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