idnits 2.17.1 draft-calhoun-diameter-12.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 43 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 44 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 14 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 190 has weird spacing: '...ges are sent,...' == Line 665 has weird spacing: '...invalid clea...' == Line 675 has weird spacing: '...eceived clea...' == Line 680 has weird spacing: '...eceived clea...' == Line 697 has weird spacing: '...eceived clea...' == (10 more instances...) == 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 1851, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1852, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1854, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1888, 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-00 -- 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-05 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-04 -- Possible downref: Normative reference to a draft: ref. '10' -- No information found for draft-calhoun-diameter-strong-security - is the name correct? -- 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-02 -- 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-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '21') -- No information found for draft-hiller-cdma2000-AAA - is the name correct? -- Possible downref: Normative reference to a draft: ref. '22' == Outdated reference: A later version (-04) exists of draft-ietf-mobileip-aaa-reqs-01 ** 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-00 -- Possible downref: Normative reference to a draft: ref. '25' Summary: 20 errors (**), 0 flaws (~~), 22 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-12.txt Allan C. Rubens 4 Date: December 1999 Tut Systems, Inc. 5 Haseeb Akhtar 6 Nortel Networks 7 Erik Guttman 8 Sun Microsystems, Inc. 10 DIAMETER Base Protocol 12 Status of this Memo 14 This document is an individual contribution for consideration by the 15 AAA Working Group of the Internet Engineering Task Force. Comments 16 should be submitted to the diameter@ipass.com mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at: 37 http://www.ietf.org/shadow.html. 39 Copyright (C) The Internet Society 1999. All Rights Reserved. 41 Abstract 43 The DIAMETER base protocol is intended to provide a AAA framework for 44 Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message 45 format, transport, error reporting and security services to be used 46 by all DIAMETER extensions and MUST be supported by all DIAMETER 47 implementations. 49 Table of Contents 51 1.0 Introduction 52 1.1 Requirements language 53 1.2 Terminology 54 2.0 Protocol Overview 55 2.1 Header Format 56 2.1.1 ZLB Message 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 Command-Code AVP 64 2.3.2 Host-IP-Address AVP 65 2.3.3 Host-Name AVP 66 2.4 The art of AVP Tagging 67 2.5 State Machine 68 2.6 Device-Reboot-Ind (DRI) Command 69 2.6.1 Vendor-Name AVP 70 2.6.2 Firmware-Revision AVP 71 2.6.3 Reboot-Type AVP 72 2.6.4 Reboot-Time AVP 73 2.6.5 Extension-Id AVP 74 2.7 Device-Watchdog-Ind (DWI) Command 75 3.0 "User" Sessions 76 3.1 Session-Id AVP 77 3.2 Session-Timeout AVP 78 3.3 User-Name AVP 79 4.0 Reliable Transport 80 4.1 Flow Control 81 4.1.1 Receive-Window AVP 82 4.2 Peer failure recovery 83 5.0 Error Reporting 84 5.1 Message-Reject-Ind (MRI) Command 85 5.1.1 Failed-AVP AVP 86 5.2 Result-Code AVP 87 6.0 DIAMETER Message Routing 88 6.1 Message Proxying 89 6.1.1 Proxy-State AVP 90 6.1.2 Destination-NAI AVP 92 6.2 Message Redirection 93 6.2.1 Redirected-Host AVP 94 7.0 DIAMETER Message Security 95 7.1 Hop-by-Hop Security 96 7.1.1 Integrity-Check-Value AVP 97 7.1.2 Encrypted-Payload AVP 98 7.1.2.1 MD5 Payload Hiding 99 7.2 Nonce AVP 100 7.3 Timestamp AVP 101 8.0 IANA Considerations 102 8.1 AVP Attributes 103 8.2 Command Code AVP Values 104 8.3 Extension Identifier Values 105 8.4 Result-Code AVP Values 106 8.5 Integrity-Check-Value AVP Transform Values 107 8.6 Reboot-Type AVP Values 108 8.7 AVP Header Bits 109 9.0 Open Issues 110 10.0 DIAMETER protocol related configurable parameters 111 11.0 Security Considerations 112 12.0 References 113 13.0 Acknowledgements 114 14.0 Author's Addresses 115 15.0 Full Copyright Statement 117 1.0 Introduction 119 The DIAMETER protocol allows peers to exchange a variety of messages. 120 The base protocol provides the following facilities: 122 - Delivery of AVPs (attribute value pairs) 123 - Capabilities negotiation, as required in [20] 124 - Error notification 125 - Sequenced in-order reliable delivery of UDP datagram messages 126 - Support for congestion control (receiver window), as required in 127 [21] 128 - Timely detection of failed or unresponsive peers, as required in 129 [21, 22, 23] 130 - Extensibility, through addition of new commands and AVPs, as 131 required in [21] 133 All data delivered by the protocol is in the form of an AVP. Some of 134 these AVP values are used by the DIAMETER protocol itself, while 135 others deliver data associated with particular applications which 136 employ DIAMETER. AVPs may be added arbitrarily to DIAMETER messages, 137 so long as the required AVPs are included and AVPs which are 138 explicitly excluded are not included. AVPs are used by base DIAMETER 139 protocol to support the following required features: 141 - If application-level security is required, all messages MUST 142 include an Integrity Check Vector (ICV). If the ICV is present, 143 the message MUST also carry a timestamp and a nonce to aid in 144 providing replay protection. 145 - To carry user authentication information, for the purposes of 146 enabling the DIAMETER server to authenticate the user. 147 - To allow authorization information to be exchanged for a 148 particular user's session between a DIAMETER client and server. 149 - To exchange resource usage information, which MAY be used for 150 accounting purposes, capacity planning, etc. 152 The DIAMETER base protocol provides the minimum requirements needed 153 for an AAA transport protocol, as required by NASREQ [21], Mobile IP 154 [22, 23], and ROAMOPS [20]. The base protocol is not intended to be 155 used by itself, and must be used with an application-specific 156 extension, such as Mobile IP. The DIAMETER protocol was heavily 157 inspired and builds upon the tradition of the RADIUS [1] protocol. 159 Any node can initiate a request. In that sense, DIAMETER is a peer to 160 peer protocol. In this document, a DIAMETER client is the device that 161 normally initiates a request for authentication and/or authorization 162 of a user. A DIAMETER server is the device that performs the actual 163 authentication and/or authorization of the user based on some 164 profile. A server MAY issue an unsolicited message to a client, but 165 this is typically not a request for authentication and/or 166 authorization, but rather for something else, such as an accounting 167 update. 169 1.1 Requirements language 171 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 172 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 173 described in [13]. 175 1.2 Terminology 177 Refer to [9] for terminology used in this document. 179 2.0 Protocol Overview 181 The base DIAMETER protocol is never used on its own. It is always 182 extended for a particular application. Four extensions to DIAMETER 183 are defined by companion documents: NASREQ [7], Mobile IP [10], 184 Accounting Extension [15], Strong Security [11]. These options are 185 introduced in this document but specified elsewhere. Additional 186 extensions to DIAMETER may be defined in the future (see Section 187 8.3). 189 The base DIAMETER protocol concerns itself with capabilities 190 negotiation, and how messages are sent, resent and how peers may 191 eventually be abandoned. The base protocol also defines certain 192 rules which apply to all exchanges of messages between DIAMETER 193 peers. It is important to note that the base protocol provides an 194 optional application-level security AVPs (Integrity-Check-Value) 195 which MAY be used in absence of an underlying security protocol (e.g. 196 IP Security). 198 Communication between DIAMETER peers begins with one peer sending a 199 message to another DIAMETER peer. The set of AVPs included in the 200 message is determined by a particular application of or extension to 201 DIAMETER. (We will refer to this as the DIAMETER extension). One 202 AVP which is included in the initial communication is the Session-Id. 204 The communicating party may accept or reject the request which 205 contains a new Session-Id, or return Result-Code if the request 206 cannot be processed. The behavior of the communicating peer depends 207 on the DIAMETER extension employed. 209 Exchanges of messages are either request/reply oriented, or in some 210 special cases, do not require replies. All such messages which do 211 not require replies (or acknowledgments) have names which end with 212 '-Ind' (short for Indication). All messages require a transport 213 level acknowledgement, either through a Zero Length Body (ZLB), or by 214 piggybacking an acknowledgement in a non-ZLB message. 216 Communicating DIAMETER peers retain state relating to transport 217 (sequence numbers and the like). This state information may be 218 discarded when the communicating peer is determined to be 219 unreachable. This occurs when the peer does not acknowledge receipt 220 of a DIAMETER message that has been retransmitted a maximum number of 221 times. The Device-Watchdog-Ind is used to pro-actively probe peers to 222 ensure that communication is still possible. 224 Freeing the transport state associated with a communication with a 225 DIAMETER peer is entirely independent of freeing session state 226 (associated with a Session-Id). The latter MUST only be done 227 according to rules established in a particular extension/application 228 of DIAMETER. 230 DIAMETER extensions SHOULD define an explicit exchange of messages 231 which allow a peer to inform the other party that a session has been 232 terminated. 234 2.1 Header Format 236 The base DIAMETER protocol is run over UDP port 1812. Implementations 237 MAY send packets from any source port, but MUST be prepared to 238 receive packets on port 1812. When a request is received, in order to 239 send a reply, the source and destination ports in the reply are 240 reversed. 242 A given DIAMETER process SHOULD use the same port number to send all 243 messages to aid in identifying which process sent a given message. 244 More than one DIAMETER process MAY exist within a single host, so the 245 sender's port number is needed to discriminate them. 247 A summary of the DIAMETER data format is shown below. The fields are 248 transmitted in network byte order. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |RADIUS PCC=254|Flags|A|W| Ver | Message Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Identifier | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Next Send (Ns) | Next Received (Nr) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | AVPs ... 260 +-+-+-+-+-+-+-+-+-+-+-+-+- 262 RADIUS PCC 263 The RADIUS Packet Compatibility Code (PCC) field is a one octet 264 field which is used for backward compatibility with RADIUS and 265 MUST be set to 254. In order to easily distinguish DIAMETER 266 messages from RADIUS, the value of 254 has been reserved and 267 allows implementations to support both protocols by using the 268 first octet in the header. 270 Flags 271 The Message Flags field is five bits, and is used in order to 272 identify any options. This field MUST be initialized to zero. The 273 'W' bit (Window-Present) is set when the Next Send (Ns) and Next 274 Received (Nr) fields are present in the header. The 'A' bit is set 275 to indicate that the message is an acknowledgement only (ZLB) and 276 does not contain a Command-Code AVP following the header. Note 277 that the Security AVPs, if required, MUST still be present within 278 a ZLB. 280 In the event that the DIAMETER protocol is implemented over a 281 reliable transport, the 'W' and 'A' bits MUST NOT be set. 283 Version 284 This Version field MUST be set to 1 to indicate DIAMETER Version 285 1. 287 Message Length 288 The Message Length field is two octets and indicates the length of 289 the DIAMETER message including the header fields. DIAMETER 290 implementations MUST be ready to receive UDP packets of at least 291 8192 octets in length. 293 Identifier 294 The Identifier field is four octets, and aids in matching requests 295 and replies. The sender MUST ensure that the identifier in a 296 message is locally unique (to the sender) at any given time, and 297 MAY attempt to ensure that the number is unique across reboots. 299 The identifier is normally a monotonically increasing number, 300 whose start value was randomly generated. DIAMETER servers should 301 consider a message to be unique by examining the source address, 302 source port and Identifier field of the message. 304 Next Send 305 This field is present when the Window-Present bit is set in the 306 header flags. The Next Send (Ns) is copied from the send sequence 307 number state variable, Ss, at the time the message is transmitted. 308 The variable Ss is incremented after copying into the header if 309 the message is not a ZLB. 311 Next Received 312 This field is present when the Window-Present bit is set in the 313 header flags. Nr is copied from the receive sequence number state 314 variable, Sr, and indicates the sequence number, Ns, +1 of the 315 highest (modulo 2^16) in-sequence message received. See section 316 4.0 for more information. 318 AVPs 319 AVPs is a method of encapsulating information relevant to the 320 DIAMETER message. See section 2.2 for more information on AVPs. 322 2.1.1 ZLB Message Format 324 Zero Length Body (ZLB) messages are used to explicitly acknowledge 325 one or more DIAMETER message, and contain no additional 326 Authentication, Authorization or Accounting related AVPs. ZLB 327 messages must contain authentication AVPs, otherwise attacks could be 328 mounted against DIAMETER nodes. 330 The format of a ZLB message is as follows: 332 ::= 333 [ 334 335 ] 337 2.2 AVP Format 339 DIAMETER AVPs carry specific authentication, accounting and 340 authorization information, security information as well as 341 configuration details for the request and reply. 343 Some AVPs MAY be listed more than once. The effect of this is AVP 344 specific, and is specified in each case by the AVP description. 346 Each AVP of type 'string' and 'data' MUST be padded to align on a 32 347 bit boundary, while other AVP types align naturally. Zero bytes are 348 added to the end of the AVP value till a word boundary is reached. 349 The length of the padding is not reflected in the AVP Length field. 351 2.2.1 AVP Header 353 The AVP format is shown below and MUST be sent in network byte order. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | AVP Code | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | AVP Length | Reserved |P|T|V|R|M| 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Vendor ID (opt) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Tag (opt) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Data ... 367 +-+-+-+-+-+-+-+-+ 369 AVP Code 370 The AVP Code identifies the attribute uniquely. If the Vendor- 371 Specific bit is set, the AVP Code is allocated from the vendor's 372 private address space. 374 The first 256 AVP numbers are reserved for backward compatibility 375 with RADIUS and are to be interpreted as per RADIUS [1]. AVP 376 numbers 256 and above are used for DIAMETER, which are allocated 377 by IANA (see section 8.1). 379 AVP Length 380 The AVP Length field is two octets, and indicates the length of 381 this Attribute including the AVP Code, AVP Length, AVP Flags, 382 Reserved, the Tag and Vendor ID fields if present and the AVP 383 data. If a message is received with an Invalid attribute length, 384 the message SHOULD be rejected. 386 AVP Flags 387 The AVP Flags field informs the DIAMETER host how each attribute 388 must be handled. Note that subsequent DIAMETER extensions MAY 389 define bits to be used within the AVP Header, and an unrecognized 390 bit should be considered an error. The 'R' and the reserved bits 391 should be set to 0 and ignored on receipt, while the 'P' bit is 392 defined in [11]. 394 The 'M' Bit, known as the Mandatory bit, indicates whether support 395 of the AVP is required. If an AVP is received with the 'M' bit 396 enabled and the receiver does not support the AVP, the message 397 MUST be rejected. AVPs without the 'M' bit enabled are 398 informational only and a receiver that receives a message with 399 such an AVP that is not supported MAY simply ignore the AVP. 401 The 'V' bit, known as the Vendor-Specific bit, indicates whether 402 the optional Vendor ID field is present in the AVP header. When 403 set the AVP Code belongs to the specific vendor code address 404 space. 406 The 'T' bit, known as the Tag bit, is used to group sets of AVPs 407 together. Grouping of AVPs is necessary when more than one AVP is 408 needed to express a condition. If this bit is set, the optional 409 Tag field will be present. 411 Unless otherwise noted, AVPs will have the following default AVP 412 Flags field settings: 413 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. The 'T' 414 bit MAY be set. 416 2.2.2 Optional Header Elements 418 The AVP Header consists of several optional fields. These fields are 419 only present if their respective bit-flags are enabled. 421 Vendor ID 422 The Vendor ID field is present in the 'V' bit is set in the AVP 423 Flags field. The optional four octet Vendor ID field contains the 424 IANA assigned "SMI Network Management Private Enterprise Codes" 425 [2] value, encoded in network byte order. Any vendor wishing to 426 implement DIAMETER extensions MUST use their own Vendor ID along 427 with private Attribute values, guaranteeing that they will not 428 collide with any other vendor's extensions, nor with future IETF 429 extensions. 431 A vendor ID value of zero (0) corresponds to the IETF adopted AVP 432 values, as managed by the IANA. Since the absence of the vendor ID 433 field implies that the AVP in question is not vendor specific, 434 implementations SHOULD not use the zero (0) vendor ID. 436 Tag 437 The Tag field is four octet in length and is intended to provide a 438 means of grouping attributes in the same message which refer to 439 the same set. If the Tag field is unused, the 'T' bit MUST NOT be 440 set. 442 2.2.3 AVP Value Formats 444 The Data field is zero or more octets and contains information 445 specific to the Attribute. The format and length of the Data field is 446 determined by the AVP Code and AVP Length fields. Note that messages 447 which are larger than the path MTU will cause IP fragmentation and 448 messages SHOULD be kept to that size wherever possible. In any case 449 UDP limits messages to 2^16 bytes. 451 The format of the value field MAY be one of seven data types. 453 Data 454 The data contains a variable length of arbitrary data. Unless 455 otherwise noted, the AVP Length field MUST be set to at least 456 9. 458 String 459 The data contains a non-NULL terminated variable length string 460 using the UTF-8 [24] character set. Unless otherwise noted, 461 the AVP Length field MUST be set to at least 9. 463 Address 464 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most 465 significant octet first. The format of the address (IPv4 or 466 IPv6) is determined by the length. If the attribute value is an 467 IPv4 address, the AVP Length field MUST be 12, otherwise the 468 AVP Length field MUST be set to 24 for IPv6 addresses. 470 Integer32 471 32 bit value, in network byte order. The AVP Length field MUST 472 be set to 12. 474 Integer64 475 64 bit value, in network byte order. The AVP Length field MUST 476 be set to 16. 478 Time 479 32 bit unsigned value, In network byte order, and contains the 480 seconds since 00:00:00 GMT, January 1, 1900. The AVP Length 481 field MUST be set to 12. 483 Complex 484 The complex data type is reserved for AVPs that includes 485 multiple information fields, and therefore do not fit within 486 any of the AVP types defined above. Complex AVPs MUST provide 487 the data format, and the expected length of the AVP. 489 2.2.4 DIAMETER Base Protocol AVPs 491 The following table describes the DIAMETER AVPs defined in the base 492 protocol, their AVP Code values, types, possible flag values and 493 whether the AVP MAY be encrypted. 495 +---------------------+ 496 | AVP Flag rules | 497 |----+-----+----+-----|----+ 498 AVP Section Value | | |SHLD| MUST|Encr| 499 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Cand| 500 -----------------------------------------|----+-----+----+-----|----| 501 User-Name 1 3.3 String | | | | | Y | 502 Host-IP-Address 4 2.3.2 Address | M | | | T,V | N | 503 Session-Timeout 27 3.2 Integer32| | | | | Y | 504 Host-Name 32 2.3.3 String | M | | | T,V | N | 505 Proxy-State 33 6.1.1 Complex | M | | | T,V | N | 506 Command-Code 256 2.3.1 Integer32| M | V | | T | N | 507 Extension-Id 258 2.6.5 Integer32| | | | | Y | 508 Integrity-Check 259 7.1.1 Complex | | | | | N | 509 -Value | | | | | | 510 Encrypted- 260 7.1.2 Complex | | | | | N | 511 Payload | | | | | | 512 Nonce 261 7.2 Data | | | | | N | 513 Timestamp 262 7.3 Time | | | | | N | 514 Session-Id 263 3.3 Data | | | | | Y | 515 Vendor-Name 266 2.6.1 String | | | |T,V,M| Y | 516 Firmware 267 2.6.2 Integer32| | | |T,V,M| Y | 517 -Revision | | | | | | 518 Result-Code 268 5.2 Complex | | | | | N | 519 Destination-NAI 269 6.1.2 String | | | | | Y | 520 Reboot-Type 271 2.6.3 Integer32| | | | | N | 521 Reboot-Time 272 2.6.4 Integer32| | | | | N | 522 Failed-AVP 279 5.1.1 Data | | | | | Y | 523 Receive-Window 277 4.1.1 Integer32| | | | | Y | 524 Redirect-Host 278 6.2.1 Address | | | | | Y | 526 2.2.5 Standard DIAMETER Extension AVPs 528 The following AVPs are defined in standard DIAMETER extensions. 530 AVP Name Code Ref AVP Name Code Ref AVP Name Code Ref 531 ------------- ---- --- ------------ ---- --- ------------ ---- ---- 532 User-Password 2 [7] Framed- 38 [7] MN-FA- 322 [10] 533 CHAP-Password 3 [7] Appletalk- Challenge- 534 NAS-Port 5 [7] Network Length 535 Service-Type 6 [7] Framed- 39 [7] MN-FA-Response 323 [10] 536 Framed-Protocol 7 [7] Appletalk- Mobile-Node- 333 [10] 537 Framed-IP- 8 [7] Zone Address 538 Address CHAP-Challenge 60 [7] Home-Agent- 334 [10] 539 Framed-IP- 9 [7] NAS-Port-Type 61 [7] Address 540 Netmask Port-Limit 62 [7] Previous-FA- 335 [10] 541 Framed-Routing 10 [7] Login-LAT-Port 63 [7] NAI 542 Filter-Id 11 [7] Tunnel-Type 64 [7] MN-AAA-SPI 336 [10] 543 Framed-MTU 12 [7] Tunnel-Medium- 65 [7] Foreign-Home- 337 [10] 544 Framed- 13 [7] Type Agent- 545 Compression Tunnel-Client- 66 [7] Available 546 Login-IP-Host 14 [7] Endpoint Filter-Rule 400 [7] 547 Login-Service 15 [7] Tunnel-Server- 67 [7] Request-Type 401 [7] 548 Login-TCP-Port 16 [7] Endpoint EAP-Payload 402 [7] 549 Reply-Message 18 [7] Tunnel-Password 69 [7] Accounting- 480 [15] 550 Callback-Number 19 [7] Tunnel-Private- 81 [7] Record-Type 551 Callback-Id 20 [7] Group-ID ADIF-Record 481 [15] 552 Framed-IP-Route 22 [7] Tunnel- 82 [7] Accounting- 482 [15] 553 Framed-IPX- 23 [7] Assignment-ID Interim- 554 Route Tunnel- 83 [7] Interval 555 Idle-Timeout 28 [7] Preference Accounting- 483 [15] 556 Called-Station- 30 [7] Tunnel-Client- 90 [7] Delivery- 557 Id Auth-ID Interval 558 Calling- 31 [7] Tunnel-Server- 91 [7] Accounting- 484 [15] 559 Station-Id Auth-ID Delivery- 560 Login-LAT- 34 [7] CMS-Data 310 [11] Max-Delay 561 Service MIP- 320 [10] Accounting- 485 [15] 562 Login-LAT-Node 35 [7] Registration- Record- 563 Login-LAT-Group 36 [7] Request Number 564 Framed- 37 [7] MIP- 321 [10] 565 Appletalk- Registration- 566 Link Reply 568 2.3 Mandatory AVPs 570 This section defines the DIAMETER AVPs that MUST be present in all 571 DIAMETER messages, with the exception of the ZLB. 573 2.3.1 Command-Code AVP 575 The Command-Code AVP (AVP Code 256) is of type Integer32 and MUST be 576 the first AVP following the DIAMETER header (except for ZLB 577 messages). A DIAMETER message MUST have at most one Command-Code 578 AVP, and it is used in order to communicate the command associated 579 with the message. The Command Code 32-bit address space is managed 580 by IANA (see section 8.2). 582 The following Command Codes are currently defined in the DIAMETER 583 protocol: 585 Command-Name Abbrev. Code Reference 586 -------------------------------------------------------- 587 Device-Reboot-Ind DRI 257 2.6 588 Device-Watchdog-Ind DWI 258 2.7 589 Message-Reject-Ind MRI 259 5.1 590 AA-Mobile-Node-Request AMR 260 [10] 591 AA-Mobile-Node-Answer AMA 261 [10] 592 Home-Agent-MIP-Request HAR 262 [10] 593 Home-Agent-MIP-Answer HAA 263 [10] 594 Mobile-Node-Terminate-Ind MTI 264 [10] 595 AA-Request AAR 265 [7] 596 AA-Answer AAA 266 [7] 597 AA-Challenge-Ind ACI 267 [7] 598 DIAMETER-EAP-Request DER 268 [7] 599 DIAMETER-EAP-Answer DEA 269 [7] 600 DIAMETER-EAP-Ind DEI 270 [7] 601 Accounting-Request ACR 271 [15] 602 Accounting-Answer ACA 272 [15] 603 Accounting-Poll-Ind ACP 273 [15] 605 2.3.2 Host-IP-Address AVP 607 The Host-IP-Address AVP (AVP Code 4) [1] is of type Address and is 608 used to inform a DIAMETER peer of the sender's IP address. All 609 DIAMETER messages, except for ZLBs, MUST include either the Host-IP- 610 Address or the Host-Name (section 2.3.3) AVPs, or both. 612 2.3.3 Host-Name AVP 614 The Host-Name AVP (AVP Code 32) [1] is of type String, and is used to 615 inform a DIAMETER peer of the sender's identity. All DIAMETER 616 messages, except for ZLBs, MUST include either the Host-IP-Address or 617 the Host-Name (section 2.3.2) AVPs, or both. This AVP contains the 618 host name of the originator of the DIAMETER message that MUST follow 619 the NAI [8] naming conventions. 621 2.4 The art of AVP Tagging 623 The AVP Header provides the 'T' bit, which is used to group AVPs 624 together. All AVPs with the same tag value are part of the same 625 "group", and there are no guidelines or rules on which tag values are 626 used. The base protocol defines the Redirect-Host AVP (see section 627 6.2.1), and [11] defines how the associated certificate MAY be 628 carried within the DIAMETER protocol. This allows a single request to 629 include information about more than one host. In the case where 630 multiple AVPs are needed to indicate a specific authorization "rule" 631 tagging is appropriate. In some cases, more than one such rule MAY be 632 present, and the tagging mechanism allows the sets of AVPs to be 633 easily grouped. 635 Some Command Codes require certain AVPs to be tagged and use the '(' 636 and ')' characters in the BNF command definition, such as: 637 ::= 638 639 ( 640 641 ) 643 2.5 State Machine 645 A DIAMETER node initially considers all known peers to be in the 646 closed state, and should not process any DIAMETER message with the 647 exception of the Device-Reboot-Ind (DRI). Once the DIAMETER peer is 648 set to the open state, any DIAMETER message may be accepted and 649 processed. This section provides the DIAMETER base protocol state 650 machine. 652 If at any time no transport level acknowledgement is received and the 653 message was retransmitted the maximum number of times, the session 654 with the peer MUST be closed, and all associated state with the peer 655 MUST be freed. 657 State Event Action New State 658 ----- ----- ------ --------- 659 closed Local Open send DRI wait-ack1 660 Request 662 closed receive DRI send ACK wait-ack2 663 send DRI 665 closed receive invalid cleanup closed 666 DRI 668 wait-ack1 receive ACK accept Incoming wait-ack1 669 Messages 671 wait-ack1 receive DRI send ACK open 672 Accept Incoming 673 Messages 675 wait-ack1 no ACK received cleanup closed 677 wait-ack2 received ACK Accept Incoming open 678 Messages 680 wait-ack2 no ACK received cleanup closed 682 open receive DRI send ACK wait-ack2 683 Rebooted send DRI 685 open receive DRI cleanup closed 686 Imminent-Reboot 688 open receive DWI send ACK open 690 open receive other send ACK open 691 messages 693 open inactivity period send DWI open 694 hits watchdog 695 timer 697 open no ACK received cleanup closed 699 2.6 Device-Reboot-Ind (DRI) Command 701 A DIAMETER device sends the Device-Reboot-Ind message, by including 702 the Command-Code AVP with a value of 257, to inform a peer either of 703 an upcoming reboot, or that it has just rebooted. The Reboot-Type AVP 704 MUST be present and indicates the type of reboot associated with this 705 command. Note that a DIAMETER device should only send this message 706 when it is able to receive network traffic. 708 The receiver of a DRI message with the Reboot-Type AVP set to 709 REBOOT_IMMINENT SHOULD make an attempt to send packets to an 710 alternate peer, if one is available. The optional Reboot-Time AVP 711 will contain an estimate of how long before the peer will be ready to 712 re-establish communication. In the case of a software implementation 713 (server) running on a general purpose operating system, the Reboot- 714 Time AVP will probably not be present since it is possible that the 715 DIAMETER server has been stopped and it is not possible to know how 716 long before (and if) it will be restarted. 718 The DRI message is also used for capabilities negotiation, such as 719 the supported protocol version number, and the locally supported 720 extensions. The receiver uses the extensions advertised in order to 721 determine whether it SHOULD send certain application-specific 722 DIAMETER commands. A DIAMETER node MUST retain the supported 723 extensions in order to ensure that unrecognized commands and/or AVPs 724 are not sent to a peer. Note that in a proxy environment, it is still 725 possible for this problem to occur, and the DIAMETER base protocol 726 provides this error reporting message. 728 Upon reboot, the host MUST issue a DRI message with the Reboot-Type 729 AVP set to REBOOTED to all configured peers. If a peer is no longer 730 reachable, a DIAMETER device SHOULD periodically transmit a DRI until 731 an acknowledgement is received. The retransmission timer SHOULD be 732 different from the retransmission timer used when communication has 733 been established, and SHOULD be configurable. 735 Upon receipt of this message the peer's Ss and Sr variables MUST be 736 reset. It is possible for this message to be received outside the 737 window (Ns and Nr set to zero) when it follows a reboot. 739 The DIAMETER Reboot-Ind message does not require a reply. The message 740 is acknowledged using DIAMETER's reliable transport. See [25] for 741 more information. 743 Message Format 745 ::= 746 747 { || 748 } 749 750 751 752 [] 753 [] 754 [] 755 [ 756 757 ] 759 2.6.1 Vendor-Name AVP 761 The Vendor-Name AVP (AVP Code 266) is of type String and is used to 762 inform a DIAMETER peer of the Vendor Name of the DIAMETER device. 763 This MAY be used in order to know which vendor specific attributes 764 may be sent to the peer. It is also envisioned that the combination 765 of the Vendor-Name and the Firmware-Revision (section 2.6.2) AVPs MAY 766 provide very useful debugging information. 768 2.6.2 Firmware-Revision AVP 770 The Firmware-Revision AVP (AVP Code 267) is of type Integer32 and is 771 used to inform a DIAMETER peer of the firmware revision of the 772 issuing device. 774 For devices that do not have a firmware revision (general purpose 775 computers running DIAMETER software modules, for instance), the 776 revision of the DIAMETER software module may be reported instead. 778 2.6.3 Reboot-Type AVP 780 The Reboot-Type AVP (AVP Code 271) is of type Integer32 and MUST be 781 present in the Device-Reboot-Indication message. This AVP contains an 782 indication of the type of reboot that has or will occur. The 783 following values are currently supported: 785 REBOOT_IMMINENT 1 786 When the Reboot-Type AVP is set to this value it is an 787 indication that the DIAMETER peer is about to reboot and should 788 not be sent any additional DIAMETER messages after the 789 acknowledgement for this Device-Reboot-Ind message. 791 REBOOTED 2 792 When the Reboot-Type AVP is set to this value it is an 793 indication that the DIAMETER peer has recently rebooted and is 794 ready to accept new DIAMETER messages. 796 2.6.4 Reboot-Time AVP 798 The Reboot-Time AVP (AVP Code 272) is of type Integer32 and MAY be 799 present in the DRI. The value of this AVP indicates the number of 800 seconds before the issuer expects to be ready to receive new DIAMETER 801 messages. This AVP MUST only be present when the Reboot-Type AVP is 802 set to REBOOT_IMMINENT. The value indicated by this AVP should be 803 used as an estimate and is not a hard rule. 805 2.6.5 Extension-Id AVP 807 The Extension-Id AVP (AVP Code 258) is of type Integer32 and is used 808 in order to identify a specific DIAMETER extension. This AVP is used 809 in the Device-Reboot-Ind command in order to inform the peer what 810 extensions are locally supported. 812 Each DIAMETER extension draft MUST have an Extension-Id assigned to 813 it by the IANA (see section 8.3). The base protocol does not require 814 an Extension-Id since its support is mandatory. 816 There MAY be more than one Extension-Id AVP within a DIAMETER 817 Device-Reboot-Ind message. The following values are recognized: 819 NASREQ 1 [7] 820 Strong Security 2 [11] 821 Mobile-IP 4 [10] 822 Accounting 5 [15] 824 2.7 Device-Watchdog-Ind (DWI) Command 826 The Device-Watchdog-Ind (DWI), indicated by the Command-Code AVP set 827 to 258, is OPTIONAL and is used as a keepalive mechanism between two 828 DIAMETER peers. If implemented, it SHOULD be sent during after a 829 configurable period of inactivity. Communicating peers are not 830 required to have the same DWI timer values set, as each entity MAY 831 have different requirements. 833 A DIAMETER node MAY use this mechanism to ensure that fail-over to an 834 alternate server occurs in the absence of AAA traffic. This pro- 835 active approach may minimize the possible latency involved in the 836 fail-over that would otherwise occur. 838 The lower the timer value is set to, the quicker a host will pro- 839 actively detect that a peer is no longer reachable. However, the 840 timer SHOULD NOT be set to a value that is considered too low (e.g. 2 841 seconds), since it will generate considerable traffic. 843 The DIAMETER Device-Watchdog-Ind message does not require a reply. 844 The message is acknowledged using DIAMETER's reliable transport. See 845 [25 for more information. 847 Message Format 849 ::= 850 851 { || 852 } 853 [ 854 855 ] 857 3.0 "User" Sessions 859 When a user requests access to the network, a DIAMETER client issues 860 an authentication and authorization request to its local server. The 861 request contains a Session-Id AVP, which is used in subsequent 862 messages (e.g. subsequent authorization, accounting, etc) relating to 863 the user's session. The Session-Id AVP is a means for the client and 864 servers to correlate a DIAMETER message with a user session. 866 When a DIAMETER server authorizes a user to use network resources, it 867 SHOULD add the Session-Timeout AVP to the response. The Session- 868 Timeout AVP defines the maximum amount of time a user MAY make use of 869 the resources before another authorization request is to be 870 transmitted to the server. If the server does not receive another 871 authorization request before the timeout occurs, it SHOULD release 872 any state information related to the user's session. Note that the 873 Session-Timeout AVP implies how long the DIAMETER server is willing 874 to pay for the services rendered, therefore a DIAMETER client SHOULD 875 NOT expect payment for services rendered past the session expiration 876 time. 878 The base protocol does not include any authorization request 879 messages, since these are largely application-specific and are 880 defined in a DIAMETER protocol extension document. Such extensions 881 SHOULD provide a message that allows a client to inform a server that 882 the user's session has been released. This would enable the server to 883 free state information instead of having to wait for the timeout to 884 occur. 886 3.1 Session-Id AVP 888 The Session-Id AVP (AVP Code 263) is of type Data and is used to 889 identify a specific session (see section 3.0). All messages 890 pertaining to a specific session MUST include only one Session-Id AVP 891 and the same value MUST be used throughout the life of a session. 892 When present, the Session-Id SHOULD appear immediately following the 893 Command-Code AVP. 895 For messages that do not pertain to a specific session, multiple 896 Session-Id AVPs MAY be present as long as the 'T' bit is set. 898 The Session-Id MUST be globally unique at any given time since it is 899 used by the server to identify the session (or flow). The format of 900 the session identifier SHOULD be as follows: 902 904 The monotonically increasing 32 bit value SHOULD NOT start at zero 905 upon reboot, but rather start at a random value. This will minimize 906 the possibility of overlapping Session-Ids after a reboot. 907 Alternatively, an implementation MAY keep track of the increasing 908 value in non-volatile memory. The optional value is implementation 909 specific but may include a modem's device Id, a layer 2 address, 910 timestamp, etc. 912 The session Id is created by the DIAMETER device initiating the 913 session, which in most cases is done by the client. Note that a 914 Session-Id MAY be used by more than one extension (e.g. 915 authentication for a specific service and accounting, both of which 916 have separate extensions). 918 3.2 Session-Timeout AVP 920 The Session-Timeout AVP (AVP Code 27) [1] is of type Integer32 and 921 contains the maximum number of seconds of service to be provided to 922 the user before termination of the session. A value of zero means 923 that this session has an unlimited number of seconds before 924 termination. 926 This AVP MAY be provided by the client as a hint of the maximum 927 duration that it is willing to accept. However, the server DOES NOT 928 have to observe the hint and MAY return any value. A value of zero 929 provided by a client DOES NOT imply that service is being terminated. 931 3.3 User-Name AVP 933 The User-Name AVP (AVP Code 1) [1] is of type String and contains the 934 User-Name in a format consistent with the NAI specification [8]. All 935 DIAMETER systems SHOULD support usernames of at least 72 octets in 936 length. 938 4.0 Reliable Transport 940 This section provides a detailed overview of how DIAMETER is reliably 941 transported over UDP. DIAMETER provides its own reliable transport 942 due to its unique requirements, which include: 944 - Rapid discovery of the failure of a communicating peer. 945 - Transactions of few messages will be the norm, so the TCP slow 946 start algorithm is not appropriate. 947 - The retransmission scheme required is more aggressive than TCP 948 provides. 950 4.1 Flow Control 952 The DIAMETER header contains two fields used for reliable transport: 953 Nr (Next Received) and Ns (Next Send). The sequence number state for 954 each peer is represented (for clarity of discussion) as Sr (the next 955 in-sequence message expected to be received) and Ss (the next in- 956 sequence message to be sent). Sr and Ss are initialized to 0. 958 The sequence number is a free ranging counter modulo 65536. For 959 purposes of detecting duplication, a received sequence value is 960 considered less than or equal to the last received value if its value 961 lies in the range of the last value and its 32767 successor values. 962 For example if the last received sequence number was 15, the packets 963 received with Ns values in the range 32783..65535, or 0..15 would be 964 considered duplicates. Duplicate messages are silently discarded. 966 ZLB messages are used to acknowledge DIAMETER messages to the 967 communicating peer. Each subsequent non-ZLB message is sent with a 968 sequence number incremented by one (modulo 2^16). The following rules 969 apply: 971 - When a non-ZLB message is received with a Ns value which matches 972 the peer's Sr value, Sr is incremented by one. Sr is not 973 modified if a message is received with a Ns value greater than 974 the current Sr value. 976 - In messages which are sent to a peer, Nr is set to reflect one 977 higher than the Ns value of the highest (module 2^16) in-order 978 message received from the peer. 980 - Every time a peer sends a non-ZLB message, it sends the message 981 with Ns set to the current value of Ss. The value of Ss for 982 that peer is then incremented by one (modulo 2^16). 984 - Every time a peer receives an in-order non-ZLB message, the 985 receiving peer must increment its Sr value. The peer MUST 986 acknowledge the message, either by sending a ZLB message with 987 the updated Nr value, or by piggybacking the acknowledgement in 988 any outgoing message sent to the communicating peer. In this 989 piggybacked message, the Nr field will be set to its updated 990 value. The implementation guidelines [25] defines an OPTIONAL 991 algorithm for delaying acknowledgments, to wait for outgoing 992 messages to piggyback acknowledgements on. 994 - Messages which are sent MUST be queued and retransmitted till 995 the peer sends an acknowledgement. Messages SHOULD be 996 retransmitted at least three times. The implmentation 997 guidelines specification [25] recommends a retransmission timer 998 algorithm. 1000 Retransmitted messages SHOULD include the current value of Sr in the 1001 Nr field. An implementation MAY choose not to update Nr field (and 1002 Timestamp AVP) for retransmitted messages, in order to avoid having 1003 to perform another hash in the Integrity-Check- Value AVP. The 1004 message identifier in the retransmitted message MUST NOT be changed. 1006 A DIAMETER implementation MAY queue out of order DIAMETER messages 1007 for subsequent processing. 1009 The receive window is the maximum number of unacknowledged packets 1010 that are to be outstanding to a DIAMETER peer. When transmitting 1011 packets, a DIAMETER peer must obey the receive window size offered by 1012 its peer. The default window size is 7. Once the number of 1013 unacknowledged messages equals the window size, the window is 1014 'closed.' Previously transmitted packets may be retransmitted when 1015 the peer's window is closed. A peer MAY explicitly specify its 1016 window size in the Device-Reboot-Ind message in the Receive-Window 1017 AVP. 1019 A peer MAY return a Nr value in a ZLB or piggybacked in a non-ZLB 1020 message which is less than the latest Sr value, due to congestion. 1021 Returning a value in Nr of the first value in the window will have 1022 the effect of preventing the communicating peer from sending any new 1023 messages. 1025 See [25] for some examples of how sequence numbers progress. 1027 4.1.1 Receive-Window AVP 1029 The Receive-Window AVP (AVP Code 277) is of type Integer32 and 1030 contains the maximum number of outstanding unacknowledged messages 1031 that it is willing to accept for a given peer. Once the number of 1032 unacknowledged messages has reached this number, the receive window 1033 is considered closed. The default value for the receive window is 7, 1034 and SHOULD be configurable. A simple implementation that does not 1035 require a high number of transactions per second MAY send a Receive- 1036 Window AVP set to one (1). 1038 A node MUST stop sending messages when it detects that the number of 1039 unacknowledged messages is equal to the peer's receive window size. 1041 4.2 Peer failure recovery 1043 A DIAMETER message with the Command-Code AVP set to Device-Reboot-Ind 1044 and the Ns and Nr values set to zero (0) indicates that the peer has 1045 rebooted. This message MUST be recognized and supported by a 1046 DIAMETER implementation. When this event occurs, the Ss and Sr values 1047 must be reset and the retransmission queue MUST be cleared. Since the 1048 protocol requires that all new messages include a random identifier 1049 in the protocol header, a Device-Reboot-Ind that is received with the 1050 same identifier as the last processed Device-Reboot-Ind is considered 1051 a retransmission and SHOULD NOT change the peer's state to closed. 1053 Messages other than the Device-Reboot-Ind MUST NOT be sent to the 1054 peer until both the acknowledgement for the transmitted Device- 1055 Reboot-Ind AND the peer's Device-Reboot-Ind have been received. When 1056 both of these have been received, the peer is considered to be in the 1057 active state. 1059 5.0 Error Reporting 1061 There are five different types of errors within DIAMETER. The first 1062 being where a DIAMETER message is poorly formatted and 1063 unrecognizable, indicated below by "Bad Message". This error 1064 condition applies if a received message creates a fatal error (e.g. 1065 fails transport level authentication, cannot be parsed, etc). 1067 The second case involves receiving a Command-Code AVP that is not 1068 supported, which is shown below by "Unknown Command". The third case 1069 is where an AVP is received, marked mandatory and is unknown by the 1070 receiver, which is labeled below as "Unknown AVP". 1072 This fourth case involves receiving a message with a known AVP, yet 1073 the value is either unknown or illegal, which is shown below as "Bad 1074 Value". The last case occurs when an error occurs while processing a 1075 specific extension command, which is not related to the message 1076 format and is labeled "Extension Error" below. 1078 Error Type Ignore Message Send Extension 1079 Message-Reject-Ind Response + 1080 Result-Code 1081 Bad Message X 1082 Unknown Command X 1083 Unknown AVP X 1084 Bad Value X 1085 Extension Error X 1087 "Ignore Message" indicates that the message is simply dropped. The 1088 "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST 1089 be sent to the peer as described in the appropriate section. The 1090 "Extension Response + Result-Code" indicates that the appropriate 1091 Response to the message MUST be sent with the Result-Code AVP set to 1092 a value that enables the peer to understand the nature of the 1093 problem. 1095 5.1 Message-Reject-Ind (MRI) Command 1097 The Message-Reject-Ind (MRI), indicated by the Command-Code AVP set 1098 to 256, provides a generic means of completing transactions by 1099 indicating errors in the messages that initiated them. The Message- 1100 Reject-Ind command is a possible response to any DIAMETER command. 1101 Some DIAMETER commands MAY expect more specialized error messages, 1102 depending on the error type. 1104 The Message-Reject-Ind message MUST contain the same identification 1105 in the header and include the Session-Id if it was present in the 1106 original message that it is responding to, even if the identification 1107 is erroneous. The receiver of a Message-Reject-Ind SHOULD examine the 1108 Result-Code AVP provided before processing the identification, in 1109 order to handle the latter appropriately. 1111 Message Format 1113 The structure of the Message-Reject-Ind message is defined as 1114 follows: 1116 ::= 1117 1118 1119 [] 1120 [] 1121 1122 1123 [ 1124 1125 ] 1127 where the Identifier value in the message header and optionally 1128 the Session-Id AVP are copied from the message being rejected. The 1129 Result-Code AVP indicate the nature of the error causing 1130 rejection, and the Failed-AVP AVP provides some minimal debugging 1131 data by indicating a specific AVP type which caused the problem. 1132 See the description of the Result-Code AVP for indication of when 1133 the Failed-AVP AVP MUST be present in the message. See [25] for 1134 more information. 1136 5.1.1 Failed-AVP AVP 1137 The Failed-AVP AVP (AVP Code 279) is of type Data and provides 1138 debugging information in cases where a request is rejected or not 1139 fully processed due to erroneous information in a specific AVP. The 1140 value of the Result-Code AVP will provide information on the reason 1141 for the Failed-AVP AVP. 1143 A DIAMETER message MAY contain one or more Failed-AVP, each 1144 containing a complete AVP that could not be processed successfully. 1145 The possible reasons for this AVP are the presence of an improperly 1146 constructed AVP, an unsupported or unrecognized AVP or an invalid AVP 1147 value (e.g. unknown Command-Code AVP). 1149 5.2 Result-Code AVP 1151 The Result-Code AVP (AVP Code 268) is of type Complex and indicates 1152 whether a particular request was completed successfully or whether an 1153 error occurred. All DIAMETER messages of type *-Response or *-Answer 1154 MUST include one Result-Code AVP. 1156 0 1 2 3 1157 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 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 AVP Header (AVP Code = 268) 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Result Code | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | String ... 1164 +-+-+-+-+-+-+-+-+ 1166 The Result Code field contains an IANA-managed 32-bit address space 1167 representing errors. The String field contains an OPTIONAL string 1168 field containing a human readable error message. The base protocol 1169 defines the following error codes, and others MAY be defined in 1170 separate DIAMETER extensions: 1172 DIAMETER_SUCCESS 0 1173 The Request was successfully completed. 1175 DIAMETER_FAILURE 1 1176 The Request was not successfully completed for an unspecified 1177 reason. A DIAMETER Message-Reject message returning this 1178 result SHOULD whenever possible also contain one or more 1179 Failed-AVP AVPs indicating the attributes which caused the 1180 failure. 1182 DIAMETER_POOR_REQUEST 2 1183 The Request was poorly constructed. 1185 DIAMETER_INVALID_AUTH 3 1186 The Request did not contain a valid Integrity-Check-Value or 1187 CMS-Data [11] AVP. 1189 DIAMETER_UNKNOWN_SESSION_ID 4 1190 The Request contained an unknown Session-Id. This error is sent 1191 only due to conditions that arise due to command messages in 1192 DIAMETER extensions, the base protocol does not include command 1193 codes that require the Session-Id AVP. 1195 DIAMETER_USER_UNKNOWN 5 1196 A request was received for a user that is unknown, therefore 1197 authentication failed. This error is sent only due to 1198 conditions that arise due to command messages in DIAMETER 1199 extensions, the base protocol does not include command codes 1200 that require the User-Name AVP. 1202 DIAMETER_COMMAND_UNSUPPORTED 6 1203 The Request contained a Command-Code AVP that the receiver did 1204 not recognize or support. The Message-Reject-Ind message MUST 1205 also contain a Failed-AVP AVP containing the unrecognized 1206 Command-Code AVP. 1208 DIAMETER_TIMEOUT 7 1209 This error MAY be returned if a request has been received that 1210 has a Timestamp AVP that is older than the maximum age that the 1211 communicating peer is willing to accept. 1213 DIAMETER_AVP_UNSUPPORTED 8 1214 The peer received a message that contained an AVP that is not 1215 recognized or supported and was marked with the Mandatory bit. 1216 A Message-Reject-Ind message with this error MUST contain one 1217 or more Failed-AVP AVP containing the AVPs that caused the 1218 failure. 1220 DIAMETER_REDIRECT_INDICATION 9 1221 A proxy or broker has determined that the request could not be 1222 satisfied locally and the initiator of the request should 1223 direct the request directly to the server, whose contact 1224 information has been added to the response. This error code 1225 MUST NOT be sent in a Message-Reject-Ind message. 1227 DIAMETER_DOMAIN_NOT_SERVED 10 1228 A proxy or broker has determined that it is unable to forward 1229 the request or provide redirect information since the realm 1230 portion of the NAI requested is unknown. 1232 DIAMETER_UNSUPPORTED_TRANSFORM 11 1233 A message was received that included an Integrity-Check-Value 1234 or CMS-Data AVP [11] that made use of an unsupported transform. 1236 DIAMETER_AUTHENTICATION_REJECTED 12 1237 The authentication process for the user failed, most likely due 1238 to an invalid password used by the user. 1240 DIAMETER_AUTHORIZATION_REJECTED 13 1241 A request was received for which the user could not be 1242 authorized. This error could occur when the user has already 1243 expended allowed resources, or if the service requested is not 1244 permitted to the user. 1246 DIAMETER_INVALID_AVP_VALUE 14 1248 The request contained an AVP with an invalid value in its data 1249 portion. A DIAMETER message with this result code MUST include 1250 the offending AVPs within a Failed-AVP AVP. 1252 DIAMETER_MISSING_AVP 15 1253 The request did not contain an AVP which the Command Code 1254 requires be present. If this result code is sent, a Failed-AVP 1255 AVP should be included in the Message-Reject-Ind message. The 1256 AVP 'Data' in the Failed-AVP has its AVP Code set to the value 1257 of the missing and required AVP, but does not include any data 1258 of its own. 1260 5.2.1 Additional Error Codes 1262 The following additional result codes are defined by standard 1263 extensions to the DIAMETER protocol. 1265 DIAMETER_ERROR_BAD_KEY 16 [10] 1266 DIAMETER_ERROR_BAD_HOME_ADDRESS 17 [10] DIAMETER_ERROR_TOO_BUSY 1267 18 [10] DIAMETER_ERROR_MIP_REPLY_FAILURE 19 [10] 1268 DIAMETER_INVALID_CMS_DATA 20 [11] 1270 6.0 DIAMETER Message Routing 1272 The DIAMETER base protocol supports two basic message routing 1273 methods; proxying and brokering. A DIAMETER proxy is a server that 1274 simply forwards the request based on the user's identity, or through 1275 some other means. A DIAMETER broker is a server that provides 1276 redirect services, allowing all servers in a roaming consortium to 1277 interact directly. 1279 6.1 Message Proxying 1281 A DIAMETER proxy is a server that provides message forwarding 1282 functions to other DIAMETER Servers. Proxies are typically used when 1283 a hierarchical DIAMETER network is deployed, where some DIAMETER 1284 servers can authenticate and authorize a set of users. Such an 1285 example is a roaming consortium, where each ISP has a user base, 1286 which they can authenticate and authorize. It is important to note 1287 that proxy servers MUST NOT attempt to re-order AVPs in a DIAMETER 1288 message. 1290 The example provided in figure 1 shows a request issued by DIA1, 1291 requesting authentication and authorization for a user that belongs 1292 to DIA3's network. When DIA1 receives the request from the access 1293 device (e.g. NAS), it checks whether the Destination-NAI AVP is 1294 present, which MUST be in a format consistent with the NAI [8] 1295 specification. If the Destination-NAI is not present, the server MUST 1296 use the information found in the User-Name AVP. 1298 The NAI has a format of user@realm, and DIAMETER servers typically 1299 have a list of locally supported realms, and MAY have a list of 1300 externally supported realms with associated DIAMETER servers. 1301 DIAMETER servers that interface with brokers SHOULD allow for a 1302 "default" destination for all requests received that are not locally 1303 configured. 1305 In the example below, DIA1 looks up the user's realm, and determines 1306 that the request is to be forwarded to DIA2. When DIA2 receives the 1307 request, it MAY decide that some state information needs to be kept 1308 in order to process the response in a particular fashion. An example 1309 would be that DIA2 determines that certain authorization information 1310 is to be added to the response, when received. 1312 (Request) (Request) 1313 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1314 (Host-Name=DIA1@nmo.net) (Host-Name=DIA1@nmo.net) 1315 (Proxy-State=x) (Proxy-State=y) 1316 +------+ ------> +------+ ------> +------+ 1317 | | | | | | 1318 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1319 | | | | | | 1320 +------+ <------ +------+ <------ +------+ 1321 (Response) (Response) 1322 (User-Name=joe@abc.com) (User-Name=joe@abc.com) 1323 (Dest-NAI=DIA1@mno.net) (Dest-NAI=DIA1@mno.net) 1324 (Proxy-State=x) (Proxy-State=y) 1325 mno.net xyz.com abc.com 1326 Figure 1: DIAMETER Proxying 1328 There are two methods that MAY be implemented by DIAMETER servers in 1329 order to keep per-request state information. 1331 1. DIA2 MAY maintain a state control block, and using the 1332 session-Id and possibly the Identifier in the header, can match 1333 the request with the response. The state control block MAY 1334 include AVPs that need to be added to the corresponding 1335 response, or any additional policy decisions that will need to 1336 be done when the response is received. 1338 2. DIA2 MAY add a Proxy-State AVP (see section 6.1.1), which can 1339 contain ANY information that will be needed when the 1340 corresponding response is received. A DIAMETER message MUST 1341 only include one Proxy-State AVP, so if a new Proxy-State AVP 1342 is added, the old one MUST be removed. The new Proxy-State AVP 1343 MAY include AVPs that are to be added to the response, the 1344 existing Proxy-State AVP, etc. 1346 Once DIA2 has completed processing the request, it forwards the 1347 request to DIA3 following the same procedures defined for DIA1. 1349 When DIA3 receives the request, and it determines that the 1350 request is to be processed locally, it authenticates and 1351 authorizes the user. DIA3 MUST add the Destination-NAI AVP, 1352 with the same contents as the Host-Name AVP that was found in 1353 the corresponding request. If the request contained a Proxy- 1354 State AVP, the same AVP MUST be present in the response. 1356 When DIA2 receives the response from DIA3, it MUST first 1357 determine whether the Proxy-State AVP was created locally by 1358 looking at the address field of the AVP. Since it is the same 1359 AVP as the one that it added to the request, it will extract 1360 any embedded information within the Proxy-State AVP. If AVPs 1361 were encapsulated within the Proxy-State AVP, these SHOULD be 1362 extracted and added to the response. If the request from DIA1 1363 included a Proxy-State AVP, the same AVP MUST be present in the 1364 response back to DIA1. 1366 6.1.1 Proxy-State AVP 1368 The Proxy-State AVP (AVP Code 33) [1] is used by proxy servers when 1369 forwarding requests and contains opaque data that is used by the 1370 proxy to further process the response. Such data may include AVPs 1371 that are to be added to the response, information about the 1372 downstream peer, etc. 1374 A DIAMETER node that receives such an AVP in a request MUST return 1375 the identical AVP in the response. Furthermore, no more than one 1376 Proxy-State AVP MUST be present in a message at any given time, so 1377 implementations MUST ensure that they remove any Proxy-State AVPs 1378 before adding their own. 1380 If the Proxy-State AVP was removed from a request, the same AVP MUST 1381 be inserted in the corresponding response before forwarding the 1382 message to the downstream peer. 1384 The Proxy-State AVP's Address field is 128-bits in length contains 1385 the IP address of the system created the AVP. If the host creating 1386 the AVP has an IPv4 address, the leading 96 bits MUST be set to zero 1387 (0). This field is intended to assist hosts in determining whether a 1388 Proxy-State AVP is intended for the local host. 1390 0 1 2 3 1391 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 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 AVP Header (AVP Code = 33) 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | 128-bit Address... 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Data ... 1398 +-+-+-+-+-+-+-+-+ 1400 6.1.2 Destination-NAI AVP 1402 The Destination-NAI AVP (AVP Code 269) is of type String and MAY be 1403 included in a request or response message, and MUST be in a format 1404 consistent with the NAI specification. When found in a response, the 1405 AVP SHOULD contain the value of the Host-Name AVP that was found in 1406 the request. This AVP SHOULD be used by intermediate proxies in the 1407 message routing process. 1409 6.2 Message Redirection 1411 There are cases where a DIAMETER proxy, known as a broker, may wish 1412 to request that a server contact another directly instead of 1413 forwarding the message (figure 2). This is typically done when the 1414 broker provides simple NAI to Home DIAMETER Server address resolution 1415 services. 1417 In the example provided in figure 2, abc.net's DIAMETER server issues 1418 a request to its broker, which in turn returns a response that 1419 includes the Result-Code AVP set to a specific value (see section 1420 5.2). When a response is received with such a value, the message MUST 1421 also include one or more Redirect-Host AVPs. These AVPs contain 1422 address information that SHOULD be used to directly communicate with 1423 the Home DIAMETER Server. Note that the servers MAY cache the home 1424 server information in order to reduce the latency involved in any 1425 future messages destined for that home server. 1427 +------------------+ +---------+ 1428 | DIAMETER | | CRL DB/ | 1429 | Broker | | OCSP | 1430 +------------------+ +---------+ 1431 /|\ 1432 Request | Response + 1433 | Result Code = 1434 | Redirect 1435 \|/ 1436 +----------+ +----------+ 1437 | abc.net |/ \| xyz.net | 1438 | DIAMETER |--------------| DIAMETER | 1439 | Server |\ /| Server | 1440 +----------+ Direct +----------+ 1441 Communication 1442 Figure 2: DIAMETER Broker Returning Redirect Indication 1444 When returning the response with the Result-Code set to indicate a 1445 redirect indication, the broker MAY also include the certificates of 1446 both the requesting server, and the target server. These certificates 1447 are encapsulated in a CMS-Data AVP [11]. The requesting server SHOULD 1448 forward the certificate that belongs to it in the subsequent request 1449 to the home DIAMETER server. 1451 6.2.1 Redirect-Host AVP 1453 The Redirect-Host AVP (AVP Code 278) is of type Address and is 1454 returned in a response that has the Result-Code AVP set to 1455 DIAMETER_REDIRECT_REQUEST. This AVP includes address information of 1456 the DIAMETER host to which the request must be redirected. Upon 1457 receipt of such a Result-Code, and this AVP, a DIAMETER host SHOULD 1458 send the request directly to the host. A proxy server or broker MAY 1459 return more than one Redirect-Host AVP if there is more than one 1460 DIAMETER server that can satisfy the request. 1462 The broker MAY wish to return the certificate associated with a given 1463 Redirect-Host AVP. This can be returned in a CMS-Data AVP, as defined 1464 in [11]. 1466 7.0 DIAMETER Message Security 1468 The DIAMETER Base protocol MAY be secured in one of three ways. The 1469 first method does not involve any security mechanisms in the DIAMETER 1470 protocol, but relies on an underlying security mechanism, such as IP 1471 Security. The second method is hop-by-hop security, which SHOULD be 1472 supported by all DIAMETER implementations. The third method is 1473 optional and requires a Public Key Infrastructure [14], and is 1474 documented in [11]. 1476 7.1 Hop-by-Hop Security 1478 DIAMETER Hop-by-Hop security provides message integrity and per AVP 1479 encryption, and requires that the communicating entities have a pre- 1480 configured shared secret, similar to the method employed by the 1481 RADIUS protocol. Hop-by-Hop security does not have the scaling 1482 properties associated with a public key infrastructure (PKI), which 1483 is used in end-to-end security, but MAY be desirable in environments 1484 where asymmetric technology is not required, or available. 1486 Hop-by-Hop security implies that each hop along a proxy chain is 1487 responsible for the following tasks: 1489 - Validating the message's integrity using the shared secret with 1490 the sender. 1492 - Decrypting any encrypted AVPs using the secret shared with the 1493 sender. 1495 - Re-encrypting AVPs using the secret shared with the next server. 1497 - Computing the message hash using the secret shared with the next 1498 server, and adding it to the ICV AVP in the DIAMETER message. 1500 (Shared-Secret-1) (Shared-Secret-2) 1501 +------+ -----> +------+ ------> +------+ 1502 | | | | | | 1503 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1504 | | | | | | 1505 +------+ +------+ +------+ 1506 Figure 3: Hop-by-Hop Security in Proxy Environments 1508 The above steps that each proxy MUST perform in a proxy chain clearly 1509 describes the security issues associated with hop-by-hop security in 1510 a proxy environment. Since the message integrity is re-computed at 1511 each node in the chain, it is very difficult to detect if a proxy 1512 modified information in the message (e.g. session time). Furthermore, 1513 any sensitive information would be known to all proxies in the chain, 1514 since each node must decrypt AVPs. Therefore, Any AVPs that require 1515 strong authentication and/or confidentiality in a proxy environment 1516 SHOULD be protected via the mechanism described in the strong 1517 security extension [11]. 1519 It is highly recommended that the size of the shared secrets used be 1520 sufficiently long (e.g. 128 bits), and that different shared secrets 1521 be used for both authentication and encryption. 1523 7.1.1 Integrity-Check-Value AVP 1525 The Integrity-Check-Value AVP (AVP Code 259) is of type complex and 1526 is used for hop-by-hop authentication and integrity, and is not 1527 recommended for use with untrusted proxy servers. 1529 The DIAMETER header as well as all AVPs (including padding) up to 1530 this AVP is protected by the Integrity-Check-Value. Note that the 1531 Message Length field in the DIAMETER header MUST be set to zero (0) 1532 prior to the ICV calculation. The Timestamp and Nonce AVPs MUST be 1533 present in the message PRIOR to the Integrity-Check-Value AVP. The 1534 Timestamp AVP provides replay protection and the Nonce AVP provides 1535 randomness. Any AVPs in a message that is not succeeded by the 1536 Integrity-Check-Value AVP MUST be ignored. 1538 The following is an example of a message that include hop-by-hop 1539 security: 1541 ::= 1542 1543 1544 [] 1545 1546 1548 All DIAMETER implementations SHOULD support this AVP. 1550 0 1 2 3 1551 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 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 AVP Header (AVP Code = 259) 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Transform ID | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Key ID | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Data ... 1560 +-+-+-+-+-+-+-+-+ 1562 AVP Length 1563 The length of this attribute MUST be at least 13. 1565 Transform ID 1566 The Transform ID field contains a value that identifies the 1567 transform that was used to compute the ICV. The following 1568 values are defined in this document: 1570 HMAC-MD5-96[6] 1 1571 The ICV is computed using the HMAC-MD5 algorithm, and the 1572 first 12 bytes of the hash output is included in the data 1573 portion of the ICV AVP. All DIAMETER implementations 1574 supporting this AVP MUST support this transform. Using the 1575 example code provided in [6], the following call would be 1576 used to generate the Integrity-Check-Value: 1578 hmac_md5(DiameterMessage, MessageLength, Secret, 1579 Secretlength, Output) 1581 Key ID 1582 The Key ID field contains a key identifier, which is used to 1583 identify the keying information used to generate the AVP's data 1584 field. 1586 Data 1587 The data field contains the output from the hashing algorithm. 1589 7.1.2 Encrypted-Payload AVP 1591 The Encrypted-Payload AVP (AVP Code 260) is of type complex and is 1592 used to encapsulate encrypted AVPs for privacy during transmission. 1594 Hop-by-Hop confidentiality is achieved by encapsulating all AVPs 1595 which are to be encrypted into an Encrypted-Payload AVP. This 1596 feature SHOULD be supported by DIAMETER implementations. 1598 0 1 2 3 1599 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 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 AVP Header (AVP Code = 260) 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Transform ID | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Key ID | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Data ... 1608 +-+-+-+-+-+-+-+-+ 1610 AVP Length 1611 The length of this attribute MUST be at least 13. 1613 Transform ID 1614 The Transform ID field contains a value that identifies the 1615 transform that was used to compute the ICV. The following 1616 values are defined in this document: 1618 MD5 1 1619 See section 7.1.2.1 for more information. 1621 Key ID 1622 The Key ID field contains a key identifier, which is used to 1623 identify the keying information used to generate the AVP's data 1624 field. 1626 Data 1627 The data field contains the encrypted payload. 1629 7.1.2.1 MD5 Payload Hiding 1631 MD5 Payload Hiding is supported by DIAMETER for backward 1632 compatibility with existing RADIUS infrastructure. 1634 The plain text (which is a buffer containing one or more AVPs) is 1635 first padded to a sixteen (16) byte boundary with 0 bytes. Since the 1636 encapsulated AVPs have length fields, it is possible to detect their 1637 boundaries, whether or not padding has been done. 1639 One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 1640 hash is performed on the: 1642 - last Nonce AVP which precedes the Encrypted-Payload AVP 1643 - the shared authentication secret 1645 This MD5 hash value is then XORed with the first 16 octet segment of 1646 the buffer to encrypt. The resulting 16 octet result is saved as the 1647 first 16 octets of the encrypted buffer. The result is also used to 1648 calculate a new value using MD5: 1650 - the shared authentication secret 1651 - the 16 byte result of the previous XOR 1653 This value is then XORed with the next 16 bytes. This is done for 1654 each 16 bytes successively in the buffer to encrypt, producing an 1655 equal sized encrypted buffer. 1657 The receiver of a DIAMETER message with an Encrypted-Payload AVP MUST 1658 first check the integrity of the message, either through the ICV, or 1659 the CMS-Data AVP [11] if it protects the Encrypted-Payload AVP. Then 1660 the Encrypted-Payload AVP is decrypted, by reversing the above 1661 procedure, which applied to the buffer will reproduce the plain text 1662 version. The decapsulated AVPs are then used to process the DIAMETER 1663 message in the normal manner. 1665 7.2 Nonce AVP 1667 The Nonce AVP (AVP Code 261) is of type Data and MUST be present 1668 prior to the Integrity-Check-Value AVPs within a message and is used 1669 to ensure randomness within a message. The content of this AVP MUST 1670 be a random value of at least 128 bits. Some crypto algorithms are 1671 known to have weaknesses if a random value is not found early within 1672 the plaintext, therefore it is recommended that the Nonce AVP be 1673 added early in a message if possible. 1675 7.3 Timestamp AVP 1677 The Timestamp AVP (AVP Code 262) is of type Time and is used to add 1678 replay protection to the DIAMETER protocol. This AVP MUST appear 1679 prior to the Integrity-Check-Value AVP or any other message integrity 1680 AVP defined in separate extensions. The value of time is the most 1681 significant four octets returned from an NTP server that indicates 1682 the number of seconds expired since Jan. 1, 1900. 1684 Messages that are older than a certain maximum age SHOULD be rejected 1685 and a response SHOULD be returned with the Result-Code AVP value set 1686 to DIAMETER_TIMEOUT. A DIAMETER node that receives a message with the 1687 Result-Code AVP set to DIAMETER-TIMEOUT MAY use the Timestamp AVP 1688 found in the message to synchronize its clock with its peer. 1690 Note that the larger the value, the more susceptible one is to a 1691 replay attack. However, one does have to take into account the 1692 possibility for clock drift, and the latency involved in the 1693 transmission of the message over the network. The timestamp AVP 1694 SHOULD be updated prior to retransmission. 1696 Implementations must be prepared to wrap at the epochal 2038 where 1697 Time values are used, and 0,1,... MUST be considered greater than 1698 2^32-1 at that time. 1700 8.0 IANA Considerations 1702 This document defines a number of assigned numbers to be maintained 1703 by the IANA. This section explains the criteria to be used by the 1704 IANA to assign additional numbers in each of these lists. The 1705 following subsections describe the assignment policy for the 1706 namespaces defined elsewhere in this document. 1708 8.1 AVP Attributes 1710 As defined in section 2.2, AVPs contain vendor ID, attribute and 1711 value fields. For vendor ID value of 0, IANA will maintain a registry 1712 of assigned AVP codes and in some case also values. Attribute 0-254 1713 are assigned from the RADIUS protocol [1], whose attributes are also 1714 maintained through IANA. AVP Codes 256-280 are assigned within this 1715 document. The remaining values are available for assignment through 1716 Designated Expert [12]. 1718 8.2 Command Code AVP Values 1720 As defined in section 2.3.1, the Command Code AVPs (AVP Code 256) 1721 have an associated value maintained by IANA. Values 0-255 are 1722 reserved for backward RADIUS compatibility, and values 256-258 are 1723 defined in this specification. The remaining values are available for 1724 assignment via Designated Expert [12]. 1726 8.3 Extension Identifier Values 1728 As defined in section 2.6.5, the Extension Identifier is used to 1729 identify a specific DIAMETER Extension. All values, other than zero 1730 (0) are available for assignment via Standards Action [12]. 1732 Note that the DIAMETER protocol is not inteded to be extended for any 1733 purpose. Any extensions added to the protocol MUST ensure that they 1734 fit within the existing framework, and that no changes to the base 1735 protocol are required. 1737 8.4 Result-Code AVP Values 1739 As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines 1740 the values 0-8. All remaining values are available for assignment via 1741 IETF Consensus [12]. 1743 8.5 Integrity-Check-Value AVP Transform Values 1745 Section 7.1.1 defines the Integrity-Check-Value AVP (AVP Code 259) 1746 which contains a field called the Transform. This document reserves 1747 the value 1. All remaining values are available for assignment via 1748 Designated Expert [12]. 1750 8.6 Reboot-Type AVP Values 1752 Section 2.6.3 defines the Reboot-Type AVP (AVP Code 271), which is 1753 used to inform the peer of the cause for the reboot. This document 1754 defines the values 1-3. All remaining values are available for 1755 assignment via Designated Expert [12]. 1757 8.7 AVP Header Bits 1759 There are six remaining reserved bits in the AVP header. Additional 1760 bits should only be assigned via a Standards Action [12]. 1762 9.0 Open Issues 1764 The following are the open issues that SHOULD be addressed in future 1765 versions of the DIAMETER protocol: 1767 - AVPs of type 'Time" are 32 bits in size and contain the a 1768 timestamp consistent with NTP [18]. This field is expected to 1769 expire sometime in 2038. Future investigation SHOULD be done to 1770 determine if a 64 bit time format could be used. 1772 - The fact that the Sender's IP Address is used in the 1773 construction of the Session-Id means that the introduction of 1774 Network Address Translation MAY cause two hosts to represent the 1775 same Session Identifier. This area needs to be investigated 1776 further to be able to support DIAMETER hosts on a private 1777 network. 1779 - When additional hashing transforms are supporting by the 1780 DIAMETER base protocol, there SHOULD be a method to negotiate 1781 the transform to be used. This negotiation MUST NOT be prone to 1782 a bidding down attack to the lowest secure transform. 1784 10.0 DIAMETER protocol related configurable parameters 1786 This section contains the configurable parameters that are found 1787 throughout this document: 1789 Device-Reboot-Ind Timer 1790 This timer is used to determine how long an implementation 1791 should issue another DRI message if no response is received. 1792 Default is 20 seconds. 1794 Device-Watchdog-Ind Timer 1795 This is the timer that determines the period of inactivity that 1796 must occur before a DWI is transmitted to the communicating 1797 peer. Default is 60 seconds, if DWI messages are sent. 1799 Receive Window 1800 The Receive window determines how many unacknowledged DIAMETER 1801 messages MAY be pending with a communicating peer. This is 1802 normally configured to a value that allows the node to 1803 effectively manage its receive buffers. Default is 7. 1805 Retransmission Timer 1806 The retransmission timer is the time period that a node will 1807 retransmit a message if no transport level acknowledgement was 1808 received. Default is 3 seconds. 1810 Maximum Retransmissions 1811 This is the maximum number of times a DIAMETER message will be 1812 retransmitted before it is determined that the communicating 1813 peer is no longer reachable. Default is 3. 1815 Delayed Acknowledgement Timer 1816 This timer is defined in [25]. 1818 Shared Secret 1819 The shared secret is a value that is known by two communicating 1820 peers, and is used to generate the Integrity-Check-Value AVP. 1821 There is no default. 1823 Maximum Age of an outstanding message 1824 Messages older than the maximum age SHOULD be rejected, as 1825 described in section 7.3. The recommended value is 4 seconds. 1827 11.0 Security Considerations 1829 The DIAMETER base protocol requires that two communicating peers 1830 exchange messages in a secure fashion. This document documents two 1831 security methods that can be used. The first requires no security at 1832 the application layer, but rather relies on an underlying security 1833 mechanism, such as IP Security. 1835 When IP Security is not available, or desirable, the DIAMETER 1836 protocol MAY use hop-by-hop security, which requires communicating 1837 peers to share a long-lived secret. Hop-by-Hop security provides 1838 replay protection by requiring that the communicating peers share a 1839 time source, such as an NTP server. 1841 When the DIAMETER protocol is used in an inter-domain network, strong 1842 application level security MAY be required, such as non-repudiation. 1843 This the communicating peers do require this level of security either 1844 for legal or business purposes, the extension defined in [11] MAY be 1845 used. 1847 12.0 References 1849 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1850 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. 1851 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 1852 [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1853 1992. 1854 [5] Kaufman, Perlman, Speciner, "Network Security: Private 1855 Communications in a Public World", Prentice Hall, March 1995, 1856 ISBN 0-13-061466-1. 1857 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 1858 Authentication", RFC 2104, January 1997. 1859 [7] P. Calhoun, W. Bulley, "DIAMETER NASREQ Extension", draft- 1860 calhoun-diameter-nasreq-00.txt (work in progress), December 1861 1999. 1862 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. 1863 January 1999. 1864 [9] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- 1865 calhoun-diameter-framework-05.txt (work in progress), December 1866 1999. 1867 [10] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", 1868 draft-calhoun-diameter-mobileip-04.txt (work in progress), 1869 December 1999. 1870 [11] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1871 Extension", draft-calhoun-diameter-strong-security-00.txt (work 1872 in progress), December 1999. 1873 [12] Narten, Alvestrand,"Guidelines for Writing an IANA 1874 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 1875 [13] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1876 Levels", BCP 14, RFC 2119, March 1997. 1877 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1878 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1879 RFC 2560, June 1999. 1880 [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension", 1881 draft-calhoun-diameter-accounting-02.txt (work in progress), 1882 December 1999. 1883 [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 1884 2373, July 1998. 1885 [17] ISI, "Internet Protocol", RFC 791, September 1981. 1886 [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 1887 IPv6 and OSI, RFC 2030, October 1996. 1888 [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key 1889 Infrastructure Certificate and CRL Profile", RFC 2459, January 1890 1999. 1891 [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1892 RFC 2477, January 1999. 1893 [21] M. Beadles, "Criteria for Evaluating Network Access Server 1894 Protocols", draft-ietf-nasreq-criteria-03.txt (work in 1895 progress), October 1999. 1896 [22] T. Hiller et al., "Cdma2000 Wireless Data Requirements for 1897 AAA", draft-hiller-cdma2000-AAA-00.txt (work in progress), 1898 October 1999. 1899 [23] S. Glass, S. Jacobs, C. Perkin, "Mobile IP Authentication, 1900 Authorization, and Accounting Requirements", draft-ietf- 1901 mobileip-aaa-reqs-01.txt (work in progress), October 1999. 1902 [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1903 2279, January 1998. 1904 [25] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 1905 Haag, "DIAMETER Implementation Guidelines", draft-calhoun- 1906 diameter-impl-guide-00.txt (work in progress), December 1999. 1908 13.0 Acknowledgements 1910 The authors would like to thank Nenad Trifunovic, Tony Johansson and 1911 Pankaj Patel for their participation in the Document Reading Party. 1913 The authors would also like to acknowledge the following people for 1914 their contribution in the development of the DIAMETER protocol: 1916 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1917 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 1918 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Stephen 1919 Farrell,Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 1921 14.0 Author's Addresses 1923 Questions about this memo can be directed to: 1925 Pat R. Calhoun 1926 Network and Security Research Center, Sun Laboratories 1927 Sun Microsystems, Inc. 1928 15 Network Circle 1929 Menlo Park, California, 94025 1930 USA 1932 Phone: 1-650-786-7733 1933 Fax: 1-650-786-6445 1934 E-mail: pcalhoun@eng.sun.com 1936 Allan C. Rubens 1937 Tut Systems, Inc. 1938 220 E. Huron, Suite 260 1939 Ann Arbor, MI 48104 1940 USA 1942 Phone: 1-734-995-1697 1943 E-Mail: arubens@tutsys.com 1945 Haseeb Akhtar 1946 Wireless Technology Labs 1947 Nortel Networks 1948 2221 Lakeside Blvd. 1949 Richardson, TX 75082-4399 1950 USA 1952 Phone: 1-972-684-8850 1953 E-Mail: haseeb@nortelnetworks.com 1955 Erik Guttman 1956 Network and Security Research Center, Sun Laboratories 1957 Sun Microsystems, Inc. 1958 Eichhoelzelstr. 7 1959 74915 Waibstadt 1960 Germany 1962 Phone: 49-7263-911-701 1963 E-mail: erik.guttman@germany.sun.com 1965 15.0 Full Copyright Statement 1967 Copyright (C) The Internet Society (1999). All Rights Reserved. 1969 This document and translations of it may be copied and furnished 1970 to others, and derivative works that comment on or otherwise 1971 explain it or assist in its implementation may be prepared, copied, 1972 published and distributed, in whole or in part, without 1973 restriction of any kind, provided that the above copyright notice 1974 and this paragraph are included on all such copies and derivative 1975 works. However, this docu- ment itself may not be modified in any 1976 way, such as by removing the copyright notice or references to the 1977 Internet Society or other Inter- net organizations, except as needed 1978 for the purpose of developing Internet standards in which case 1979 the procedures for copyrights defined in the Internet Standards 1980 process must be followed, or as required to translate it into 1981 languages other than English. The limited permis- sions granted 1982 above are perpetual and will not be revoked by the Internet 1983 Society or its successors or assigns. This document and the 1984 information contained herein is provided on an "AS IS" basis and 1985 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1986 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1987 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 1988 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1989 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."