idnits 2.17.1 draft-calhoun-diameter-16.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 630 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 1807, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1809, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1812, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1860, 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-04 -- 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-09 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-04 -- 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-07 -- 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') == Outdated reference: A later version (-02) exists of draft-hiller-cdma2000-aaa-01 ** Downref: Normative reference to an Informational draft: draft-hiller-cdma2000-aaa (ref. '22') == Outdated reference: A later version (-04) exists of draft-ietf-mobileip-aaa-reqs-03 ** 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' == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-10 ** Obsolete normative reference: RFC 793 (ref. '27') (Obsoleted by RFC 9293) == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-04 -- Possible downref: Normative reference to a draft: ref. '29' Summary: 22 errors (**), 0 flaws (~~), 21 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-16.txt Allan C. Rubens 5 Date: July 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 The art of AVP Tagging 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.2 Result-Code AVP 84 6.0 DIAMETER Message Routing 85 6.1 NAI-Based Message Routing 86 6.2 Message Proxying 87 6.2.1 Proxy-State AVP 88 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] 323 Vendor-ID 324 In the event that the Command-Code field contains a vendor 325 specific command, the four octet Vendor-ID field contains the IANA 326 assigned "SMI Network Management Private Enterprise Codes" [2] 327 value. If the Command-Code field contains an IETF standard 328 Command, the Vendor-ID field MUST be set to zero (0). 330 AVPs 331 AVPs is a method of encapsulating information relevant to the 332 DIAMETER message. See section 2.2 for more information on AVPs. 334 2.2 AVP Format 336 DIAMETER AVPs carry specific authentication, accounting and 337 authorization information, security information as well as 338 configuration details for the request and reply. 340 Some AVPs MAY be listed more than once. The effect of this AVP is 341 specific, and is specified in each case by the AVP description. 343 Each AVP of type 'string' and 'data' MUST be padded to align on a 32 344 bit boundary, while other AVP types align naturally. NULL bytes are 345 added to the end of the AVP value till a word boundary is reached. 346 The length of the padding is not reflected in the AVP Length field. 348 2.2.1 AVP Header 350 The AVP format is shown below and MUST be sent in network byte order. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | AVP Code | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | AVP Length | Reserved |P|T|V|R|M| 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Vendor-ID (opt) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Tag (opt) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Data ... 364 +-+-+-+-+-+-+-+-+ 366 AVP Code 367 The AVP Code identifies the attribute uniquely. The first 256 AVP 368 numbers are reserved for backward compatibility with RADIUS and 369 are to be interpreted as per NASREQ [7]. AVP numbers 256 and above 370 are used for DIAMETER, which are allocated by IANA (see section 371 8.1). 373 AVP Length 374 The AVP Length field is two octets, and indicates the length of 375 this Attribute including the AVP Code, AVP Length, AVP Flags, 376 Reserved, the Tag and Vendor-ID fields if present and the AVP 377 data. If a message is received with an Invalid attribute length, 378 the message SHOULD be rejected. 380 AVP Flags 381 The AVP Flags field informs the DIAMETER host how each attribute 382 must be handled. Note that subsequent DIAMETER extensions MAY 383 define bits to be used within the AVP Header, and an unrecognized 384 bit should be considered an error. The 'R' and the reserved bits 385 are unused and should be set to 0 and ignored on receipt, while 386 the 'P' bit is defined in [11]. 388 The 'M' Bit, known as the Mandatory bit, indicates whether support 389 of the AVP is required. If an AVP is received with the 'M' bit 390 enabled and the receiver does not support the AVP, the message 391 MUST be rejected. AVPs without the 'M' bit enabled are 392 informational only and a receiver that receives a message with 393 such an AVP that is not supported MAY simply ignore the AVP. 395 The 'V' bit, known as the Vendor-Specific bit, indicates whether 396 the optional Vendor-ID field is present in the AVP header. When 397 set the AVP Code belongs to the specific vendor code address 398 space. 400 The 'T' bit, known as the Tag bit, is used to group sets of AVPs 401 together. Grouping of AVPs is necessary when more than one AVP is 402 needed to express a condition. If this bit is set, the optional 403 Tag field will be present. 405 Unless otherwise noted, AVPs will have the following default AVP 406 Flags field settings: 407 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. The 'T' 408 bit MAY be set. 410 2.2.2 Optional Header Elements 412 The AVP Header consists of several optional fields. These fields are 413 only present if their respective bit-flags are enabled. 415 Vendor-ID 416 The Vendor-ID field is present in the 'V' bit is set in the AVP 417 Flags field. The optional four octet Vendor-ID field contains the 418 IANA assigned "SMI Network Management Private Enterprise Codes" 419 [2] value, encoded in network byte order. Any vendor wishing to 420 implement a DIAMETER extensions MUST use their own Vendor-ID along 421 with their privately managed AVP address space, guaranteeing that 422 they will not collide with any other vendor's extensions, nor with 423 future IETF extensions. 425 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 426 values, as managed by the IANA. Since the absence of the vendor ID 427 field implies that the AVP in question is not vendor specific, 428 implementations SHOULD not use the zero (0) vendor ID. 430 Tag 431 The Tag field is four octet in length and is intended to provide a 432 means of grouping attributes in the same message which refer to 433 the same set. If the Tag field is unused, the 'T' bit MUST NOT be 434 set (see section 2.4 for more information). 436 2.2.3 AVP Value Formats 438 The Data field is zero or more octets and contains information 439 specific to the Attribute. The format and length of the Data field is 440 determined by the AVP Code and AVP Length fields. The format of the 441 value field MAY be one of seven data types. 443 Data 444 The data contains a variable length of arbitrary data. Unless 445 otherwise noted, the AVP Length field MUST be set to at least 446 9. 448 String 449 The data contains a non-NULL terminated variable length string 450 using the UTF-8 [24] character set. Unless otherwise noted, 451 the AVP Length field MUST be set to at least 9. 453 Address 454 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most 455 significant octet first. The format of the address (IPv4 or 456 IPv6) is determined by the length. If the attribute value is an 457 IPv4 address, the AVP Length field MUST be 12, otherwise the 458 AVP Length field MUST be set to 24 for IPv6 addresses. 460 Integer32 461 32 bit value, in network byte order. The AVP Length field MUST 462 be set to 12. 464 Integer64 465 64 bit value, in network byte order. The AVP Length field MUST 466 be set to 16. 468 Time 469 32 bit unsigned value contains the four most significant octets 470 returned from NTP [18], in network byte order. The AVP Length 471 field MUST be set to 12. 473 Complex 474 The complex data type is reserved for AVPs that includes 475 multiple information fields, and therefore do not fit within 476 any of the AVP types defined above. Complex AVPs MUST provide 477 the data format, and the expected length of the AVP. 479 2.2.4 DIAMETER Base Protocol AVPs 481 The following table describes the DIAMETER AVPs defined in the base 482 protocol, their AVP Code values, types, possible flag values and 483 whether the AVP MAY be encrypted. 485 +---------------------+ 486 | AVP Flag rules | 487 |----+-----+----+-----|----+ 488 AVP Section Value | | |SHLD| MUST|MAY | 489 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 490 -----------------------------------------|----+-----+----+-----|----| 491 User-Name 1 3.3 String | | | | | Y | 492 Session-Timeout 27 3.2 Integer32| | | | | Y | 493 Proxy-State 33 6.2.1 Complex | M | | | T,V | N | 494 Host-IP-Address 257 2.6.4 Address | M | | | T,V | N | 495 Extension-Id 258 2.6.3 Integer32| | | | | Y | 496 Integrity-Check 259 7.1.1 Complex | | | | | N | 497 -Value | | | | | | 498 Encrypted- 260 7.1.2 Complex | | | | | N | 499 Payload | | | | | | 500 Nonce 261 7.2 Data | | | | | N | 501 Timestamp 262 7.3 Time | | | | | N | 502 Session-Id 263 3.3 Data | | | | | Y | 503 Host-Name 264 2.3.2 String | M | | | T,V | N | 504 Vendor-Name 266 2.6.1 String | | | |T,V,M| Y | 505 Firmware 267 2.6.2 Integer32| | | |T,V,M| Y | 506 -Revision | | | | | | 507 Result-Code 268 5.2 Complex | | | | | N | 508 Destination-NAI 269 6.2.2 String | | | | | Y | 509 Failed-AVP 279 5.1.1 Data | | | | | Y | 510 Redirect-Host 278 6.3.1 Address | | | | | Y | 511 Redirect-Host- 277 6.3.2 Integer32| | | | | Y | 512 Port | | | | | | 514 2.2.5 Standard DIAMETER Extension AVPs 516 The following AVPs are defined in standard DIAMETER extensions. 518 AVP Name Code Ref AVP Name Code Ref AVP Name Code Ref 519 ------------- ---- --- ------------ ---- --- ------------ ---- ---- 520 User-Password 2 [7] Framed- 38 [7] MN-FA- 322 [10] 521 CHAP-Password 3 [7] Appletalk- Challenge- 522 NAS-IP-Address 4 [7] Network Length 523 NAS-Port 5 [7] Framed- 39 [7] MN-FA-Response 323 [10] 524 Service-Type 6 [7] Appletalk- Mobile-Node- 333 [10] 525 Framed-Protocol 7 [7] Zone Address 526 Framed-IP- 8 [7] CHAP-Challenge 60 [7] Home-Agent- 334 [10] 527 Address NAS-Port-Type 61 [7] Address 528 Framed-IP- 9 [7] Port-Limit 62 [7] Previous-FA- 335 [10] 529 Netmask Login-LAT-Port 63 [7] NAI 530 Framed-Routing 10 [7] Tunnel-Type 64 [7] MN-AAA-SPI 336 [10] 531 Filter-Id 11 [7] Tunnel-Medium- 65 [7] Foreign-Home- 337 [10] 532 Framed-MTU 12 [7] Type Agent- 533 Framed- 13 [7] Tunnel-Client- 66 [7] Available 534 Compression Endpoint Filter-Rule 400 [7] 535 Login-IP-Host 14 [7] Tunnel-Server- 67 [7] Request-Type 401 [7] 536 Login-Service 15 [7] Endpoint EAP-Payload 402 [7] 537 Login-TCP-Port 16 [7] Tunnel-Password 69 [7] Accounting- 480 [15] 538 Reply-Message 18 [7] Tunnel-Private- 81 [7] Record-Type 539 Callback-Number 19 [7] Group-ID ADIF-Record 481 [15] 540 Callback-Id 20 [7] Tunnel- 82 [7] Accounting- 482 [15] 541 Framed-IP-Route 22 [7] Assignment-ID Interim- 542 Framed-IPX- 23 [7] Tunnel- 83 [7] Interval 543 Route Preference Accounting- 483 [15] 544 Idle-Timeout 28 [7] Tunnel-Client- 90 [7] Delivery- 545 Called-Station- 30 [7] Auth-ID Interval 546 Id Tunnel-Server- 91 [7] Accounting- 484 [15] 547 Calling- 31 [7] Auth-ID Delivery- 548 Station-Id CMS-Data 310 [11] Max-Delay 549 NAS-Identifier 32 [7] MIP- 320 [10] Accounting- 485 [15] 550 Login-LAT- 34 [7] Registration- Record- 551 Service Request Number 552 Login-LAT-Node 35 [7] MIP- 321 [10] Accounting- 553 Login-LAT-Group 36 [7] Registration- State 486 [15] 554 Framed- 37 [7] Reply Query-Index 500 [29] 555 Appletalk- Resource-Token 501 [29] 556 Link 558 2.3 Mandatory AVPs 560 This section defines the DIAMETER AVPs that MUST be present in all 561 DIAMETER messages. 563 2.3.1 Host-Name AVP 564 The Host-Name AVP (AVP Code 264) [1] is of type String, and is used 565 to inform a DIAMETER peer of the sender's identity. All DIAMETER 566 messages MUST include the Host-Name AVP, which contains the host name 567 of the originator of the DIAMETER message that MUST follow the NAI 568 [8] naming conventions. 570 Note that the Host-Name AVP may resolve to more than one address as 571 the DIAMETER peer may support more than one address. 573 2.4 The art of AVP Tagging 575 The AVP Header provides the 'T' bit, which is used to group AVPs 576 together. All AVPs with the same tag value are part of the same 577 "group", known as a "tagged AVP set", and there are no guidelines or 578 rules on which tag values are used. The base protocol defines the 579 Redirect-Host AVP (see section 6.3.1), and [11] defines how the 580 associated certificate MAY be carried within the DIAMETER protocol. 581 This allows a single request to include information about more than 582 one host. In the case where multiple AVPs are needed to indicate a 583 specific authorization "rule" tagging is appropriate. In some cases, 584 more than one such rule MAY be present, and the tagging mechanism 585 allows the sets of AVPs to be easily grouped. 587 Some Command Codes require certain AVPs to be tagged. Tagged AVPs are 588 represented in the BNF command definition through the use of the '(' 589 and ')' characters. All AVPs within a single tagged AVP set MUST all 590 contain the same tag value, but no two sets MAY use the same tag 591 value. 593 ::= 594 ( 595 596 ) 598 2.5 State Machine 600 This section contains a finite state machine, that MUST be observed 601 by all DIAMETER implementations. Each DIAMETER node MUST follow the 602 state machine described below when communicating with each peer. 604 State Event Action New State 605 ----- ----- ------ --------- 606 Initial Local request to establish SCTP Idle 607 communication with a DIAMETER Connect 608 peer with which there is no 609 existing transport level 610 connection established. 612 Initial Receive transport level Send DRI Open 613 connection request from a 614 DIAMETER peer. 616 Idle Connection Established Send DRI Wait-DRI 618 Idle Receive DRI Send DRI Open 620 Wait-DRI Receive DRI None Open 622 Open Receive other messages Process Open 623 Message 625 Open Receive DRI Cleanup Closed 627 Open Transport level failure Cleanup Closed 629 Closed DIAMETER Entity shutdown Close Initial 630 or close connection with peer connection 632 The Initial and Idle states MAY be merged if the local SCTP 633 implementation is able to implement the piggyback of data during the 634 connection phase. 636 When the Cleanup action is invoked, the DIAMETER node SHOULD attempt 637 to forward all pending requests and replies, which haven't been 638 acknowledged, to an alternate server (when possible). If the final 639 destination for a specific message is the host that is no longer 640 accessible, the message in question SHOULD be responded with the 641 Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 643 2.6 Device-Reboot-Ind (DRI) Command 645 A DIAMETER device sends the Device-Reboot-Ind message, by setting the 646 Command-Code field with a value of 257, to inform a peer that a 647 reboot has just occured. Since SCTP [26] allows for connections to 648 span multiple interfaces, hence multiple IP addresses, the Device- 649 Reboot-Ind message MUST contain one Host-IP-Address AVP for each 650 potential IP address that MAY be locally used when transmitting 651 DIAMETER messages. 653 The DRI message is also used for capabilities negotiation, such as 654 the supported protocol version number, and the locally supported 655 extensions. The receiver uses the extensions advertised in order to 656 determine whether it SHOULD send certain application-specific 657 DIAMETER commands. A DIAMETER node MUST retain the supported 658 extensions in order to ensure that unrecognized commands and/or AVPs 659 are not sent to a peer. Note that in a proxy environment, it is still 660 possible that a downstream proxy has no available peer that have 661 advertised the extension that corresponds to the Command-Code, and 662 therefore the request cannot be forwarded any further. The DIAMETER 663 base protocol provides this error reporting, via the Result-Code AVP. 665 Once the transport layer connection has been established, a DIAMETER 666 entity MUST issue a DRI message, regardless of whether the peer was 667 statically configured, or dynamically discovered. Dynamic discovery 668 of DIAMETER peers MAY be done by using Service Location Protocol 669 (SLP) [28], or through some other discovery mechanism. 671 If a peer is no longer reachable, a DIAMETER device SHOULD 672 periodically attempt to establish a transport level connection with 673 the peer and send a DRI message. This message does not require a 674 reply. If a DIAMETER node receives a DRI message that results in an 675 error, a Message-Reject-Ind message MUST be returned. 677 Message Format 679 ::= 680 681 682 683 684 [] 685 [ 686 687 ] 689 2.6.1 Vendor-Name AVP 691 The Vendor-Name AVP (AVP Code 266) is of type String and is used to 692 inform a DIAMETER peer of the Vendor Name of the DIAMETER device. 693 This MAY be used in order to know which vendor specific attributes 694 may be sent to the peer. It is also envisioned that the combination 695 of the Vendor-Name and the Firmware-Revision (section 2.6.2) AVPs MAY 696 provide very useful debugging information. 698 2.6.2 Firmware-Revision AVP 700 The Firmware-Revision AVP (AVP Code 267) is of type Integer32 and is 701 used to inform a DIAMETER peer of the firmware revision of the 702 issuing device. 704 For devices that do not have a firmware revision (general purpose 705 computers running DIAMETER software modules, for instance), the 706 revision of the DIAMETER software module may be reported instead. 708 2.6.3 Extension-Id AVP 710 The Extension-Id AVP (AVP Code 258) is of type Integer32 and is used 711 in order to identify a specific DIAMETER extension. This AVP is used 712 in the Device-Reboot-Ind message in order to inform the peer what 713 extensions are locally supported. 715 Each DIAMETER extension draft MUST have an IANA assigned extension 716 Idenfier (see section 8.3). The base protocol does not require an 717 Extension-Id since its support is mandatory. 719 There MAY be more than one Extension-Id AVP within a DIAMETER 720 Device-Reboot-Ind message. The following values are recognized: 722 NASREQ 1 [7] 723 Strong Security 2 [11] 724 Resource Management 3 [29] 725 Mobile-IP 4 [10] 726 Accounting 5 [15] 728 2.6.4 Host-IP-Address AVP 730 The Host-IP-Address AVP (AVP Code 4) [1] is of type Address and is 731 used to inform a DIAMETER peer of the sender's IP addresses. All 732 source addresses that a DIAMETER node expects to use with SCTP [26] 733 MUST be advertised in the Device-Reboot-Ind message by including a 734 Host-IP-Address AVP for each address. This AVP MUST ONLY be used in 735 the Device-Reboot-Ind message. 737 3.0 "User" Sessions 739 When a user requests access to the network, a DIAMETER client issues 740 an authentication and authorization request to its local server. The 741 request contains a Session-Id AVP, which is used in subsequent 742 messages (e.g. subsequent authorization, accounting, etc) relating to 743 the user's session. The Session-Id AVP is a means for the client and 744 servers to correlate a DIAMETER message with a user session. 746 When a DIAMETER server authorizes a user to use network resources, it 747 SHOULD add the Session-Timeout AVP to the response. The Session- 748 Timeout AVP defines the maximum amount of time a user MAY make use of 749 the resources before another authorization request is to be 750 transmitted to the server. If the server does not receive another 751 authorization request before the timeout occurs, it SHOULD release 752 any state information related to the user's session. Note that the 753 Session-Timeout AVP implies how long the DIAMETER server is willing 754 to pay for the services rendered, therefore a DIAMETER client SHOULD 755 NOT expect payment for services rendered past the session expiration 756 time. 758 The base protocol does not include any authorization request 759 messages, since these are largely application-specific and are 760 defined in a DIAMETER protocol extension document. However, the base 761 protocol does define a set of messages that are used to terminate 762 user sessions. These are used to allow servers that maintain state 763 information to free resources. 765 3.1 Session-Id AVP 767 The Session-Id AVP (AVP Code 263) is of type Data and is used to 768 identify a specific session (see section 3.0). All messages 769 pertaining to a specific session MUST include only one Session-Id AVP 770 and the same value MUST be used throughout the life of a session. 771 When present, the Session-Id SHOULD appear immediately following the 772 DIAMETER Header (see section 2.1). 774 For messages that do not pertain to a specific session, multiple 775 Session-Id AVPs MAY be present as long as the 'T' bit is set. 777 The Session-Id MUST be globally unique at any given time since it is 778 used by the server to identify the session (or flow). The format of 779 the session identifier SHOULD be as follows: 781 784 The monotonically increasing 32 bit value SHOULD NOT start at zero 785 upon reboot, but rather start at a random value. This will minimize 786 the possibility of overlapping Session-Ids after a reboot. 787 Alternatively, an implementation MAY keep track of the increasing 788 value in non-volatile memory. The optional value is implementation 789 specific but may include a modem's device Id, a layer 2 address, 790 timestamp, etc. 792 The session Id is created by the DIAMETER device initiating the 793 session, which in most cases is done by the client. Note that a 794 Session-Id MAY be used by more than one extension (e.g. 795 authentication for a specific service and accounting, both of which 796 have separate extensions). 798 3.2 Session-Timeout AVP 800 The Session-Timeout AVP (AVP Code 27) [1] is of type Integer32 and 801 contains the maximum number of seconds of service to be provided to 802 the user before termination of the session. A value of zero means 803 that this session has an unlimited number of seconds before 804 termination. 806 This AVP MAY be provided by the client as a hint of the maximum 807 duration that it is willing to accept. However, the server DOES NOT 808 have to observe the hint, and MAY return a value that is smaller than 809 the hint. A value of zero provided by a client DOES NOT imply that 810 service is being terminated. 812 3.3 User-Name AVP 814 The User-Name AVP (AVP Code 1) [1] is of type String and contains the 815 User-Name in a format consistent with the NAI specification [8]. All 816 DIAMETER systems SHOULD support usernames of at least 72 octets in 817 length. 819 3.4 Session Termination 821 The DIAMETER Base Protocol provides a set of messages that MAY be 822 used by any peer to explicitely request that a previously 823 authenticated and/or authorized session be terminated. Since the 824 Session-Id is typically tied to a particular service (i.e. Mobile IP, 825 NASREQ, etc), the session termination messages are used to request 826 that the service tied to the Session Id be terminated. 828 3.4.1 Session-Termination-Ind 830 The Session-Termination-Ind (STI), indicated by the Command-Code set 831 to 274, MAY be sent by any DIAMETER entity to the access device to 832 request that a particular session be terminated. This message MAY be 833 used when a server detects that a session MUST be terminated, which 834 is typically done as a policy decision (e.g. local resources have 835 been expended, etc). The Destination-NAI AVP MUST be present, and 836 contain the NAI of the access device that initiated the session (see 837 section 3.0). 839 Upon receipt of the STI message, the access device SHOULD issue a 840 Session-Terminate-Request message. 842 Message Format 844 ::= 846 847 848 849 850 [] 851 [ 852 853 ] 855 3.4.2 Session-Termination-Request 857 The Session-Termination-Request (STR), indicated by the Command-Code 858 set to 275, is sent by the access device to inform the Home AAA that 859 an authenticated and/or authorized session is being terminated. The 860 Destination-NAI AVP MUST be present, and set to the value that was 861 found in the Host-Name AVP of the authentication and/or authorization 862 response that corresponds with the session in question (e.g. AAA, 863 HAR, AMA in section 2.1). 865 Upon receipt of the STR, the Home DIAMETER Server SHOULD release all 866 resources for the session indicated by the Session-Id AVP. Any 867 intermediate server in the Proxy-Chain MAY also release any 868 resources, if necessary. 870 Message Format 872 ::= 874 875 876 877 878 [] 879 [ 880 881 ] 883 3.4.3 Session-Termination-Answer 885 The Session-Termination-Answer (STA), indicated by the Command-Code 886 set to 276, is sent by the Home DIAMETER Server to acknowledge that 887 the session has been terminated. The Result-Code AVP MUST be present, 888 and MAY contain an indication that an error occured while servicing 889 the STR. 891 Message Format 893 ::= 895 896 897 898 899 900 [] 901 [ 902 903 ] 905 4.0 Reliable Transport 907 In order to provide rapid discovery of the failure of a communicating 908 peer, aggressive retransmission and rapid transactions, DIAMETER 909 peers MUST be able to send and receive messages over SCTP [26]. A 910 DIAMETER peer MAY use TCP [27], as TCP does provide reliable 911 transport, though it does not have the properties listed above. 913 5.0 Error Reporting 915 There are five different types of errors within DIAMETER. The first 916 being where a DIAMETER message is poorly formatted and 917 unrecognizable, indicated below by "Bad Message". This error 918 condition applies if a received message creates a fatal error (e.g. 919 fails transport level authentication, cannot be parsed, etc). 921 The second case involves receiving a Command-Code that is not 922 supported, which is shown below by "Unknown Command". The third case 923 is where an AVP is received, marked mandatory and is unknown by the 924 receiver, which is labeled below as "Unknown AVP". 926 This fourth case involves receiving a message with a known AVP, yet 927 the value is either unknown or illegal, which is shown below as "Bad 928 Value". The last case occurs when an error occurs while processing a 929 specific extension command, which is not related to the message 930 format and is labeled "Extension Error" below. 932 Error Type Ignore Message Send Extension 933 Message-Reject-Ind Response + 934 Result-Code 935 Bad Message X 936 Unknown Command X 937 Unknown AVP X 938 Bad Value X 939 Extension Error X 941 "Ignore Message" indicates that the message is simply dropped. The 942 "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST 943 be sent to the peer as described in the appropriate section. The 944 "Extension Response + Result-Code" indicates that the appropriate 945 Response to the message MUST be sent with the Result-Code AVP set to 946 a value that enables the peer to understand the nature of the 947 problem. 949 5.1 Message-Reject-Ind (MRI) Command 951 The Message-Reject-Ind (MRI), indicated by the Command-Code set to 952 259, provides a generic means of completing transactions by 953 indicating errors in the messages that initiated them. The Message- 954 Reject-Ind command is sent in response: 956 1. An error is found in a Device-Reboot-Ind message. 957 2. An error is found in a message for which there is no 958 appropriate response. 959 3. A message was received that cannot pass the base protocol error 960 checking. 961 4. A message was received whose extension is not locally 962 supported. 964 In the event that a request is received that causes an error defined 965 in a DIAMETER extension, the appropriate response with the Result- 966 Code AVP SHOULD be sent. 968 The Message-Reject-Ind message MUST contain the same identification 969 in the header and include the Session-Id if it was present in the 970 original message that it is responding to, even if the identification 971 is erroneous. 973 Message Format 975 The structure of the Message-Reject-Ind message is defined as 976 follows: 978 ::= 980 981 [] 982 983 984 [ 985 986 ] 988 where the Identifier value in the message header and optionally 989 the Session-Id AVP are copied from the message being rejected. The 990 Result-Code AVP indicate the nature of the error causing 991 rejection, and the Failed-AVP AVP provides some minimal debugging 992 data by indicating a specific AVP type which caused the problem. 993 See the description of the Result-Code AVP for indication of when 994 the Failed-AVP AVP MUST be present in the message. See [25] for 995 more information. 997 5.1.1 Failed-AVP AVP 999 The Failed-AVP AVP (AVP Code 279) is of type Data and provides 1000 debugging information in cases where a request is rejected or not 1001 fully processed due to erroneous information in a specific AVP. The 1002 value of the Result-Code AVP will provide information on the reason 1003 for the Failed-AVP AVP. 1005 A DIAMETER message MAY contain one or more Failed-AVP, each 1006 containing a complete AVP that could not be processed successfully. 1007 The possible reasons for this AVP are the presence of an improperly 1008 constructed AVP, an unsupported or unrecognized AVP or an invalid AVP 1009 value (e.g. unknown Command-Code). 1011 5.2 Result-Code AVP 1013 The Result-Code AVP (AVP Code 268) is of type Complex and indicates 1014 whether a particular request was completed successfully or whether an 1015 error occurred. All DIAMETER messages of type *-Response or *-Answer 1016 MUST include one Result-Code AVP. 1018 0 1 2 3 1019 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 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 AVP Header (AVP Code = 268) 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Result Code | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | String ... 1026 +-+-+-+-+-+-+-+-+ 1028 The Result Code field contains an IANA-managed 32-bit address space 1029 representing errors (see section 8.4). The String field contains an 1030 OPTIONAL string field containing a human readable error message. The 1031 base protocol defines the following error codes, and others MAY be 1032 defined in separate DIAMETER extensions: 1034 DIAMETER_SUCCESS 0 1035 The Request was successfully completed. 1037 DIAMETER_FAILURE 1 1038 The Request was not successfully completed for an unspecified 1039 reason. A DIAMETER Message-Reject-Ind message returning this 1040 result SHOULD whenever possible also contain one or more 1041 Failed-AVP AVPs indicating the AVPs that caused the failure. 1043 DIAMETER_POOR_REQUEST 2 1044 The Request was poorly constructed. 1046 DIAMETER_INVALID_AUTH 3 1047 The Request did not contain a valid Integrity-Check-Value or 1048 CMS-Data [11] AVP. 1050 DIAMETER_UNKNOWN_SESSION_ID 4 1051 The request or response contained an unknown Session-Id. 1053 DIAMETER_USER_UNKNOWN 5 1054 A request was received for a user that is unknown, therefore 1055 authentication failed. This error is sent only due to 1056 conditions that arise due to command messages in DIAMETER 1057 extensions, the base protocol does not include command codes 1058 that require the User-Name AVP. 1060 DIAMETER_COMMAND_UNSUPPORTED 6 1061 The Request contained a Command-Code that the receiver did not 1062 recognize or support. The Message-Reject-Ind message MUST also 1063 contain a Failed-AVP AVP containing the unrecognized Command- 1064 Code. 1066 DIAMETER_TIMEOUT 7 1067 This error MAY be returned if a request has been received that 1068 has a Timestamp AVP that is older than the maximum age that the 1069 communicating peer is willing to accept. 1071 DIAMETER_AVP_UNSUPPORTED 8 1072 The peer received a message that contained an AVP that is not 1073 recognized or supported and was marked with the Mandatory bit. 1074 A DIAMETER message with this error MUST contain one or more 1075 Failed-AVP AVP containing the AVPs that caused the failure. 1077 DIAMETER_REDIRECT_INDICATION 9 1078 A proxy or broker has determined that the request could not be 1079 satisfied locally and the initiator of the request should 1080 direct the request directly to the server, whose contact 1081 information has been added to the response. This error code 1082 MUST NOT be sent in a Message-Reject-Ind message. 1084 DIAMETER_REALM_NOT_SERVED 10 1085 A proxy or broker has determined that it is unable to forward 1086 the request or provide redirect information since the realm 1087 portion of the NAI requested is unknown. 1089 DIAMETER_UNSUPPORTED_TRANSFORM 11 1090 A message was received that included an Integrity-Check-Value 1091 or CMS-Data AVP [11] that made use of an unsupported transform. 1093 DIAMETER_AUTHENTICATION_REJECTED 12 1094 The authentication process for the user failed, most likely due 1095 to an invalid password used by the user. 1097 DIAMETER_AUTHORIZATION_REJECTED 13 1098 A request was received for which the user could not be 1099 authorized. This error could occur when the user has already 1100 expended allowed resources, or if the service requested is not 1101 permitted to the user. 1103 DIAMETER_INVALID_AVP_VALUE 14 1104 The request contained an AVP with an invalid value in its data 1105 portion. A DIAMETER message with this result code MUST include 1106 the offending AVPs within a Failed-AVP AVP. 1108 DIAMETER_MISSING_AVP 15 1109 The request did not contain an AVP that is considered mandatory 1110 by the Command Code definition. If this value is sent in the 1111 Result-Code AVP, a Failed-AVP AVP SHOULD be included in the 1112 message. The data portion of the Failed-AVP MUST have its AVP 1113 Code set to the value of the missing AVP. 1115 DIAMETER_UNABLE_TO_DELIVER 16 1116 The request could not be delivered to the host specified in the 1117 Destination-NAI AVP, or no host is available for that 1118 particular realm to handle the request. 1120 5.2.1 Additional Error Codes 1122 The following additional result codes are defined by standard 1123 extensions to the DIAMETER protocol. 1125 DIAMETER_ERROR_BAD_KEY 16 [10] 1126 DIAMETER_ERROR_BAD_HOME_ADDRESS 17 [10] 1127 DIAMETER_ERROR_TOO_BUSY 18 [10] 1128 DIAMETER_ERROR_MIP_REPLY_FAILURE 19 [10] 1129 DIAMETER_INVALID_CMS_DATA 20 [11] 1131 6.0 DIAMETER Message Routing 1133 The DIAMETER base protocol supports two basic message routing 1134 methods; proxying and brokering. A DIAMETER proxy is a server that 1135 simply forwards the request based on the user's identity, or through 1136 some other means. A DIAMETER broker is a server that provides 1137 redirect services, allowing all servers in a roaming consortium to 1138 interact directly. This section describes how DIAMETER message 1139 routing is performed. 1141 6.1 NAI-Based Message Routing 1143 DIAMETER Message routing is done through the use of the Network 1144 Access Identifier (NAI), and an associated realm routing table (see 1145 section 10.0). The NAI has a format of user@realm, and DIAMETER 1146 servers have a list of locally supported realms, and MAY have a list 1147 of externally supported realms. When a message is received that 1148 includes a realm that is not locally supported, the message is 1149 proxied to the DIAMETER entity configured in the "route" table. 1151 Figure 1 depicts an example where DIA1 receives a request to 1152 authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local 1153 realm route table and determines that the message must be proxied to 1154 DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3 1155 checks its realm route table, and determines that the realm is 1156 locally supported, and processes the authentication request, and 1157 returns the response. How the response actually makes it back to the 1158 sender of the original request is described in the next section. 1160 (Request) (Request) 1161 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1162 +------+ ------> +------+ ------> +------+ 1163 | | | | | | 1164 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1165 | | | | | | 1166 +------+ <------ +------+ <------ +------+ 1167 (Response) (Response) 1168 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1170 mno.net xyz.com abc.com 1171 Figure 1: NAI Based Routing 1173 6.2 Message Proxying 1175 A DIAMETER proxy is a server that provides message forwarding 1176 functions to other DIAMETER Servers. Proxies are typically used when 1177 a hierarchical DIAMETER network is deployed, where some DIAMETER 1178 servers can authenticate and authorize a set of users. Such an 1179 example is a roaming consortium, where each ISP has a user base, 1180 which they can authenticate and authorize. It is important to note 1181 that proxy servers MUST NOT attempt to re-order AVPs in a DIAMETER 1182 message. 1184 There are two different methods of routing DIAMETER messages through 1185 proxies; Proxy-State and Destination-NAI. The Proxy-State AVP is used 1186 to encode local state information in a request. The corresponding 1187 response is guaranteed to include the same Proxy-State AVP, allowing 1188 the node to recover the state information. The use of the Proxy-State 1189 AVP requires that the corresponding response traverse through the 1190 same set of proxies (in reverse order), which introduces some 1191 reliability problems. If a single DIAMETER node in the proxy chain 1192 fails, all responses that must traverse through it would be lost. The 1193 Proxy-State AVP is used by proxy servers that MUST maintain state 1194 information, such as protocol translation gateways [25]. 1196 The Destination-NAI is a more flexible scheme, and is used by 1197 DIAMETER proxies that do not need to maintain any state information 1198 when acting as a simple message routing agent. This allows the 1199 DIAMETER network to be much more reliable, since responses can be 1200 sent through an alternate path should a proxy server fail. 1202 6.2.1 Proxy-State AVP 1204 The Proxy-State AVP (AVP Code 33) [1] is used by proxy servers when 1205 forwarding requests and contains opaque data that is used by the 1206 proxy to further process the response. Such data may include AVPs 1207 that are to be added to the response, information about the 1208 downstream peer, etc. 1210 It is important to note that the use of the Proxy-State AVP requires 1211 that the corresponding response traverse through the DIAMETER node 1212 that added the AVP. The requirement that responses return on the 1213 reverse path of a request is only adequate in certain networks. It 1214 does not allow for resilient operation, since alternative servers 1215 MUST NOT be used. Therefore a DIAMETER node SHOULD only use the 1216 Proxy-State AVP when performing protocol bridging [25]. 1218 A DIAMETER node that adds a Proxy-State AVP to a request expects the 1219 SAME AVP to be present in the corresponding response. Furthermore, 1220 more than one Proxy-State AVP MUST NOT be present in a single 1221 DIAMETER message. See [25] for more information on AVP handling. 1223 (Request) (Request) 1224 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1225 (Proxy-State=DIA1,x) (Proxy-State=DIA2,y) 1226 +------+ ------> +------+ ------> +------+ 1227 | | | | | | 1228 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1229 | | | | | | 1230 +------+ <------ +------+ <------ +------+ 1231 (Response) (Response) 1232 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1233 (Proxy-State=DIA1,x) (Proxy-State=DIA2,y) 1235 mno.net xyz.com abc.com 1236 Figure 2: Use of the Proxy-State AVP 1238 When a DIAMETER node receives a message that includes the Proxy-State 1239 AVP, and the address within the AVP is a peer that it is able to 1240 exchange DIAMETER messages with, the message MUST be forwarded to the 1241 peer in question. When the Proxy-State AVP's address indicates that 1242 the AVP was locally added, the Proxy-State AVP MUST be removed, and 1243 the original Proxy-State AVP must be restored (if one was present in 1244 the corresponding request). When DIA2 receives the response from DIA3 1245 (in figure 2), it examines the Proxy-State and finds that it was 1246 created by DIA1. Since DIA2 is able to communicate with DIA1, it 1247 forwards the message to DIA1. 1249 The Proxy-State AVP's Address field is 128-bits in length contains 1250 one of the IP addresses of the system that created the AVP, and used 1251 to assist hosts in determining whether a Proxy-State AVP is intended 1252 for the local host. If the host creating the AVP has an IPv4 address, 1253 and is IPv6 capable, the leading 96 bits MUST be set to zero (0). If 1254 the AVP has an IPv4 address, and the host is not IPv6 capable, the 1255 leading 64 bites MUST be set to zero (0), and the following 32 bits 1256 MUST be set to all ones [16]. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 AVP Header (AVP Code = 33) 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | 128-bit Address... 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Data ... 1266 +-+-+-+-+-+-+-+-+ 1268 6.2.2 Destination-NAI AVP 1270 The Destination-NAI AVP (AVP Code 269) is of type String, MAY be 1271 included in a request, and SHOULD be included in a response message. 1272 The Destination-NAI MUST be in a format consistent with the NAI 1273 specification. When found in a response, the AVP SHOULD contain the 1274 value of the Host-Name AVP that was found in the request. 1276 Since the Destination-NAI AVP allows for a more resilient DIAMETER 1277 network, by allowing a DIAMETER node to send to one of many peers 1278 that can handle a particular realm, implementations SHOULD use it as 1279 opposed to the Proxy-State AVP. 1281 Request messages in transactions that span multiple round trips (e.g. 1282 EAP [7]), the Destination-NAI AVP SHOULD be copied from the previous 1283 response that caused the new request. This will ensure that all 1284 requests forming the transaction will be forwarded to the same target 1285 DIAMETER server. 1287 (Request) (Request) 1288 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1289 (Host-Name=DIA1@nmo.net) (Host-Name=DIA1@nmo.net) 1290 +------+ +------+ +------+ 1291 | | | | | | 1292 | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 | 1293 | | | | | | 1294 +------+ +------+ +------+ 1295 ^ | 1296 | +------+ | 1297 | | | | 1298 +-----------------------| DIA4 |<----------------------+ 1299 | | 1300 +------+ 1301 (Response) (Response) 1302 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1303 (Dest-NAI=DIA1@mno.net) (Dest-NAI=DIA1@mno.net) 1305 mno.net mno.com abc.com 1306 Figure 3: Use of Destination-NAI 1308 When DIA3 (in figure 3) creates the response, it adds the 1309 Destination-NAI AVP with the value that was found in the request's 1310 Host-Name AVP. DIA3 is not able to communicate directly with DIA1, 1311 but it is able to communicate with peers within the mno.com network. 1312 Therefore, it issues the response to any peer in the mno.com network. 1313 When DIA4 receives the response, it examines the Destination-NAI AVP, 1314 and determines that it is able to communicate directly with DIA1, and 1315 forwards the response to it. 1317 6.3 Message Redirection 1319 There are cases where a DIAMETER proxy, known as a broker, may wish 1320 to request that a server contact another directly instead of 1321 forwarding the message (figure 2). This is typically done when the 1322 broker provides simple NAI to Home DIAMETER Server address resolution 1323 services. 1325 In the example provided in figure 4, abc.net's DIAMETER server issues 1326 a request to its broker, which in turn returns a response that 1327 includes the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION (see 1328 section 5.2). When a response is received with the Result-Code set 1329 to this value, the message MUST also include one or more Redirect- 1330 Host AVPs, and optionally the Redirect-Host-Port AVP. The Redirect- 1331 Host AVP contains the IP address to which the request SHOULD be 1332 forwarded to directly. When more than one untagged Redirect-Host-Port 1333 AVPs are found, they contain more than one server that could service 1334 the request. When more than one tagged Redirect-Host AVP is present 1335 in the message, they contain the various IP addresses of the SAME 1336 host, any of which MAY be used to directly contact the peer. 1338 The above requires that the broker be contacted for all messages in 1339 order to identify the Home DIAMETER server to use for a particular 1340 realm. Since contacting the broker does introduce additional latency, 1341 an implementation MAY cache the information received by the broker, 1342 eliminating the need to contact the broker for multiple messages to 1343 the same realm. The broker MAY include the the Session-Timeout AVP in 1344 the redirect response as a hint to its peer as to how long the cache 1345 entry SHOULD be valid. The peer is not obligated to respect the hint 1346 from the broker. 1348 In the event that the Redirect-Host AVP is tagged, the broker MAY 1349 also add the tag to the Session-Timeout AVP in order to specify the 1350 cache timeout for the particular host. 1352 +------------------+ +---------+ 1353 | DIAMETER | | CRL DB/ | 1354 | Broker | | OCSP | 1355 +------------------+ +---------+ 1356 ^ 1357 Request | Response + 1358 | Result Code = 1359 | Redirect 1360 v 1361 +----------+ +----------+ 1362 | abc.net | | xyz.net | 1363 | DIAMETER |<------------>| DIAMETER | 1364 | Server | | Server | 1365 +----------+ Direct +----------+ 1366 Communication 1367 Figure 4: DIAMETER Broker Returning Redirect Indication 1369 When returning the response with the Result-Code set to 1370 DIAMETER_REDIRECT_INDICATION, the broker MAY also include the 1371 certificates of both the requesting server, and the target server. 1372 These certificates are encapsulated in a CMS-Data AVP [11]. The 1373 requesting server SHOULD forward the certificate that belongs to it 1374 in the subsequent request to the home DIAMETER server. 1376 Figure 5 below provides a more complex network, where the request 1377 must be forwarded to a second broker (Inter-Broker Communication), 1378 and there are a number of proxies between the NAS and the "edge" 1379 DIAMETER Server that communicates with the broker. When Broker A 1380 receives the response that includes the redirect information from 1381 Broker B, it is passed down to abc's DIAMETER server, which in turn 1382 communicates directly with xyz's server. 1384 +------------+ Request +------------+ 1385 | DIAMETER | | DIAMETER | 1386 | Broker A |<--------->| Broker B | 1387 +------------+ Redirect +------------+ 1388 ^ Response 1389 Request |Redirect 1390 |Response 1391 | 1392 v 1393 +----------+ +----------+ 1394 +-----+ +-| abc.net | | xyz.net | 1395 | | +-| | DIAMETER |<------------>| DIAMETER | 1396 | NAS |<->| | | Server(s)| | Server | 1397 | | | | +----------+ Direct +----------+ 1398 +-----+ | +----------+ Communication 1399 +----------+ 1400 Figure 5: Inter-Broker redirect in a proxied network 1402 6.3.1 Redirect-Host AVP 1404 The Redirect-Host AVP (AVP Code 278) is of type Address and is 1405 returned in a response that has the Result-Code AVP set to 1406 DIAMETER_REDIRECT_REQUEST. This AVP includes the IP address of the 1407 DIAMETER host to which the request MUST be redirected. The presence 1408 of multiple tagged Redirect-Host AVPs with the same tag value, 1409 implies that all of the addresses MAY be used to contact the same 1410 host. When multiple AVPs are found that are un-tagged, or tagged with 1411 different value, they represent separate hosts. Upon receipt of such 1412 a Result-Code, and this AVP, a DIAMETER host SHOULD send the request 1413 directly to one of the hosts. 1415 The broker MAY wish to return the certificate associated with a given 1416 Redirect-Host AVP. This can be returned in a CMS-Data AVP, as defined 1417 in [11]. 1419 6.3.2 Redirect-Host-Port AVP 1421 The Redirect-Host-Port AVP (AVP Code 277) is of type Integer32 and 1422 MAY be present when the Redirect-Host AVP is present. The absence of 1423 this AVP implies that the reserved port MUST be used. 1425 7.0 DIAMETER Message Security 1426 The DIAMETER Base protocol MAY be secured in one of three ways. The 1427 first method does not involve any security mechanisms in the DIAMETER 1428 protocol, but relies on an underlying security mechanism, such as IP 1429 Security. The second method is hop-by-hop security, which SHOULD be 1430 supported by all DIAMETER implementations. The third method is 1431 optional and requires a Public Key Infrastructure [14], and is 1432 documented in [11]. 1434 7.1 Hop-by-Hop Security 1436 DIAMETER Hop-by-Hop security provides message integrity and per AVP 1437 encryption, and requires that the communicating entities have a pre- 1438 configured shared secret, similar to the method employed by the 1439 RADIUS protocol. Hop-by-Hop security is very difficult to deploy and 1440 administer in large scale networks and involves symmetric trust, 1441 unlike security based on a public key infrastructure (PKI). PKI is 1442 used for DIAMETER End-to-End security, and is defined in [11]. Hop- 1443 by-Hop security may be desirable in environments where symmetric 1444 cryptography is sufficient or when a PKI is not available. 1446 Figure 6 below provides an example of hop-by-hop security in a proxy 1447 chain. Assuming that the packet was received by DIA2 from DIA1, and 1448 was to be proxied to DIA3, the following steps would be taken: 1450 1. Validating the message's integrity using the shared secret with 1451 DIA1, and removing the authenticated security AVPs. 1453 2. Decrypting any encrypted AVPs using the secret shared with DIA1. 1455 3. Re-encrypting AVPs using the secret shared with DIA3. 1457 4. Computing the message hash using the secret shared with DIA3, 1458 and adding it to the ICV AVP in the DIAMETER message. 1460 (Shared-Secret-1) (Shared-Secret-2) 1461 +------+ -----> +------+ ------> +------+ 1462 | | |1 3| | | 1463 | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 | 1464 | | |2 4| | | 1465 +------+ +------+ +------+ 1466 Figure 6: Hop-by-Hop Security in Proxy Environments 1468 The above steps that each proxy MUST perform in a proxy chain clearly 1469 describes the security issues associated with hop-by-hop security in 1470 a proxy environment. Since the message integrity is re-computed at 1471 each node in the chain, it is not possible to detect if a proxy 1472 modified information in the message (e.g. session time). Furthermore, 1473 any sensitive information would be known to all proxies in the chain, 1474 since each node must decrypt AVPs. Therefore, Any AVPs that contain 1475 data that MUST NOT be seen by intermediate DIAMETER nodes MUST be 1476 protected via the mechanism described in the strong security 1477 extension [11]. 1479 It is highly recommended that the size of the shared secrets used be 1480 sufficiently long (e.g. 128 bits), and that different shared secrets 1481 be used for both authentication and encryption. 1483 7.1.1 Integrity-Check-Value AVP 1485 The Integrity-Check-Value AVP (AVP Code 259) is of type complex and 1486 is used for hop-by-hop message authentication and integrity. 1488 The DIAMETER header as well as all AVPs (including padding) up to 1489 this AVP is protected by the Integrity-Check-Value. Note that the 1490 Message Length field in the DIAMETER header MUST be set to zero (0) 1491 prior to the ICV calculation. The Timestamp and Nonce AVPs MUST be 1492 present in the message PRIOR to the Integrity-Check-Value AVP. The 1493 Timestamp AVP provides replay protection and the Nonce AVP provides 1494 randomness. Any AVPs in a message that is not succeeded by the 1495 Integrity-Check-Value AVP MUST be ignored. 1497 The following is an example of a message that include hop-by-hop 1498 security: 1500 ::= 1501 1502 [] 1503 1504 1506 All DIAMETER implementations SHOULD support this AVP. 1508 0 1 2 3 1509 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 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 AVP Header (AVP Code = 259) 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Transform ID | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Key ID | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Data ... 1518 +-+-+-+-+-+-+-+-+ 1519 AVP Length 1520 The length of this attribute MUST be at least 13. 1522 Transform ID 1523 The Transform ID field contains a value that identifies the 1524 transform that was used to compute the ICV. The following 1525 values are defined in this document: 1527 HMAC-MD5-96[6] 1 1528 The ICV is computed using the HMAC-MD5 algorithm, and the 1529 first 12 bytes of the hash output is included in the data 1530 portion of the ICV AVP. All DIAMETER implementations 1531 supporting this AVP MUST support this transform. Using the 1532 example code provided in [6], the following call would be 1533 used to generate the Integrity-Check-Value: 1535 hmac_md5(DiameterMessage, MessageLength, Secret, 1536 Secretlength, Output) 1538 Key ID 1539 The Key ID field contains a key identifier, which is used to 1540 identify the keying information used to generate the AVP's data 1541 field. 1543 Data 1544 The data field contains the output from the hashing algorithm. 1546 7.1.2 Encrypted-Payload AVP 1548 The Encrypted-Payload AVP (AVP Code 260) is of type complex and is 1549 used to encapsulate encrypted AVPs for privacy during transmission. 1551 Hop-by-Hop confidentiality is achieved by encapsulating all AVPs 1552 which are to be encrypted into an Encrypted-Payload AVP. This 1553 feature SHOULD be supported by DIAMETER implementations. 1555 0 1 2 3 1556 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 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 AVP Header (AVP Code = 260) 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Transform ID | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Key ID | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Decrypted Data Length | Data ... 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 AVP Length 1567 The length of this attribute MUST be at least 13. 1569 Transform ID 1570 The Transform ID field contains a value that identifies the 1571 transform that was used to compute the ICV. The following 1572 values are defined in this document: 1574 MD5 1 1575 See section 7.1.2.1 for more information. 1577 Key ID 1578 The Key ID field contains a key identifier, which is used to 1579 identify the keying information used to generate the AVP's data 1580 field. 1582 Decrypted Data Length 1583 The encrypted data length field contains the actual length of 1584 the decrypted data. This field is necessary in order to not 1585 treat the padded data as part of the plaintext. 1587 Data 1588 The data field contains the encrypted payload. 1590 7.1.2.1 MD5 Payload Hiding 1592 MD5 Payload Hiding is supported by DIAMETER for backward 1593 compatibility with existing RADIUS infrastructure. 1595 The plain text (which is a buffer containing one or more AVPs) is 1596 first padded to a sixteen (16) byte boundary with 0 bytes. Since the 1597 encapsulated AVPs have length fields, it is possible to detect their 1598 boundaries, whether or not padding has been done. 1600 One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 1601 hash is performed on the: 1603 - last Nonce AVP which precedes the Encrypted-Payload AVP 1604 - the shared authentication secret 1606 This MD5 hash value is then XORed with the first 16 octet segment of 1607 the buffer to encrypt. The resulting 16 octet result is saved as the 1608 first 16 octets of the encrypted buffer. The result is also used to 1609 calculate a new value using MD5: 1611 - the shared authentication secret 1612 - the 16 byte result of the previous XOR 1614 This value is then XORed with the next 16 bytes. This is done for 1615 each 16 bytes successively in the buffer to encrypt, producing an 1616 equal sized encrypted buffer. 1618 The receiver of a DIAMETER message with an Encrypted-Payload AVP MUST 1619 first check the integrity of the message, either through the ICV, or 1620 the CMS-Data AVP [11] if it protects the Encrypted-Payload AVP. Then 1621 the Encrypted-Payload AVP is decrypted, by reversing the above 1622 procedure, which applied to the buffer will reproduce the plain text 1623 version. The decapsulated AVPs are then used to process the DIAMETER 1624 message in the normal manner. 1626 7.2 Nonce AVP 1628 The Nonce AVP (AVP Code 261) is of type Data and MUST be present 1629 prior to the Integrity-Check-Value AVPs within a message and is used 1630 to ensure randomness within a message. The content of this AVP MUST 1631 be a random value of at least 128 bits. Some crypto algorithms are 1632 known to have weaknesses if a random value is not found early within 1633 the plaintext, therefore it is recommended that the Nonce AVP be 1634 added early in a message if possible. 1636 7.3 Timestamp AVP 1638 The Timestamp AVP (AVP Code 262) is of type Time and is used to add 1639 replay protection to the DIAMETER protocol. This AVP MUST appear 1640 prior to the Integrity-Check-Value AVP or any other message integrity 1641 AVP defined in separate extensions. The value of this AVP is the most 1642 significant four octets returned from an NTP [18] server that 1643 indicates the number of seconds expired since Jan. 1, 1900. 1645 Messages that are older than a configurable maximum age SHOULD be 1646 rejected (see section 10.0) and a response SHOULD be returned with 1647 the Result-Code AVP value set to DIAMETER_TIMEOUT. Note that the 1648 larger the configurable value, the more susceptible one is to a 1649 replay attack. However, one does have to take into account the 1650 possibility for clock drift, and the latency involved in the 1651 transmission of the message over the network. The timestamp AVP 1652 SHOULD be updated prior to retransmission. 1654 A DIAMETER node that receives a message with the Result-Code AVP set 1655 to DIAMETER-TIMEOUT MAY use the time found in the Timestamp AVP 1656 within the reply in order to synchronize its clock with its peer. 1657 When time synchronization is done, the sender MUST NOT change its 1658 local time, but SHOULD adjust the time delta for all outgoing 1659 messages to the peer, and require that its local time be used in 1660 received messages. 1662 Implementations must be prepared to wrap at the epochal 2038 where 1663 Time values are used, and 0,1,... MUST be considered greater than 1664 2^32-1 at that time. 1666 8.0 IANA Considerations 1668 This document defines a number of assigned numbers to be maintained 1669 by the IANA. This section explains the criteria to be used by the 1670 IANA to assign additional numbers in each of these lists. The 1671 following subsections describe the assignment policy for the 1672 namespaces defined elsewhere in this document. 1674 8.1 AVP Attributes 1676 As defined in section 2.2, AVPs contain vendor ID, attribute and 1677 value fields. For vendor ID value of 0, IANA will maintain a registry 1678 of assigned AVP codes and in some case also values. Attribute 0-254 1679 are assigned from the RADIUS protocol [1], whose attributes are also 1680 maintained through IANA. AVP Codes 256-280 are assigned within this 1681 document. The remaining values are available for assignment through 1682 Designated Expert [12]. 1684 8.2 Command Code Values 1686 As defined in section 2.1, the Command Code field has an associated 1687 value maintained by IANA. Values 0-255 are reserved for backward 1688 RADIUS compatibility, and values 256-258 are defined in this 1689 specification. The remaining values are available for assignment via 1690 Designated Expert [12]. 1692 8.3 Extension Identifier Values 1694 As defined in section 2.6.5, the Extension Identifier is used to 1695 identify a specific DIAMETER Extension. All values, other than zero 1696 (0) are available for assignment via Standards Action [12]. 1698 Note that the DIAMETER protocol is not inteded to be extended for any 1699 purpose. Any extensions added to the protocol MUST ensure that they 1700 fit within the existing framework, and that no changes to the base 1701 protocol are required. 1703 8.4 Result-Code AVP Values 1705 As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines 1706 the values 0-8. All remaining values are available for assignment via 1707 IETF Consensus [12]. 1709 8.5 Integrity-Check-Value AVP Transform Values 1711 Section 7.1.1 defines the Integrity-Check-Value AVP (AVP Code 259) 1712 which contains a field called the Transform. This document reserves 1713 the value 1. All remaining values are available for assignment via 1714 Designated Expert [12]. 1716 8.6 AVP Header Bits 1718 There are six remaining reserved bits in the AVP header. Additional 1719 bits should only be assigned via a Standards Action [12]. 1721 9.0 Open Issues 1723 The following are the open issues that SHOULD be addressed in future 1724 versions of the DIAMETER protocol: 1726 - AVPs of type 'Time" are 32 bits in size and contain the a 1727 timestamp consistent with NTP [18]. This field is expected to 1728 expire sometime in 2038. Future investigation SHOULD be done to 1729 determine if a 64 bit time format could be used. 1731 - The fact that the Sender's IP Address is used in the 1732 construction of the Session-Id means that the introduction of 1733 Network Address Translation MAY cause two hosts to represent the 1734 same Session Identifier. This area needs to be investigated 1735 further to be able to support DIAMETER hosts on a private 1736 network. 1738 - When additional hashing transforms are supporting by the 1739 DIAMETER base protocol, there SHOULD be a method to negotiate 1740 the transform to be used. This negotiation MUST NOT be prone to 1741 a bidding down attack to the lowest secure transform. 1743 - This specification defines the use of SCTP port 1812. This port 1744 has not been assigned to the DIAMETER protocol, and cannot be 1745 requested until SCTP becomes an RFC. 1747 10.0 DIAMETER protocol related configurable parameters 1749 This section contains the configurable parameters that are found 1750 throughout this document: 1752 DIAMETER Peer 1753 A DIAMETER entity MAY communicate with peers that are 1754 statically configured. A statically configured DIAMETER peer 1755 would require that either the IP address or the fully qualified 1756 domain name (FQDN) be supplied, which would then be used to 1757 resolve through DNS. 1759 Realm Routing Table 1760 A DIAMETER Proxy server routes messages based on the realm 1761 portion of a Network Access Identifier (NAI). The server MUST 1762 have a table of Realms Names, and the address of the peer to 1763 which the message must be forwarded to. The routing table MAY 1764 also include a "default route", which is typically used for all 1765 messages that cannot be locally processed. 1767 Maximum Age of an outstanding message 1768 Messages older than the maximum age SHOULD be rejected, as 1769 described in section 7.3. The recommended value is 4 seconds. 1771 Shared Secret 1772 The shared secret is a value that is known by two communicating 1773 peers, and is used to generate the Integrity-Check-Value AVP. 1774 There is no default. 1776 11.0 Security Considerations 1778 The DIAMETER base protocol requires that two communicating peers 1779 exchange messages in a secure fashion. This document describes two 1780 security methods that can be used. The first requires no security at 1781 the application layer, but rather relies on an underlying security 1782 mechanism, such as IP Security. 1784 When IP Security is not available, or desirable, the DIAMETER 1785 protocol MAY use hop-by-hop security, which requires communicating 1786 peers to share a long-lived secret. Hop-by-Hop security provides 1787 replay protection by requiring that the communicating peers share a 1788 time source, such as an NTP server. Information of a sensitive 1789 nature, which MUST NOT be seen by any intermediate DIAMETER node MUST 1790 NOT be encrypted using hop-by-hop encryption. 1792 When the DIAMETER protocol is used in an inter-domain network, strong 1793 application level security MAY be required, such as non-repudiation. 1795 When the communicating peers do require this level of security either 1796 for legal or business purposes, the extension defined in [11] MAY be 1797 used. This security model provides AVP-level authentication, and the 1798 encryption mechanism is designed such that only the target host has 1799 the keying information required to decrypt the information. 1801 12.0 References 1803 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1805 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. 1807 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 1809 [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1810 1992. 1812 [5] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 1813 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 1814 13-061466-1. 1816 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 1817 Authentication", RFC 2104, January 1997. 1819 [7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 1820 Extension", draft-calhoun-diameter-nasreq-04.txt, IETF work in 1821 progress, July 2000. 1823 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu- 1824 ary 1999. 1826 [9] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- 1827 calhoun-diameter-framework-08.txt, IETF work in progress, June 1828 2000. 1830 [10] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 1831 calhoun-diameter-mobileip-09.txt, IETF work in progress, July 1832 2000. 1834 [11] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1835 Extension", draft-calhoun-diameter-strong-crypto-04.txt (work in 1836 progress), July 2000. 1838 [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considera- 1839 tions Section in RFCs", BCP 26, RFC 2434, October 1998 1841 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1842 Levels", BCP 14, RFC 2119, March 1997. 1844 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1845 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1846 RFC 2560, June 1999. 1848 [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension", 1849 draft-calhoun-diameter-accounting-07.txt, IETF work in progress, 1850 July 2000. 1852 [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 1853 2373, July 1998. 1855 [17] ISI, "Internet Protocol", RFC 791, September 1981. 1857 [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 1858 IPv6 and OSI, RFC 2030, October 1996. 1860 [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 1861 tructure Certificate and CRL Profile", RFC 2459, January 1999. 1863 [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1864 RFC 2477, January 1999. 1866 [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 1867 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 1868 in progress, June 2000. 1870 [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1871 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 1872 2000. 1874 [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1875 Authorization, and Accounting Requirements", draft-ietf- 1876 mobileip-aaa-reqs-03.txt, IETF work in progress, March 2000. 1878 [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1879 2279, January 1998. 1881 [25] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 1882 Haag, "DIAMETER Implementation Guidelines", draft-calhoun- 1883 diameter-impl-guide-03.txt, IETF work in progress, June 2000. 1885 [26] R. Stewart et al., "Simple Control Transmission Protocol", 1886 draft-ietf-sigtran-sctp-10.txt, IETF Work in Progress, June 1887 2000. 1889 [27] Postel, J. "Transmission Control Protocol", RFC 793, January 1890 1981. 1892 [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location 1893 Protocol, Version 2", RFC 2165, June 1999. 1895 [29] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- 1896 calhoun-diameter-res-mgmt-04.txt, IETF Work in Progress, July 1897 2000. 1899 13.0 Acknowledgements 1901 The authors would like to thank Nenad Trifunovic, Tony Johansson and 1902 Pankaj Patel for their participation in the Document Reading Party. 1904 The authors would also like to acknowledge the following people for 1905 their contribution in the development of the DIAMETER protocol: 1907 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1908 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 1909 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Stephen Farrell, 1910 Sumit Vakil, John R. Vollbrecht, Jeff Weisberg, Jon Wood and Glen 1911 Zorn 1913 14.0 Authors' Addresses 1915 Questions about this memo can be directed to: 1917 Pat R. Calhoun 1918 Network and Security Research Center, Sun Laboratories 1919 Sun Microsystems, Inc. 1920 15 Network Circle 1921 Menlo Park, California, 94025 1922 USA 1924 Phone: +1 650-786-7733 1925 Fax: +1 650-786-6445 1926 E-mail: pcalhoun@eng.sun.com 1928 Allan C. Rubens 1929 Tut Systems, Inc. 1930 220 E. Huron, Suite 260 1931 Ann Arbor, MI 48104 1932 USA 1933 Phone: +1 734-995-1697 1934 E-Mail: arubens@tutsys.com 1936 Haseeb Akhtar 1937 Wireless Technology Labs 1938 Nortel Networks 1939 2221 Lakeside Blvd. 1940 Richardson, TX 75082-4399 1941 USA 1943 Phone: +1 972-684-8850 1944 E-Mail: haseeb@nortelnetworks.com 1946 Erik Guttman 1947 Network and Security Research Center, Sun Laboratories 1948 Sun Microsystems, Inc. 1949 Eichhoelzelstr. 7 1950 74915 Waibstadt 1951 Germany 1953 Phone: +49-7263-911-701 1954 E-mail: erik.guttman@germany.sun.com 1956 15.0 Full Copyright Statement 1958 Copyright (C) The Internet Society (1999). All Rights Reserved. 1960 This document and translations of it may be copied and furnished to 1961 others, and derivative works that comment on or otherwise explain it 1962 or assist in its implementation may be prepared, copied, published 1963 and distributed, in whole or in part, without restriction of any 1964 kind, provided that the above copyright notice and this paragraph are 1965 included on all such copies and derivative works. However, this docu- 1966 ment itself may not be modified in any way, such as by removing the 1967 copyright notice or references to the Internet Society or other 1968 Internet organizations, except as needed for the purpose of develop- 1969 ing Internet standards in which case the procedures for copyrights 1970 defined in the Internet Standards process must be followed, or as 1971 required to translate it into languages other than English. The lim- 1972 ited permissions granted above are perpetual and will not be revoked 1973 by the Internet Society or its successors or assigns. This document 1974 and the information contained herein is provided on an "AS IS" basis 1975 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1976 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1977 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1978 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1979 FITNESS FOR A PARTICULAR PURPOSE.