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