idnits 2.17.1 draft-calhoun-diameter-10.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 55 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 56 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 6 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 1253 has weird spacing: '... AVP if there...' == Line 1442 has weird spacing: '...invalid clea...' == Line 1452 has weird spacing: '...eceived clea...' == Line 1457 has weird spacing: '...eceived clea...' == Line 1470 has weird spacing: '...eceived clea...' == (12 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A vendor id value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the absence of the vendor id field implies that the AVP in question is not vendor specific, implementations SHOULD not use the zero (0) vendor id. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 1932, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1933, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1935, 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') -- No information found for draft-calhoun-diameter-authen - is the name correct? -- 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-04 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-05 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '10') == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-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-00 -- 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) Summary: 17 errors (**), 0 flaws (~~), 18 warnings (==), 8 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 Laboratories, Inc. 3 Title: draft-calhoun-diameter-10.txt Allan C. Rubens 4 Date: October 1999 Tut Systems, Inc. 5 Haseeb Akhtar 6 Nortel Networks 8 DIAMETER Base Protocol 10 Status of this Memo 12 This document is an individual contribution for consideration by the 13 AAA Working Group of the Internet Engineering Task Force. Comments 14 should be submitted to the diameter@ipass.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The DIAMETER base protocol is intended to provide a framework for 40 access technology services that require AAA support. The protocol is 41 intended to be flexible enough to allow services to add building 42 blocks (or extensions) to DIAMETER in order to meet their 43 requirements. 45 This draft specifies the message format and transport to be used by 46 all DIAMETER extensions and MUST be supported by all DIAMETER 47 implementations. 49 Table of Contents 51 1.0 Introduction 52 1.1 Copyright Statement 53 1.2 Requirements language 54 1.3 Terminology 55 2.0 Protocol Overview 56 2.1 Header Format 57 2.1.1 ZLB Message Format 58 2.2 AVP Format 59 2.2.1 AVP Header 60 2.2.2 Optional Header Elements 61 2.2.3 AVP Value Formats 62 2.3 Error Reporting 63 3.0 Reliable Transport 64 3.1 Flow Control 65 3.2 Peer failure recovery 66 4.0 DIAMETER AVPs 67 4.1 DIAMETER-Command AVP 68 4.1.1 Message-Reject-Ind 69 4.1.2 Device-Reboot-Ind 70 4.1.3 Device-Watchdog-Ind 71 4.2 Host-IP-Address 72 4.3 Host-Name 73 4.4 State 74 4.5 Class 75 4.6 Session-Timeout 76 4.7 Extension-Id 77 4.8 Integrity-Check-Value 78 4.9 Nonce 79 4.10 Timestamp 80 4.11 Session-Id 81 4.12 Vendor-Name 82 4.13 Firmware-Revision 83 4.14 Result-Code 84 4.15 Error-Code 85 4.16 Unrecognized-Command-Code 86 4.17 Reboot-Type 87 4.18 Reboot-Time 88 4.19 Failed-AVP-Code 89 4.20 User-Name 90 4.21 Receive-Window 91 4.22 Proxy-State 92 4.23 Redirected-Host 93 4.24 Broker-Issued-Certificate 94 5.0 Protocol Definition 95 5.1 Session Identifiers 96 5.2 DIAMETER Bootstrap Message 97 5.2.1 State Machine 98 5.3 Keepalive Exchange 99 5.4 AVP Handling Rules 100 5.4.1 Unrecognized Command Support 101 5.4.2 The art of AVP Tagging 102 5.5 DIAMETER Message Security 103 5.5.1 Using the Integrity-Check-Value 104 5.5.2 AVP Encryption with Shared Secrets 105 5.6 DIAMETER Message Routing 106 5.6.1 DIAMETER Proxying 107 5.6.2 Message Redirection 108 6.0 IANA Considerations 109 6.1 AVP Attributes 110 6.2 Command Code AVP Values 111 6.3 Extension Identifier Values 112 6.4 Result Code AVP Values 113 6.5 Integrity Check Value Transform Values 114 6.7 AVP Header Bits 115 6.6 Reboot Type Values 116 7.0 Open Issues 117 8.0 DIAMETER protocol related configurable parameters 118 9.0 Security Considerations 119 10.0 References 120 11.0 Acknowledgements 121 12.0 Author's Address 122 13.0 Full Copyright Statement 123 Appendix A: Acknowledgment Timeouts 124 A.1 Calculating Adaptive Acknowledgment Timeout 125 A.2 Flow Control: Adjusting for Timeout 126 Appendix B: Examples of sequence numbering 127 B.1 Lock-step tunnel establishment 128 B.2 Multiple messages acknowledged 129 B.3 Lost message with retransmission 130 Appendix C: Backward Compatibility with RADIUS 131 Appendix D: Delayed Acknowledgement Optimization 132 Appendix E: Device-Reboot-Ind Message Flow 133 Appendix F: Device-Watchdog-Ind Message Flow 134 Appendix G: Message-Reject-Ind Message Flow 136 1.0 Introduction 138 The DIAMETER is a peer to peer protocol that provides Authentication, 139 Authorization and Accounting (AAA) services for access technologies, 140 such as PPP dial-in, Mobile IP, etc. 142 This document describes the base DIAMETER protocol, which is used as 143 the transport for all DIAMETER extensions. This document in itself is 144 not complete and MUST be used with an accompanying applicability 145 extension document. 147 An example of such a document would be [7] that defines extensions to 148 the base protocol to support Dial-in PPP user authentication and 149 [15], which defines extensions to support accounting. 151 The DIAMETER protocol is recognized as a peer to peer protocol since 152 any node can initiate a request. However, a client is the device that 153 normally initiates a request for authentication and/or authorization 154 of a user. A server is the device that performs the actual 155 authentication and/or authorization of the user based on some 156 profile. A server can issue a request to a client, but this is 157 typically not a request for authentication and/or authorization, but 158 rather a different request, such as a request for an accounting 159 update. 161 1.1 Copyright Statement 163 Copyright (C) The Internet Society 1999. All Rights Reserved. 165 1.2 Requirements language 167 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 168 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 169 described in [13]. 171 1.3 Terminology 173 Refer to [9] for terminology used in this document. 175 2.0 Protocol Overview 177 The DIAMETER protocol allows peers to exchange a variety of messages. 178 The base protocol provides the following facilities: 180 - Sequenced in-order reliable delivery of UDP datagram messages 182 - Support for congestion control (receiver window) 184 - Timely detection of failed or unresponsive peers 186 - Delivery of AVPs (attribute value pairs) 188 - Extensibility, through addition of new commands and AVPs 190 All data delivered by the is protocol in the form of an AVP. Some of 191 these AVP values are used by the DIAMETER protocol itself, while 192 others deliver data associated with particular applications which 193 employ DIAMETER. AVPs may be added arbitrarily to DIAMETER messages, 194 so long as the required AVPs are included and AVPs which are 195 explicitly excluded are not included. AVPs are used by base DIAMETER 196 protocol to support the following required features: 198 - All messages carry either an Integrity Check Vector (ICV) or a 199 digital signature[11]. They also carry a timestamp and a nonce to 200 aid in providing replay protection. 202 - To carry user authentication information, for the purposes of 203 enabling the DIAMETER server to authenticate the user. 205 - To allow authorization information to be exchanged for a 206 particular user's session between a DIAMETER client and server. 208 - To exchange resource usage information, which can be used for 209 accounting purposes, capacity planning, etc. 211 The DIAMETER base protocol provides the minimum requirements needed 212 for an AAA transport protocol. The base protocol is not intended to 213 be used by itself, and must be used with an application-specific 214 extension, such as Mobile IP. The DIAMETER protocol was heavily 215 inspired and builds upon the tradition of the RADIUS [1] protocol. 217 2.1 Header Format 219 The base DIAMETER protocol is run over UDP port 1812. Implementations 220 MAY send packets from any source port, but SHOULD be prepared to 221 receive packets on port 1812. When a request is received, in order to 222 send a reply, the source and destination ports in the reply are 223 reversed. 225 A summary of the DIAMETER data format is shown below. The fields are 226 transmitted from left to right. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | RADIUS PCC |Flags|A|W| Ver | Message Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Identifier | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Next Send (Ns) | Next Received (Nr) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | AVPs ... 238 +-+-+-+-+-+-+-+-+-+-+-+-+- 240 RADIUS PCC (Packet Compatibility Code) 241 The RADIUS PCC field is a one octet field which is used for 242 backward compatibility with RADIUS. In order to easily distinguish 243 DIAMETER messages from RADIUS a special value has been reserved 244 and allows an implementation to support both protocols 245 concurrently using the first octet in the header. The RADIUS PCC 246 field MUST be set as follows: 248 254 DIAMETER message 250 PKT Flags 251 The Message Flags field is five bits, and is used in order to 252 identify any options. This field MUST be initialized to zero. The 253 following flag may be set: 255 The 'W' bit (Window-Present) is set when the Next Send (Ns) and 256 Next Received (Nr) fields are present in the header. Should 257 DIAMETER be implemented over a reliable transport, the 'W' 258 should not be set. 260 The 'A' bit is set to indicate that the message is an 261 acknowledgement only and does not contain a Command-Code AVP 262 following the header. Note that the Security AVPs MUST still be 263 present within an acknowledgment message. 265 Version 266 This field MUST be set to 1 to indicate DIAMETER Version 1. 268 Message Length 269 The Message Length field is two octets. It indicates the length 270 of the DIAMETER message including the header fields. 272 Identifier 273 The Identifier field is four octets, and aids in matching requests 274 and replies. The sender MUST ensure that the identifier in a 275 message is locally unique (to the sender) at any given time, and 276 MAY attempt to ensure that the number is unique across reboots. 277 The identifier is normally a monotonically increasing number, 278 whose start value was randomly generated. DIAMETER servers should 279 consider a message to be unique by examining the source address, 280 source port and Identifier field of the message. 282 Next Send 283 This field is present when the Window-Present bit is set in the 284 header flags. The Next Send (Ns) is copied from the send sequence 285 number state variable, Ss, at the time the message is transmitted. 286 Ss is incremented after copying if the message is not a ZLB ACK. 288 Next Received 289 This field is present when the Window-Present bit is set in the 290 header flags. Nr is copied from the receive sequence number state 291 variable, Sr, and indicates the sequence number, Ns, +1 of the 292 highest (modulo 2^16) in-sequence message received. See section 293 3.0 for more information. 295 AVPs 296 AVPs is a method of encapsulating information relevant to the 297 DIAMETER message. See section 2.2 for more information on AVPs. 299 2.1.1 ZLB Message Format 301 Zero Length Body messages are used to explicitly acknowledge one or 302 more DIAMETER message, and contain no additional Authentication, 303 Authorization or Accounting related AVPs. ZLB messages must contain 304 authentication AVPs, otherwise attacks could be mounted against 305 DIAMETER nodes. 307 The format of a ZLB message will be as follows: 309 ::= 310 311 312 { || 313 [11] } 315 2.2 AVP Format 317 DIAMETER AVPs carry specific authentication, accounting and 318 authorization information as well as configuration details for the 319 request and reply. 321 Some AVPs MAY be listed more than once. The effect of this is AVP 322 specific, and is specified in each case by the AVP description. 324 Each AVP of type 'string' and 'data' MUST be padded to align on a 32 325 byte boundary. Zero bytes are added to the end of the AVP value till 326 a word boundary is reached. 328 2.2.1 AVP Header 330 The AVP format is shown below and MUST be sent in network byte order. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | AVP Code | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | AVP Length | Cmd Flags | Reserved |T|V|H|M| 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Vendor ID (opt) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Tag (opt) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Data ... 344 +-+-+-+-+-+-+-+-+ 346 AVP Code 347 The AVP Code identifies the attribute uniquely. If the Vendor- 348 Specific-AVP is set, the AVP Code is allocated from the vendor's 349 private address space. 351 The first 256 AVP numbers are reserved for backward compatibility 352 with RADIUS and are to be interpreted as per RADIUS [1]. AVP 353 numbers 256 and above are used for DIAMETER, which are allocated 354 by IANA (see section 6.0). 356 AVP Length 357 The AVP Length field is two octets, and indicates the length of 358 this Attribute including the AVP Code, AVP Length, AVP Flags, 359 Reserved, the Tag and Vendor ID fields if present and the AVP 360 data. If a message is received with an Invalid attribute length, 361 the message SHOULD be rejected. 363 Command Flags 364 The Command Flag field is a bit-field that can be used by 365 individual command codes. Any Command Code that makes use of these 366 bits MUST define their value, and how they are used. Note that 367 only AVPs with the AVP Code set to Command-Code may use these 368 bits, otherwise the bits MUST be set to zero (0). 370 AVP Flags 371 The AVP Flags field informs the DIAMETER host how each attribute 372 must be handled. Note that subsequent DIAMETER extensions MAY 373 define bits to be used within the AVP Header, and an unrecognized 374 bit should be considered an error. Reserved bits should be set to 375 0 and ignored on receipt. 377 The 'M' Bit, known as the Mandatory bit, indicates whether support 378 of the AVP is required. If an AVP is received with the 'M' bit 379 enabled and the receiver does not support the AVP, the message 380 MUST be rejected. 382 AVPs without the 'M' bit enabled are informational only and a 383 receiver that receives a message with such an AVP that is not 384 supported MAY simply ignore the AVP. 386 When the 'H' bit is enabled it indicates that the AVP data is 387 encrypted using hop-by-hop encryption. See section 4.5 for more 388 information. 390 The 'V' bit, known as the Vendor-Specific bit, indicates whether 391 the optional Vendor ID field is present in the AVP header. When 392 set the AVP Code belongs to the specific vendor code address 393 space. 395 The 'T' bit, known as the Tag bit, is used to group sets of AVPs 396 together. Grouping of AVPs is necessary when more than one AVP is 397 needed to express a condition. If this bit is set, the optional 398 Tag field will be present. 400 Unless otherwise noted, AVPs will have the following default AVP 401 Flags field settings: 402 The 'M' bit MUST be set. The 'V' bit MUST NOT be set. The 'H' 403 and 'T' bits MAY be set. 405 2.2.2 Optional Header Elements 407 The AVP Header consists of several optional fields. These fields are 408 only present if their respective bit-flags are enabled. 410 Vendor ID 411 The Vendor Id field is present in the 'V' bit is set in the AVP 412 Flags field. The optional four octet Vendor ID field contains the 413 IANA assigned "SMI Network Management Private Enterprise Codes" 414 [2] value, encoded in network byte order. Any vendor wishing to 415 implement DIAMETER extensions can use their own Vendor ID along 416 with private Attribute values, guaranteeing that they will not 417 collide with any other vendor's extensions, nor with future IETF 418 extensions. 420 A vendor id value of zero (0) corresponds to the IETF adopted AVP 421 values, as managed by the IANA. Since the absence of the vendor id 422 field implies that the AVP in question is not vendor specific, 423 implementations SHOULD not use the zero (0) vendor id. 425 Tag 426 The Tag field is four octet in length and is intended to provide a 427 means of grouping attributes in the same message which refer to 428 the same set. If the Tag field is unused, the 'T' bit MUST NOT be 429 set. 431 2.2.3 AVP Value Formats 433 The Data field is zero or more octets and contains information 434 specific to the Attribute. The format and length of the Data field is 435 determined by the AVP Code and AVP Length fields. Note that messages 436 which are larger than the path MTU will cause IP fragmentation and 437 messages SHOULD be kept to that size wherever possible. In any case 438 UDP limits messages to 2^16 bytes. 440 The format of the value field MAY be one of six data types. It is 441 possible for an attribute to have a structure and this MUST be 442 defined along with the attribute. 444 Data 445 The data contains a variable length of arbitrary data. Unless 446 otherwise noted, the AVP Length field MUST be set to at least 447 9. 449 String 450 The data contains a variable length string using the UTF-8 451 character set. Unless otherwise noted, the AVP Length field 452 MUST be set to at least 9. 454 Address 455 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most 456 significant octet first. The format of the address (IPv4 or 457 IPv6) is determined by the length. If the attribute value is an 458 IPv4 address, the AVP Length field MUST be 12, otherwise the 459 AVP Length field MUST be set to 24 for IPv6 addresses. 461 Integer32 462 32 bit value, most significant octet first. The AVP Length 463 field MUST be set to 12. 465 Integer64 466 64 bit value, most significant octet first. The AVP Length 467 field MUST be set to 16. 469 Time 470 32 bit unsigned value, most significant octet first -- seconds 471 since 00:00:00 GMT, January 1, 1900. The AVP Length field MUST 472 be set to 12. 474 2.3 Error Reporting 476 There are five different types of errors within DIAMETER. The first 477 being where a DIAMETER message is poorly formatted and 478 unrecognizable, indicated below by "Bad Message". This error 479 condition applies if a received message creates a fatal error (e.g. 480 fails transport level authentication, cannot be parsed, etc). 482 The second case involves receiving a DIAMETER-Command AVP that is not 483 supported, which is shown below by "Unknown Command". The third case 484 is where an AVP is received, marked mandatory and is unknown by the 485 receiver, which is labeled below as "Unknown AVP". 487 This fourth case involves receiving a message with a known AVP, yet 488 the value is either unknown or illegal, which is shown below as "Bad 489 Value". The last case occurs when an error occurs while processing a 490 specific extension command, which is not related to the message 491 format and is labeled "Extension Error" below. 493 Error Type Ignore Message Send Extension 494 Message-Reject-Ind Response + 495 Result-Code 496 Bad Message X 497 Unknown Command X 498 Unknown AVP X 499 Bad Value X 500 Extension Error X 502 "Ignore Message" indicates that the message is simply dropped. The 503 "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST 504 be sent to the peer as described in the appropriate section. The 505 "Extension Response + Result-Code" indicates that the appropriate 506 Response to the message MUST be sent with the Result-Code or Error- 507 Code AVP set to a value that enables the peer to understand the 508 nature of the problem. 510 3.0 Reliable Transport 511 This section provides a detailed overview of how DIAMETER is reliably 512 transported over UDP. DIAMETER provides its own reliable transport 513 due to its unique requirements, which include: 515 -Rapid discovery of the failure of a communicating peer. 516 -Transactions of few messages will be the norm, so the TCP 517 slow start algorithm is in appropriate. 518 -The retransmission scheme required is more agressive than 519 TCP provides. 521 3.1 Flow Control 523 ZLB messages are used to acknowledge DIAMETER messages to the 524 communicating peer. 526 The DIAMETER header contains two fields used for reliable transport: 527 Nr (Next Received) and Ns (Next Send). The sequence number state for 528 each peer is represented (for clarity of discussion) as Sr (the next 529 in-sequence message expected to be received) and Ss (the next in- 530 sequence message to be sent). Sr and Ss are initialized to 0. 532 The sequence number is a free ranging counter modulo 65536. For 533 purposes of detecting duplication, a received sequence value is 534 considered less than or equal to the last received value if its value 535 lies in the range of the last value and its 32767 successor values. 536 For example if the last received sequence number was 15, the packets 537 received with Ns values in the range 32783..65535, or 0..15 would be 538 considered duplicates. Duplicate messages are silently discarded. 540 Each subsequent non-ZLB message is sent with a sequence number 541 incremented by one (modulo 2^16). The following rules apply: 543 - When a non-ZLB message is received with a Ns value which matches 544 the peer's Sr value, Sr is incremented by one. Sr is not modified 545 if a message is received with a Ns value greater than the current 546 Sr value. 548 - In messages which are sent to a peer, Nr is set to reflect one 549 higher than the Ns value of the highest (module 2^16) in-order 550 message received from the peer. 552 - Every time a peer sends a non-ZLB message, it sends the message 553 with Ns set to the current value of Ss. The value of Ss for that 554 peer is then incremented by one (modulo 2^16). 556 - Every time a peer receives an in-order non-ZLB message, the 557 receiving peer must increment its Sr value. The peer MUST 558 acknowledge the message, either by sending a ZLB message with the 559 updated Nr value, or by piggybacking the acknowledgement in any 560 outgoing message sent to the communicating peer. In this 561 piggybacked message, the Nr field will be set to its updated 562 value. Appendix D defines an OPTIONAL algorithm for delaying 563 acknowledgments, to wait for outgoing messages to piggyback 564 acknowledgements on. 566 - Messages which are sent MUST be queued and retransmitted till 567 the peer sends an acknowlegment. Messages SHOULD be retransmitted 568 at least three times. Appendix A recommends a retransmission 569 timer algorithm. 571 Retransmitted messages SHOULD include the current value of Sr in the 572 Nr field. An implementation MAY choose not to update Nr field (and 573 Timestamp AVP) for retransmitted messages, in order to avoid having 574 to perform another hash in the Integrity-Check- Vector AVP. The 575 message identifier in the retransmitted message MUST NOT be changed. 577 A DIAMETER implementation MAY queue out of order DIAMETER messages 578 for subsequent processing. 580 The receive window is the number of unacknowledged packets which can 581 be outstanding to a DIAMETER peer. When transmitting packets, a 582 DIAMETER peer must obey the receive window size offered by its peer. 583 The default window size is 7. Once the number of unacknowledged 584 messages equals the window size, the window is 'closed.' Previously 585 transmitted packets may be retransmitted when the peer's window is 586 closed. A peer can explicitly specify its window size in the 587 Device-Reboot-Ind message in the Receive-Window AVP. 589 A peer MAY return a Nr value in a ZLB or piggybacked in a non-ZLB 590 message which is less than the latest Sr value, due to congestion. 591 Returning a value in Nr of the first value in the window will have 592 the effect of preventing the communicating peer from sending any new 593 messages. 595 See Appendix B for some examples of how sequence numbers progress. 597 3.2 Peer failure recovery 599 A DIAMETER message with the Command-Code AVP set to Device-Reboot-Ind 600 and the Ns and Nr values set to zero (0) indicates that the peer has 601 rebooted. This message MUST be recognized and supported by a 602 DIAMETER implementation. When this event occurs, the Ss and Sr values 603 must be reset and the retransmission queue MUST be cleared. Since the 604 protocol requires that all new messages include a random identifier 605 in the protocol header, a Device-Reboot-Ind that is received with the 606 same identifier as the last processed Device-Reboot-Ind is considered 607 a retransmission and SHOULD NOT change the peer's state to inactive. 609 Messages other than the Device-Reboot-Ind MUST NOT be sent to the 610 peer until both the acknowledgement for the transmitted Device- 611 Reboot-Ind AND the peer's Device-Reboot-Ind have been received. When 612 both of these have been received, the peer is considered to be in the 613 active state. 615 4.0 DIAMETER AVPs 617 This section will define the mandatory AVPs that MUST be supported by 618 all DIAMETER implementations. 620 The following AVPs are defined in this document: 622 Attribute Name Attribute Code Definition in Section 623 ------------------------------------------------------------ 624 DIAMETER-Command 256 4.1 625 Host-IP-Address 4 [1], 4.2 626 Host-Name 32 [1], 4.3 627 State 24 [1], 4.4 628 Class 25 [1], 4.5 629 Session-Timeout 27 [1], 4.6 630 Extension-Id 258 4.7 631 Integrity-Check-Value 259 4.8 632 Nonce 261 4.9 633 Timestamp 262 4.10 634 Session-Id 263 4.11 635 Vendor-Name 266 4.12 636 Firmware-Revision 267 4.13 637 Result-Code 268 4.14 638 Error-Code 269 4.15 639 Unrecognized-Command-Code 270 4.16 640 Reboot-Type 271 4.17 641 Reboot-Time 272 4.18 642 Failed-AVP-Code 279 4.19 643 User-Name 1 [1], 4.20 644 Receive-Window 277 4.21 645 Proxy-State 33 [1], 4.22 646 Redirect-Host 278 4.23 647 Broker-Issued-Certificate 280 4.24 649 4.1 DIAMETER-Command AVP 651 Description 652 The DIAMETER-Command AVP MUST be the first AVP following the 653 DIAMETER header. This AVP is used in order to communicate the 654 command associated with the message. A DIAMETER message can have 655 at most one DIAMETER-Command AVP. Unless noted otherwise, all 656 command codes defined in this document will use the following 657 format: 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 AVP Header (AVP Code = 256) 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Command Code | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 AVP Length 668 The length of this attribute MUST be at least 12. The exact 669 length of the AVP is determined by the actual Command and is 670 defined with each command. 672 AVP Flags 673 The 'M' bit MUST be set. The 'V' MAY be set if the Command Code 674 is vendor specific. The 'H', 'T' bits MUST NOT be set. 676 Command Code 677 The Command Code field contains the command number. The 678 following commands are defined and MUST be supported by all 679 DIAMETER implementations in order to conform to the base 680 protocol specification: 682 Command Name Command Code 683 ----------------------------------- 684 Message-Reject-Ind 256 685 Device-Reboot-Ind 257 686 Device-Watchdog-Ind 258 688 4.1.1 Message-Reject-Ind (MRI) 690 Description 692 The Message-Reject-Ind command provides a generic means of 693 completing transactions by indicating errors in the messages which 694 initiated them. The Message-Reject-Ind command is a possible 695 response to any DIAMETER command. Some some DIAMETER commands MAY 696 expect more specialized error messages, depending on the error 697 type. 699 The Message-Reject-Ind message MUST contain the same 700 identification in the header and include the Session-Id if it was 701 present in the original message that it is responding to, even if 702 the identification is erroneous. The receiver of a Message- 703 Reject-Ind SHOULD examine the Result-Code AVP provided before 704 processing the identification, in order to handle the latter 705 appropriately. 707 Message Format 709 The structure of the Message-Reject message is defined as follows: 711 ::= 712 713 714 [] 715 [] 716 717 [ ] 718 { || 719 } 720 721 722 { || 723 [11]} 725 where the Identifier value in the message header and optionally 726 the Session-Id AVP are copied from the message being rejected and 727 the DIAMETER-Command AVP has the format described below. The 728 Result-Code and conditionally-present Error-Code AVPs indicate the 729 nature of the error causing rejection, and the conditionally- 730 present Failed-AVP-Code AVP provides some minimal debugging data 731 by indicating a specific AVP type which caused the problem. See 732 the description of the Result-Code AVP for indication of when the 733 Error-Code and/or Failed-AVP-Code AVPs will be present in the 734 message. The Unrecognized-Command-Code AVP is present only when 735 the reason for message rejection is an unrecognized or unsupported 736 command code. 738 The length of the DIAMETER Command AVP must be 12 when the Command 739 Code is set to 256 (Message-Reject-Ind). 741 4.1.2 Device-Reboot-Ind (DRI) 743 Description 745 A DIAMETER device sends the Device-Reboot-Ind message to inform 746 all of its peers either of an upcoming reboot or that it has just 747 rebooted. 749 The Reboot-Type AVP MUST be present and indicates the type of 750 reboot associated with this command. Note that a DIAMETER device 751 should only send this message once it is able to receive network 752 traffic. 754 This message is also used by a DIAMETER device in order to 755 exchange the supported protocol version number as well as all 756 supported extensions. The originator of this message SHOULD insert 757 it's highest supported version number within the DIAMETER header. 758 Similarly the originator of this message MUST include all 759 supported extensions within the message. 761 It is desirable for a DIAMETER device to retain the supported 762 extensions in order to ensure that only requests/responses are 763 sent to peers that support the extension in question. 765 This message MUST contain the Vendor-Name and Extension-Id AVPs. 767 In the case where a DIAMETER device is configured to communicate 768 with many peers, this message MUST be issued to each peer. The DRI 769 SHOULD be periodically retransmitted until an acknowledgement is 770 received. This retransmission timer MAY be different from the 771 timer used when the communication has been established, and SHOULD 772 be configurable. 774 No explicit DIAMETER message is necessary to acknowledge this 775 message since it is handled by DIAMETER's reliable transport. 777 Message Format 779 ::= 780 781 782 [] 783 784 [] 785 786 787 788 [] 789 [] 790 791 792 { || 793 [11]} 795 The length of the DIAMETER Command AVP must be 12 when the Command 796 Code is set to 257 (Device-Reboot-Ind). 798 4.1.3 Device-Watchdog-Ind (DWI) 800 Description 802 The Device-Watchdog-Ind is used as a keepalive mechanism between 803 two DIAMETER peers, and SHOULD be sent during after a configurable 804 period of inactivity. The lower the timer value is set to, the 805 quicker a host can pro-actively detect that a peer is no longer 806 reachable. However, the timer SHOULD NOT be set to a value that is 807 considered too low (e.g. 2 seconds), since it will generate 808 considerable traffic. This message MUST contain the Host-IP- 809 Address or Host-Name AVP as well as any security related AVPs. 811 No explicit DIAMETER message is necessary to acknowledge this 812 message since it is handled by DIAMETER's reliable transport. 814 Message Format 816 ::= 817 818 { || 819 } 820 821 822 { || 823 [11]} 825 The length of the Command Code AVP MUST be 12 when the Command Code 826 field is set to 258 (Device-Watchdog-Ind). 828 4.2 Host-IP-Address 830 The Host-IP-Address AVP (AVP Code 4) is of type Address and is used 831 to inform a DIAMETER peer of the sender's identity. The data portion 832 of this AVP contains the IP address of the originator of the DIAMETER 833 message. 835 The AVP flags for this AVP are different from the default value, and 836 have the following rules: 837 The 'M' bit MUST be set. The 'H' SHOULD NOT be set since 838 implementations could use this information to determine the shared 839 secret information necessary to authenticate the message. The 'T' 840 and 'V' bits MUST NOT be set. 842 4.3 Host-Name 844 The Host-Name AVP (AVP Code 32) is of type String, and is used to 845 inform a DIAMETER peer of the sender's identity. The data portion of 846 this AVP contains the host name of the originator of the DIAMETER 847 message. The host name MUST follow the NAI [8] naming conventions. 849 The AVP flags for this AVP are different from the default value, and 850 have the following rules: 851 The 'M' bit MUST be set. The 'H' SHOULD NOT be set since 852 implementations could use this information to determine the shared 853 secret information necessary to authenticate the message. The 'T' 854 and 'V' bits MUST NOT be set. 856 4.4 State 858 The State AVP (AVP Code 24) is sent by the server to the client when 859 the DIAMETER exchange can span multiple round-trip messages and is 860 used to maintain server state information. The opaque data MUST be 861 sent unmodified by the client to the server in subsequent messages 862 for the same Session-Id. 864 The data portion of the AVP is of type Data and the format of the 865 information is site or application specific, and SHOULD be treated as 866 opaque octets. 868 4.5 Class 870 The server sends the Class AVP (AVP Code 25) to the client during 871 authentication or authorization and MUST be sent unmodified by the 872 client to the accounting server as part of the accounting message if 873 accounting is supported. No interpretation of the opaque data should 874 be made by the client. 876 The data portion of the AVP is of type Data and the format of the 877 information is site or application specific, and SHOULD be treated as 878 opaque octets. 880 4.6 Session-Timeout 882 The Session-Timeout AVP (AVP Code 27) is of type Integer32 and 883 contains the maximum number of seconds of service to be provided to 884 the user before termination of the session. A value of zero means 885 that this session has an unlimited number of seconds before 886 termination. 888 This AVP can be provided by the client as a hint of the maximum 889 duration that it is willing to accept. However, the server DOES NOT 890 have to observe the hint and can return any value. A value of zero 891 provided by a client DOES NOT imply that service is being terminated. 893 4.7 Extension-Id 895 The Extension-Id AVP (AVP Code 258) is of type Integer32 and is used 896 in order to identify a specific DIAMETER extension. This AVP SHOULD 897 be used in the Device-Reboot-Ind command in order to inform the peer 898 what extensions are locally supported. 900 Each DIAMETER extension draft MUST have an Extension-Id assigned to 901 it by the IANA (see section 6.3). The base protocol does not require 902 a Extension-Id since its support is mandatory. 904 There MAY be more than one Extension-Id AVP within a DIAMETER 905 message. 907 4.8 Integrity-Check-Value 909 The Integrity-Check-Value AVP (AVP Code 259) is used for hop-by-hop 910 authentication and integrity, and is not recommended for use with 911 untrusted proxy servers. 913 The DIAMETER header as well as all AVPs (including padding) up to 914 this AVP is protected by the Integrity-Check-Value. Note that the 915 Message Length field in the DIAMETER header MUST be set to zero (0) 916 prior to the ICV calculation. The Timestamp AVP MUST be present to 917 provide replay protection and the Nonce AVP must be present to add 918 randomness to the message. All AVPs following this AVP must be 919 ignored. 921 The Integrity-Check-Value is generated in the method described in 922 section 5.5.1 924 All DIAMETER implementations MUST support this AVP. 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 AVP Header (AVP Code = 259) 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Transform ID | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Data ... 934 +-+-+-+-+-+-+-+-+ 936 AVP Length 937 The length of this attribute MUST be at least 13. 939 AVP Flags 940 The 'M' bit MUST be set and the 'T' bit MAY be set. The 'V' and 941 'H' bits MUST NOT be set. 943 Transform ID 944 The Transform ID field contains a value that identifies the 945 transform that was used to compute the ICV. The following 946 values are defined in this document: 948 HMAC-MD5-96[6] 1 950 Data 951 The Data field contains an ICV of the message up to this AVP. 953 4.9 Nonce 955 The Nonce AVP (AVP Code 261) is of type Data and MUST be present 956 prior to the Integrity-Check-Value AVPs within a message and is used 957 to ensure randomness within a message. The content of this AVP MUST 958 be a random value of at least 128 bits. 960 The AVP flags for this AVP are different from the default value, and 961 have the following rules: 962 The 'M' bit MUST be set and the 'T' bit MAY be set. The 'V' and 963 'H' bits MUST NOT be set. 965 4.10 Timestamp 967 The Timestamp AVP (AVP Code 262) is of type Time and is used to add 968 replay protection to the DIAMETER protocol. This AVP MUST appear 969 prior to the Integrity-Check-Value AVP or any other Integrity AVP 970 defined in separate extensions. The value of time is the most 971 significant four octets returned from an NTP server that indicates 972 the number of seconds expired since Jan. 1, 1900. 974 The AVP flags for this AVP are different from the default value, and 975 have the following rules: 976 The 'M' bit MUST be set and the 'T' bit MAY be set. The 'V' and 977 'H' bits MUST NOT be set. 979 Messages which are older than a certain maximum age SHOULD be 980 rejected and a MRI message with the Result-Code AVP value set to 981 DIAMETER_SEE_ERROR_CODE and the Error-Code AVP set to 982 DIAMETER_TIMEOUT. The recommended value for the maximum age of an 983 outstanding message is 4 seconds. 985 Note that the larger the value, the more susceptible one is to a 986 replay attack. However, one does have to take into account the 987 possibility for clock drift, and the latency involved in the 988 transmission of the message over the network. The timestamp AVP 989 SHOULD be updated prior to retransmission. 991 4.11 Session-Id 993 The Session-Id AVP (AVP Code 263) is of type Data and is used to 994 identify a specific session (see section 5.1). All messages 995 pertaining to a specific session MUST include only one Session-Id AVP 996 and the same value MUST be used throughout the life of a session. 997 When present, the Session-Id SHOULD appear immediately following the 998 DIAMETER-Command AVP. 1000 For any other messages that does not pertain to a specific session, 1001 multiple Session-Id AVPs MAY be present as long as the 'T' bit is 1002 set. 1004 The Session-Id MUST be globally unique at any given time since it is 1005 used by the server to identify the session (or flow). The format of 1006 the session identifier SHOULD be as follows: 1008 1011 It is suggested that the monotonically increasing 32 bit value NOT 1012 start at zero upon reboot, but rather start at a random value. This 1013 will minimize the possibility of overlapping Session-Ids after a 1014 reboot. Alternatively, an implementation MAY keep track of the 1015 increasing value in non-volatile memory. The optional value is 1016 implementation specific but may include a modem's device Id, a layer 1017 2 address, timestamp, etc. 1019 The session Id is created by the DIAMETER device initiating the 1020 session, which in most cases is done by the client. Note that a 1021 Session-Id can be used by more than one extension. 1023 4.12 Vendor-Name 1025 The Vendor-Name AVP (AVP Code 266) is of type String and is used to 1026 inform a DIAMETER peer of the Vendor Name of the DIAMETER device. 1027 This MAY be used in order to know which vendor specific attributes 1028 may be sent to the peer. It is also envisioned that the combination 1029 of the Vendor-Name and the Firmware-Revision AVPs can provide very 1030 useful debugging information. 1032 The AVP flags for this AVP are different from the default value, and 1033 have the following rules: 1034 The 'H' bits MAY be set. The 'T', 'V' and 'M' bits MUST NOT be 1035 set. 1037 4.13 Firmware-Revision 1039 The Firmware-Revision AVP (AVP Code 267) is of type Integer32 and is 1040 used to inform a DIAMETER peer of the firmware revision of the 1041 issuing device. 1043 For devices which do not have a firmware revision (general purpose 1044 computers running DIAMETER software modules, for instance), the 1045 revision of the DIAMETER software module may be reported instead. 1047 The AVP flags for this AVP are different from the default value, and 1048 have the following rules: 1049 The 'H' bits MAY be set. The 'T', 'V' and 'M' bits MUST NOT be 1050 set. 1052 4.14 Result-Code 1054 The Result-Code AVP (AVP Code 268) is of type Integer32 and indicates 1055 whether a particular request was completed successfully or whether an 1056 error occurred. The Result-Code AVP MUST be present in all DIAMETER 1057 messages of type *-Response or *-Answer. The following codes have 1058 been defined: 1060 DIAMETER_SUCCESS 0 1061 The Request was successfully completed. 1063 DIAMETER_FAILURE 1 1064 The Request was not successfully completed for an unspecified 1065 reason. A DIAMETER Message-Reject message returning this 1066 result SHOULD whenever possible also contain one or more 1067 Failed-AVP-Code AVPs indicating the attributes which caused the 1068 failure. 1070 DIAMETER_POOR_REQUEST 2 1071 The Request was poorly constructed. A DIAMETER Message-Reject 1072 message returning this result SHOULD whenever possible also 1073 contain one or more Failed-AVP-Code AVPs indicating the 1074 attributes which caused the failure. 1076 DIAMETER_INVALID_AUTH 3 1077 The Request did not contain a valid Integrity-Check-Value or 1078 Digital-Signature [11]. 1080 DIAMETER_UNKNOWN_SESSION_ID 4 1081 The Request contained an unknown Session-Id. 1083 DIAMETER_SEE_ERROR_CODE 5 1084 The Request failed. The message MUST also contain an Error-Code 1085 AVP which provides command-specific information on the failure. 1086 A DIAMETER Message-Reject-Ind message returning this result 1087 SHOULD whenever possible also contain one or more Failed-AVP- 1088 Code AVPs indicating the attributes which caused the failure. 1090 DIAMETER_COMMAND_UNSUPPORTED 6 1091 The Request contained a command code which the DIAMETER 1092 implementation does not recognize or does not support. The 1093 Message-Reject-Ind message MUST also contain an Unrecognized- 1094 Command-Code AVP which contains the Command Code value which 1095 was rejected. 1097 DIAMETER_TIMEOUT 1098 This error MAY be returned if a request if a message has been 1099 received that has a Timestamp AVP that is older than the 1100 maximum age that the communicating peer accepts. 1102 DIAMETER_ATTRIBUTE_UNSUPPORTED 8 1103 The Request contained an AVP with an AVP Code which the 1104 DIAMETER implementation does not recognize or does not support. 1105 An DIAMETER Message-Reject-Ind message returning this result 1106 MUST also contain one or more Failed-AVP-Code AVPs indicating 1107 the AVP Codes which caused the failure. 1109 DIAMETER_REDIRECT_INDICATION 9 1110 A proxy or broker has determined that the request could not be 1111 satisfied locally and the initiator of the request should 1112 direct the request directly to the server, whose contact 1113 information has been added to the response. 1115 DIAMETER_DOMAIN_NOT_SERVED 10 1116 A proxy or broker has determined that it is unable to forward 1117 the request or provide redirect information since the domain 1118 requested is unknown. 1120 DIAMETER_INVALID_TRANSFORM 11 1121 A message was received that included an Integrity-Check-Value 1122 or Digital-Signature that made use of an unsupported transform. 1124 4.15 Error-Code 1126 The Error-Code AVP (AVP Code 269) is of type Integer32 and contains 1127 the message specific error code, if any. This AVP only needs to be 1128 present if the Result-Code AVP is present with the 1129 DIAMETER_SEE_ERROR_CODE. 1131 Error-Code values and corresponding semantics are specific to the 1132 command to which the Error-Code is a response, and MUST therefore be 1133 documented as part of the description of that command. 1135 4.16 Unrecognized-Command-Code 1137 The Unrecognized-Command-Code AVP (AVP Code 270) is of type Integer32 1138 and contains the offending Command Code that resulted in sending the 1139 Message-Reject-Ind message. 1141 4.17 Reboot-Type 1143 The Reboot-Type AVP (AVP Code 271) is of type Integer32 and MUST be 1144 present in the Device-Reboot-Indication message. This AVP contains an 1145 indication of the type of that has or will occur. The following 1146 values are currently supported: 1148 REBOOT_IMMINENT 1 1149 When the Reboot-Type AVP is set to this value it is an 1150 indication that the DIAMETER peer is about to reboot and should 1151 not be sent any additional DIAMETER messages besides the 1152 acknowledgement. 1154 REBOOTED 2 1155 When the Reboot-Type AVP is set to this value it is an 1156 indication that the DIAMETER peer has recently rebooted and is 1157 ready to accept new DIAMETER messages. 1159 4.18 Reboot-Time 1161 The Reboot-Time AVP (AVP Code 272) is of type Integer32 and MAY be 1162 present in the DRI. The value of this AVP indicates the number of 1163 seconds before the issuer expects to be ready to receive new DIAMETER 1164 messages. This AVP MAY only be present when the Reboot-Type AVP is 1165 set to REBOOT_IMMINENT. The value indicated by this AVP should be 1166 used as an estimate and is not a hard rule. 1168 4.19 Failed-AVP-Code 1170 The Failed-AVP-Code AVP (AVP Code 279) is of type Data and provides 1171 debugging information in cases where a request is rejected or not 1172 fully processed due to erroneous information in a specific AVP. The 1173 documentation of the Result-Code AVP and of the Message-Reject-Ind 1174 command provide information on the use of the Failed-AVP-Code AVP. 1176 The Data field contains the complete AVP that could not be processed 1177 successfully. Possible reasons for this are an improperly-constructed 1178 AVP, an unsupported or unrecognized AVP Code, or an invalid value. 1180 4.20 User-Name 1182 The User-Name AVP (AVP Code 1) is of type String and contains the 1183 User-Name in a format consistent with the NAI specification [8]. All 1184 DIAMETER systems SHOULD support usernames of at least 72 octets in 1185 length. 1187 4.21 Receive-Window 1189 The Receive-Window AVP (AVP Code 277) is of type Integer32 and 1190 contains the maximum number of outstanding unacknowledged messages 1191 that it is willing to accept for a given peer. Once the number of 1192 unacknowledged messages has reached this number, the receive window 1193 is considered closed. The default value for the receive window is 7, 1194 and SHOULD be configurable. 1196 A node MUST stop sending messages when it detects that the number of 1197 unacknowledged messages is equal to the peer's receive window size. 1199 4.22 Proxy-State 1200 The Proxy-State AVP (AVP Code 33) 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 A DIAMETER node that receives such an AVP in a request MUST return 1207 the identical AVP in the response. Furthermore, only one such AVP may 1208 be present in a message at any given time, so implementations MUST 1209 ensure that they remove any Proxy-State AVPs before adding their own. 1211 If the Proxy-State AVP was removed from a request, the same AVP must 1212 be inserted in the corresponding response before forwarding the 1213 message to the downstream peer. 1215 The Proxy-State AVP's Address field is intended to be used by 1216 DIAMETER hosts in order to assist in determining if the AVP was 1217 locally generated. 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 AVP Header (AVP Code = 33) 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | 128-bit Address... 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Data ... 1227 +-+-+-+-+-+-+-+-+ 1229 AVP Flags 1230 The 'M' bit MUST be set. The 'V', 'H' and 'T' bits MUST NOT be 1231 set. 1233 Address 1234 The Address field is a 128-bit field that contains the IP 1235 address of the system that created the Proxy-State AVP. If the 1236 host creating the AVP has an IPv4 address, the leading 96 bits 1237 MUST be set to zero. This field is intended to assist hosts in 1238 determining if a Proxy-State AVP in a message was locally 1239 created. 1241 Data 1242 The Data field is one or more octets. The actual format of the 1243 information is site or application specific, and SHOULD be 1244 treated as undistinguished octets. 1246 4.23 Redirect-Host 1247 The Redirect-Host AVP (AVP Code 278) is of type Address and is 1248 returned in a response that has the Result-Code AVP set to 1249 DIAMETER_REDIRECT_REQUEST. This AVP includes address information 1250 about the DIAMETER host to which the request must be redirected. Upon 1251 receipt of such a Result-Code, and this AVP, a DIAMETER host SHOULD 1252 send the request directly to the host. A proxy server or broker MAY 1253 return more than one Redirect-Host AVP if there is a group of 1254 DIAMETER servers that can satisfy the request. 1256 4.24 Broker-Issued-Certificate 1258 The Broker-Issued-Certificate AVP (AVP Code 280) is typically added 1259 by a broker in a network where the broker's organization also 1260 provides certificate authority services. In such networks, 1261 certificates are issued to all DIAMETER servers within the roaming 1262 consortium. The Broker-Issued-Certificate AVP contains a timestamp 1263 and an expiration time, which CAN be used by DIAMETER hosts in order 1264 to determine whether they should further validate the certificate 1265 against a certification validation infrastructure (see section 5.6.2 1266 for more information). 1268 0 1 2 3 1269 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 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 AVP Header (AVP Code = 280) 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Timestamp | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Expiration Time | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Certificate Length | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Digital Signature Length | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Certificate ... 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Digital Signature ... 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 AVP Length 1287 The length of this attribute MUST be at least 24. 1289 Timestamp 1290 The Timestamp field contains the time when the AVP was created. 1291 This field is in the data format defined in Section 2.2.3. 1293 Expiration 1294 The Expiration field contains the time after which the broker 1295 recommends that a new Broker-Certificate be retrieved. This 1296 field is in the data format defined in Section 2.2.3. 1298 Certificate Length 1299 The Certificate Length field contains the number of octets of 1300 the certificate in the certificate field. 1302 Digital-Signature Length 1303 The Digital-Signature Length field contains the number of 1304 octets of the signature found in the Digital Signature field. 1306 Certificate 1307 The certificate field contains the X.509 certificate [19]. 1309 Digital-Signature 1310 The Digital-Signature field contains the broker's digital 1311 signature [11]. 1313 5.0 Protocol Definition 1315 The base DIAMETER protocol is never used on its own. It is always 1316 extended for a particular application. The base DIAMETER protocol 1317 concerns how messages are sent, resent and how peers may eventually 1318 be abandoned. The base protocol also defines certain rules which 1319 apply to all exchanges of messages between DIAMETER peers. It is 1320 important to note that the base protocol requires that every message 1321 includes some AVPs (Nonce, Timestamp, Integrity-Check-Vector or 1322 Digital-Signature). 1324 Communication between DIAMETER peers begins with one peer sending a 1325 message to another DIAMETER peer. The set of AVPs included in the 1326 message is determined by a particular application of or extension to 1327 DIAMETER. (We will refer to this as the DIAMETER extension). One 1328 AVP which is included in the initial communication is the Session-Id. 1330 The communicating party may accept or reject the request which 1331 contains a new Session-Id, or return Result-Code and Error-Code AVPs 1332 if the request cannot be processed. The behavior of the 1333 communicating peer depends on the DIAMETER extension employed. 1335 Exchanges of messages are either request/reply oriented, or in some 1336 special cases, do not require replies. All such messages which do 1337 not require replies (or acknowledgments) have names which end with 1338 '-Ind' (short for Indication). All messages require a transport 1339 level acknowledgement, either through a ZLB, or by piggybacking an 1340 acknowledgement in a non-ZLB message. 1342 Communicating DIAMETER peers retain state relating to transport 1343 (sequence numbers and the like). This state information may be 1344 discarded when the communicating peer is determined to be 1345 unreachable. This occurs when the peer does not acknowledge receipt 1346 of a DIAMETER message that has been retransmitted a maximum number of 1347 times. The Device-Watchdog-Ind is used to pro-actively probe the peer 1348 to ensure that communication is still possible. 1350 Freeing the transport state associated with a communication with a 1351 DIAMETER peer is entirely independent of freeing session state 1352 (associated with a Session-Id). This can only be done according to 1353 rules established in a particular extension/application of DIAMETER. 1355 DIAMETER extensions MUST define an explicit exchange of messages 1356 which allow a peer to inform the other party that a session has been 1357 terminated. 1359 5.1 Session Identifiers 1361 When a user requests access to the network, a DIAMETER client issues 1362 an authentication and authorization request to its local server. The 1363 request contains a Session-Id AVP, which is used in subsequent 1364 messages (e.g. subsequent authorization, accounting, etc) relating to 1365 the user's session. The Session-Id AVP is a means for the client and 1366 servers to correlate a DIAMETER message with a user session. 1368 When a DIAMETER server authorizes a user to use network resources, it 1369 typically adds the Session-Timeout AVP to the response. The Session- 1370 Timeout AVP defines how long the user can make use of the resources 1371 before another authorization request is sent to the server. Should 1372 the server not receive another authorization request before the 1373 timeout occurs, it SHOULD release any state information related to 1374 the user's session. 1376 The base protocol does not include any authorization request 1377 messages, since these are largely application-specific and are 1378 defined in a DIAMETER protocol extension document. Such extensions 1379 SHOULD provide a message that allows a client to inform a server that 1380 the user's session has been released. This would enable the server to 1381 free state information instead of having to wait for the timeout to 1382 occur. 1384 5.2 DIAMETER Bootstrap Message 1386 DIAMETER provides a message that is used to indicate either an 1387 imminent reboot, or that a reboot has occurred. The DRI message MUST 1388 be sent to all known DIAMETER peers both previous to a reboot when 1389 possible as well as following a reboot. 1391 The Reboot-Type AVP is used to indicate the type of reboot associated 1392 with the DRI. When set to REBOOT_IMMINENT, all peers should be warned 1393 that any new DIAMETER requests sent to the issuer will probably not 1394 be received or processed. If a request MUST be sent it would be 1395 preferable to issue the request to an alternate peer if available. 1397 The message includes an optional Reboot-Time AVP that specifies an 1398 estimate of how long before the issuer is available to receive new 1399 DIAMETER messages. 1401 Upon reboot, the host MUST issue a DRI message with the Reboot-Type 1402 AVP set to REBOOTED. This is an indication that new DIAMETER messages 1403 may be sent to the transmitter of the DRI. 1405 Note that the Reboot-Time AVP is not required, and when present 1406 provides an estimate and should not be used as a hard value. In the 1407 case of a software implementation (server) running on a general 1408 purpose operating system, the Reboot-Time AVP will probably not be 1409 present since it is possible that the DIAMETER server has been 1410 stopped and it is not possible to know how long before (and if) it 1411 will be restarted. 1413 Upon receipt of this message the peer's Ss and Sr variables must be 1414 reset. It is possible for this message to be received outside the 1415 window (Ns and Nr set to zero) when it follows a reboot. 1417 The DIAMETER Reboot-Ind message does not require a reply. The message 1418 is acknowledged using DIAMETER's reliable transport. See appendix E 1419 for more information. 1421 5.2.1 State Machine 1423 A DIAMETER node initially considers all known peers to be in the 1424 closed state, and should not process any DIAMETER message with the 1425 exception of acknowledgements and the DRI. Once the DIAMETER peer is 1426 set to the open state, any DIAMETER message may be accepted and 1427 processed. The following is a suggested state machine. 1429 If at any time no transport level acknowledgement is received and the 1430 message was retransmitted the maximum number of times, the session 1431 with the peer MUST be closed, and all associated state with the peer 1432 MUST be freed. 1434 State Event Action New State 1435 ----- ----- ------ --------- 1436 closed Local Open send DRI wait-ack1 1437 Request 1439 closed receive DRI send ACK wait-ack2 1440 send DRI 1442 closed receive invalid cleanup closed 1443 DRI 1445 wait-ack1 receive ACK accept Incoming wait-ack1 1446 Messages 1448 wait-ack1 receive DRI send ACK open 1449 Accept Incoming 1450 Messages 1452 wait-ack1 no ACK received cleanup closed 1454 wait-ack2 received ACK Accept Incoming open 1455 Messages 1457 wait-ack2 no ACK received cleanup closed 1459 open receive DRI send ACK wait-ack2 1460 Rebooted send DRI 1462 open receive DRI cleanup closed 1463 Imminent-Reboot 1465 open receive DWI send ACK open 1467 open receive other send ACK open 1468 messages 1470 open no ACK received cleanup closed 1472 5.3 Keepalive Exchange 1474 DIAMETER uses the Device-Watchdog-Ind message as a keepalive 1475 mechanism. DIAMETER entities that need to ensure that connectivity 1476 with a peer is not lost may use this mechanism. Each node is 1477 responsible for sending their own Device-Watchdog-Ind message to its 1478 peer when no activity is present for some time, which can be 1479 configurable. Note that it is possible for each node in the network 1480 to have a different inactivity timer configured. The more aggressive 1481 the timer, the more traffic is generated, but the quicker it can 1482 detect if a peer is no longer reachable. 1484 A DIAMETER Client can use this mechanism to ensure that fail-over to 1485 an alternate server occurs even without any AAA traffic. DIAMETER 1486 Servers use this mechanism to identify when a particular client is no 1487 longer reachable. Redundant DIAMETER Servers can use this mechanism 1488 to identify when the primary server is no longer available. Proxy 1489 Servers can equally use this method to identify when a particular 1490 domain's server is no longer reachable. 1492 The DIAMETER Device-Watchdog-Ind message does not require a reply. 1493 The message is acknowledged using DIAMETER's reliable transport. See 1494 appendix F for more information. 1496 5.4 AVP Handling Rules 1498 5.4.1 Unrecognized Command Support 1500 The DIAMETER protocol provides a message that is used to inform a 1501 peer that a DIAMETER message was received with an unrecognized 1502 command (see appendix G for more information). The following provides 1503 a DIAMETER message that is sent to a peer: 1505 ::= 1506 1507 1508 [] 1509 1510 1511 { || 1512 [11] } 1514 Upon receipt of the above message, the receiver notices that it does 1515 not support the command and sends the following message: 1517 ::= 1518 1519 1520 1521 [] 1522 1523 1524 { || 1525 [11] } 1527 5.4.2 The art of AVP Tagging 1529 The AVP Header provides the 'T' bit that is used for grouping AVPs 1530 together. Although the base protocol does not define any AVPs that 1531 need to be grouped, it is envisioned that DIAMETER extensions will 1532 require tag support. 1534 In the case where multiple AVPs are needed to indicate a specific 1535 authorization "rule" tagging is appropriate. Such an example is taken 1536 from [10] that discusses Tunneling attributes. In this case multiple 1537 AVPs are required in order to specify tunnel parameter, and more than 1538 one set of AVPs MAY be present in the message. This is necessary in 1539 order to support redundant tunnel servers. 1541 In this case, the AVPs that need to be grouped together would have a 1542 specific tag value, and each group would use a different tag value. 1544 5.5 DIAMETER Message Security 1546 5.5.1 Using the Integrity-Check-Value 1548 The use of the Integrity-Check-Value (ICV) AVP requires a pre- 1549 configured shared secret. Although this mechanism does not scale as 1550 well as the Digital Signature, it may be desirable to use this 1551 mechanism in the case where asymmetric technology is not required or 1552 available. It is recommended that the key size used in the 1553 computation of the ICV be sufficiently long (e.g. 128 bits), and that 1554 different keys be used for both authentication and encryption (see 1555 section 5.5.2). 1557 Note that in the case where two DIAMETER nodes need to communicate 1558 through an intermediate node (i.e. Proxy) it does not offer any end- 1559 to-end data integrity or encryption as each node must re-compute the 1560 Integrity-Check-Value AVP. 1562 The Timestamp and Nonce AVPs MUST be present in the message PRIOR to 1563 the Integrity-Check-Value AVP. The Timestamp AVP provides replay 1564 protection and the Nonce AVP provides randomness. 1566 The Data field of the AVP contains an HMAC-MD5-96[6] of the message 1567 up to the ICV AVP. Prior to computing the hash value, the Message 1568 Length field in the DIAMETER header (see section 2.1) MUST be set to 1569 zero. Using the example code provided in [6], the following call 1570 would be used to generate the Integrity-Check-Value: 1572 hmac_md5(DiameterMessage, MessageLength, Secret, Secretlength, 1573 Output) 1575 The following is an example of a message that include hop-by-hop 1576 security: 1578 ::= 1579 1580 [] 1581 1582 1583 1585 Any AVPs in a message that is not succeeded by the Integrity-Check- 1586 Value AVP MUST be ignored. 1588 5.5.2 AVP Encryption with Shared Secrets 1590 This method of encrypting AVP data is the simplest to use and MUST be 1591 supported by all DIAMETER implementations. However, local policy MAY 1592 determine that the use of this mechanism is not permitted. 1594 The 'H' bit MUST only be set if a shared secret exists between both 1595 DIAMETER peers. If the 'H' bit is set in any DIAMETER AVP, the Nonce 1596 AVP MUST be present prior to the first encrypted AVP. 1598 The length of the AVP value to be encrypted is first encoded in the 1599 following Subformat, which is included in the AVP's data field. 1601 0 1 2 3 1602 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 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | length of plain text data | plain text data ... 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | Padding ... 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Length 1611 The Length field contains the length of the decrypted data. 1613 plain text data 1615 Data of AVP that is to be obscured. 1617 Padding 1619 If the plain text does not align on the byte boundary required by 1620 the hashing algorithm (e.g. 16 octets for MD5), it is highly 1621 recommended that random padding be added to obscure the length of 1622 the plain text data. 1624 The resulting subformat MAY be padded to a multiple of 16 octets in 1625 length. For example, if the plain text data to be obscured is a 1626 string containing 6 characters (e.g. password 'foobar'), then 8 + n * 1627 16 octets of padding would be applied. Padding does NOT alter the 1628 value placed in the Length of the ClearText Data, only the length of 1629 the AVP itself. 1631 Next, An MD5 hash is performed on the concatenation of: 1633 - the four octet Command Code of the AVP 1634 - the shared authentication secret 1635 - an arbitrary length random vector 1637 The value of the random vector used in this hash is passed in the 1638 Data field of a Nonce AVP. This Nonce AVP must appear in the message 1639 before any hidden AVPs. The same Nonce may be used for more than one 1640 hidden AVP in the same message. If a different Nonce is used for the 1641 hiding of subsequent AVPs then a new Nonce AVP must be placed before 1642 the first AVP to which it applies. 1644 The MD5 hash value is then XORed with the first 16 octet or less 1645 segment of the AVP Subformat and placed in the Data field of the AVP. 1646 If the AVP Subformat is less than 16 octets, the Subformat is 1647 transformed as if the Value field had been padded to 16 octets before 1648 the XOR, but only the actual octets present in the Subformat are 1649 modified, and the length of the AVP is not altered. 1651 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1652 is calculated over a stream of octets consisting of the shared secret 1653 followed by the result of the first XOR. That hash is XORed with the 1654 second 16 octet or less segment of the Subformat and placed in the 1655 corresponding octets of the Data field of the AVP. 1657 If necessary, this operation is repeated, with each XOR result being 1658 used along with the shared secret to generate the next hash to XOR 1659 the next segment of the value with. This technique results in the 1660 content of the AVP being obscured, although the length of the AVP is 1661 still known. 1663 On receipt, the Nonce is taken from the last Nonce AVP encountered in 1664 the message prior to the AVP to be decrypted. The above process is 1665 then reversed to yield the original value. For more details on this 1666 hiding method, consult RFC2138 [1]. 1668 Please note that in the case where the DIAMETER message needs to be 1669 processed by an intermediate non-trusted DIAMETER server (also known 1670 as a proxy server, depicted as DIA2 in the figure below) the AVP 1671 needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 1672 using Shared-Secret-2. 1674 (Shared-Secret-1) (Shared-Secret-2) 1675 +------+ -----> +------+ ------> +------+ 1676 | | | | | | 1677 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1678 | | | | | | 1679 +------+ +------+ +------+ 1680 Figure 1: Message Forwarding 1682 Unfortunately in this case the non-trusted server DIA2 has access to 1683 sensitive information (such as a password). It is recommended that 1684 the key size used in the encryption of AVPs be sufficiently long 1685 (e.g. 128 bits), and that different keys be used for both 1686 authentication and encryption (see section 5.5.1). 1688 5.6 DIAMETER Message Routing 1690 5.6.1 DIAMETER Proxying 1692 This section will describe how DIAMETER server implementations can 1693 proxy requests to upstream servers. Consider the following diagram, 1694 which depicts DIA1 sending a request to DIA2. Typically, the request 1695 will contain the User-Name AVP (section 4.20), which conforms to the 1696 format defined in the NAI specification [8]. Server DIA2 will extract 1697 that realm portion of the NAI to determine if the request can be 1698 locally processed, or if the request must be proxied to an upstream 1699 server (in this case DIA3). 1701 (Request) (Request) 1702 (User-Name = joe@abc.com) (Proxy-State=1) 1703 +------+ ------> +------+ ------> +------+ 1704 | | | | | | 1705 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1706 | | | | | | 1707 +------+ <------ +------+ <------ +------+ 1708 (Response) (Response) 1709 (Proxy-State=1) 1710 mno.net xyz.com abc.com 1711 Figure 2: DIAMETER Proxying 1713 Prior to forwarding the request, DIA2 must establish some state 1714 information in order to be able to forward the corresponding response 1715 from DIA3 to DIA1. There are two methods of doing so: 1717 1. DIA2 can maintain state information locally, and using the 1718 session-Id and possible the Identifier in the header, can match 1719 the request with the response. The state information would contain 1720 sufficient information for it to know where the response should be 1721 forwarded. Additionally, it may be necessary for DIA2 to attach 1722 AVPs to the response that were created when the request was 1723 received. These AVPs could be kept in the state table. 1725 2. DIA2 can attach a Proxy-State AVP (section 4.22), which may 1726 contain any information, including information regarding the 1727 source of the request, additional AVPs that must be attached to 1728 the response, etc. Upon receipt of the response, DIA2 must find 1729 the Proxy-State AVP, determine if the AVP was created locally, and 1730 if so use the information included within the AVP. If AVPs were 1731 found within the Proxy-State AVP, they could easily be attached to 1732 the response. Finally, the Proxy-State AVP is removed from the 1733 response before being forwarded to DIA1. 1735 Although both methods work, the latter is much simpler as it 1736 reduces the amount of state information each proxy must maintain 1737 on a per request basis. 1739 When DIA3 receives a request that includes the Proxy-State AVP, it 1740 MUST include the same AVP in the corresponding response. 1741 Furthermore, should DIA3 have to proxy the request to another 1742 upstream server, it would have to replace the existing Proxy-State 1743 AVP with its own. It must, however, be able to replace the Proxy- 1744 State AVP in the corresponding response back to the one it had 1745 received in the request. One suggested implementation is to 1746 include the Proxy-State AVPs in a newly created Proxy-State AVP, 1747 allowing a server to easily replace the Proxy-State AVPs in the 1748 responses. 1750 5.6.2 Message Redirection 1752 There are cases where a DIAMETER proxy, known as a broker, may wish 1753 to request that a server contact another directly instead of 1754 forwarding the message (figure 3). This is typically done when the 1755 broker provides simple NAI to Home DIAMETER Server address resolution 1756 services. 1758 In the example provided in figure 3, abc.net's DIAMETER server issues 1759 a request to its broker, which in turn returns a response that 1760 includes the Result-Code AVP set to a specific value (see section 1761 4.14). When a response is received with such a value, the message 1762 MUST also include one or more Redirect-Host AVPs. These AVPs contain 1763 address information that can be then used to directly communicate 1764 with the Home DIAMETER Server. Note that the servers COULD cache the 1765 home server information in order to reduce the latency involved in 1766 any future messages destined for that home server. 1768 +------------------+ +---------+ 1769 | DIAMETER | | CRL DB/ | 1770 | Broker | | OCSP | 1771 +------------------+ +---------+ 1772 /|\ 1773 Request | Response w+ 1774 | Result Code = 1775 | Redirect 1776 \|/ 1777 +----------+ +----------+ 1778 | abc.net |/ \| xyz.net | 1779 | DIAMETER |--------------| DIAMETER | 1780 | Server |\ /| Server | 1781 +----------+ Direct +----------+ 1782 Communication 1783 Figure 3: DIAMETER Broker Returning Redirect Indication 1785 When returning the response with the Result-Code set to indicate a 1786 redirect indication, the broker can also include the certificates of 1787 both the requesting server, and the target server. These certificates 1788 are encapsulated in the Broker-Certificate AVP, which also includes a 1789 timestamp and an expiration time. The requesting server can forward 1790 the Broker-Certificate that belongs to it in the subsequent request 1791 to the home DIAMETER server. The Broker-Certificate is intended to 1792 allow the peers to communicate without having to validate the 1793 certificate against a certificate validation infrastructure, such as 1794 Certificate Revocation Lists (CRLs) or using Online Certificate 1795 Status Protocol (OCSP) [14]. Local policy at the individual servers 1796 will dictate whether they can trust the Broker-Certificate, or 1797 whether they must validate the certificate themselves. 1799 6.0 IANA Considerations 1801 This document defines a number of assigned numbers to be maintained 1802 by the IANA. This section explains the criteria to be used by the 1803 IANA to assign additional numbers in each of these lists. The 1804 following subsections describe the assignment policy for the 1805 namespaces defined elsewhere in this document. 1807 6.1 AVP Attributes 1808 As defined in Section 4.0, AVPs contain vendor ID, Attribute and 1809 Value fields. For vendor ID value of 0, IANA will maintain a registry 1810 of assigned Attributes and in some case also values. Attribute 0-254 1811 are assigned from the RADIUS protocol [1], whose attributes are also 1812 maintained through IANA. Attributes 256-280 are assigned within this 1813 document in section 4.0. The remaining values are available for 1814 assignment through Designated Expert [12]. 1816 6.2 Command Code AVP Values 1818 As defined in Section 4.1, the Command Code AVPs (AVP Code 256) have 1819 an associated value maintained by IANA. Values 0-255 are reserved for 1820 backward RADIUS compatibility, and values 256-258 are defined in this 1821 specification. The remaining values are available for assignment via 1822 Designated Expert [12]. 1824 6.3 Extension Identifier Values 1826 as defined in Section 4.7, the Extension Identifier is used to 1827 identify a specific DIAMETER Extension. All values, other than zero 1828 (0) are available for assignment via Designated Expert [12]. 1830 6.4 Result Code AVP Values 1832 As defined in Section 4.14, the Result Code AVP (AVP Code 268) 1833 defines the values 0-8. All remaining values are available for 1834 assignment via IETF Consensus [12]. 1836 6.5 Integrity Check Value Transform Values 1838 Section 4.8 defines the Integrity-Check-Value AVP (AVP Code 259) 1839 which contains a field called the Transform. This document reserves 1840 the value 1. All remaining values are available for assignment via 1841 Designated Expert [12]. 1843 6.6 Reboot Type Values 1845 Section 4.17 defines the Reboot-Type AVP (AVP Code 271), which is 1846 used to inform the peer of the cause for the reboot. This document 1847 defines the values 1-3. All remaining values are available for 1848 assignment via Designated Expert [12]. 1850 6.7 AVP Header Bits 1852 There are six remaining reserved bits in the AVP header. Additional 1853 bits should only be assigned via a Standards Action [12]. 1855 7.0 Open Issues 1857 The following are the open issues that SHOULD be addressed in future 1858 versions of the DIAMETER protocol: 1860 - AVPs of type 'Time" are 32 bits in size and contain the a 1861 timestamp consistent with NTP [18]. This field is expected to 1862 expire sometime in 2038. Future investigation SHOULD be done to 1863 determine if a 64 bit time format could be used. 1865 - The fact that the Sender's IP Address is used in the 1866 construction of the Session-Id means that the introduction of 1867 Network Address Translation can cause two hosts to represent the 1868 same Session Identifier. This area needs to be investigated 1869 further to be able to support DIAMETER hosts on a private network. 1871 - Some crypto algorithms are known to have weaknesses if a random 1872 value is not found early within the plaintext, therefore it is 1873 recommended that the Nonce AVP be added early in a message if 1874 possible. More investigation on this subject is needed in order 1875 to determine if there exists any possibility for such attacks. 1877 - When additional hashing transforms are supporting by the 1878 DIAMETER base protocol, there SHOULD be a method to negotiate the 1879 transform to be used. This negotiation MUST NOT be prone to a 1880 bidding down attack to the lowest secure transform. 1882 8.0 DIAMETER protocol related configurable parameters 1884 This section contains the configurable parameters that can be found 1885 throughout this document: 1887 Device-Reboot-Ind Timer 1888 This timer is used to determine how long an implementation 1889 should issue another DRI message if no response is received. 1891 Device-Watchdog-Ind Timer 1892 This is the timer that determines the period of inactivity that 1893 must occur before a DWI is transmitted to the communicating 1894 peer. 1896 Receive Window 1897 The Receive window determines how many DIAMETER messages a node 1898 can handle from a communicating peer. This is normally 1899 configured to a value that allows the node to effectively 1900 manage its receive buffers. 1902 Retransmission Timer 1903 The retransmission timer is the time period that a node will 1904 retransmit a message if not transport level acknowledgement was 1905 received. 1907 Maximum Retransmissions 1908 This is the maximum number of times a DIAMETER message will be 1909 retransmitted before it is determined that the communicating 1910 peer is no longer reachable. 1912 Delayed Acknowlegement Timer 1913 This is an optional timer, described in appendix D, that 1914 specifies how long an implementation could wait before sending 1915 a ZLB. The idea is that if there is a non-ZLB message that 1916 would be sent within this window, an acknowledgement would be 1917 piggybacked onto the message. 1919 Shared Secret 1920 The shared secret is a value that is known by two communicating 1921 peers, and is used to generate the Integrity-Check-Value. 1923 9.0 Security Considerations 1925 Security issues are the primary topic of this document. 1927 10.0 References 1929 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1930 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, 1931 October 1994. 1932 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 1933 [4] Rivest, "The MD5 Message-Digest Algorithm", 1934 RFC 1321, April 1992. 1935 [5] Kaufman, Perlman, Speciner, "Network Security: Private 1936 Communications in a Public World", Prentice Hall, 1937 March 1995, ISBN 0-13-061466-1. 1938 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 1939 Authentication", RFC 2104, January 1997. 1940 [7] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 1941 draft-calhoun-diameter-authen-06.txt, Work in Progress, 1942 August 1999. 1943 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. 1944 January 1999. 1945 [9] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", 1946 draft-calhoun-diameter-framework-04.txt, Work in Progress, 1947 October 1999. 1948 [10] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for 1949 Tunnel Protocol Support", 1950 draft-ietf-radius-tunnel-auth-05.txt, Work in Progress, 1951 April 1998. 1952 [11] Calhoun, Bulley, "DIAMETER Secure Proxy Extension", 1953 draft-calhoun-diameter-proxy-03.txt, Work in Progress, 1954 October 1999. 1955 [12] Narten, Alvestrand,"Guidelines for Writing an IANA 1956 Considerations Section in RFCs", BCP 26, RFC 2434, 1957 October 1998 1958 [13] S. Bradner, "Key words for use in RFCs to Indicate 1959 Requirement Levels", BCP 14, RFC 2119, March 1997. 1960 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet 1961 Public Key Infrastructure Online Certificate Status 1962 Protocol (OCSP)", RFC 2560, June 1999. 1963 [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting 1964 Extension", draft-calhoun-diameter-accounting-00.txt, 1965 IETF Work in Progress, September 1999. 1966 [16] Hinden, Deering, "IP Version 6 Addressing Architecture", 1967 RFC 2373, July 1998. 1968 [17] ISI, "Internet Protocol", RFC 791, September 1981. 1969 [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 1970 for IPv4, IPv6 and OSI, RFC 2030, October 1996. 1971 [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key 1972 Infrastructure Certificate and CRL Profile", RFC 2459, 1973 January 1999. 1975 11.0 Acknowledgements 1977 The authors would like to thank Nenad Trifunovic, Tony Johansson and 1978 Pankaj Patel for their participation in the Document Reading Party. 1979 Erik Guttman provided alot of good suggestions that were instrumental 1980 in reducing the size of the document, while making the text generally 1981 clearer. 1983 The authors would also like to acknowledge the following people for 1984 their contribution in the development of the DIAMETER protocol: 1986 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1987 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 1988 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 1989 R. Vollbrecht, Jeff Weisberg and Glen Zorn 1991 12.0 Author's Address 1993 Questions about this memo can be directed to: 1995 Pat R. Calhoun 1996 Network and Security Research Center, Sun Labs 1997 Sun Microsystems, Inc. 1998 15 Network Circle 1999 Menlo Park, California, 94025 2000 USA 2002 Phone: 1-650-786-7733 2003 Fax: 1-650-786-6445 2004 E-mail: pcalhoun@eng.sun.com 2006 Allan C. Rubens 2007 Tut Systems, Inc. 2008 220 E. Huron, Suite 260 2009 Ann Arbor, MI 48104 2010 USA 2012 Phone: 1-734-995-1697 2013 E-Mail: arubens@tutsys.com 2015 Haseeb Akhtar 2016 Wireless Technology Labs 2017 Nortel Networks 2018 2221 Lakeside Blvd. 2019 Richardson, TX 75082-4399 2020 USA 2022 Phone: 1-972-684-8850 2023 E-Mail: haseeb@nortelnetworks.com 2025 13.0 Full Copyright Statement 2027 Copyright (C) The Internet Society (1999). All Rights Reserved. 2029 This document and translations of it may be copied and furnished 2030 to others, and derivative works that comment on or otherwise 2031 explain it or assist in its implementation may be prepared, copied, 2032 published and distributed, in whole or in part, without 2033 restriction of any kind, provided that the above copyright notice 2034 and this paragraph are included on all such copies and derivative 2035 works. However, this docu- ment itself may not be modified in any 2036 way, such as by removing the copyright notice or references to the 2037 Internet Society or other Inter- net organizations, except as needed 2038 for the purpose of developing Internet standards in which case 2039 the procedures for copyrights defined in the Internet Standards 2040 process must be followed, or as required to translate it into 2041 languages other than English. The limited permis- sions granted 2042 above are perpetual and will not be revoked by the Internet 2043 Society or its successors or assigns. This document and the 2044 information contained herein is provided on an "AS IS" basis and 2045 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 2046 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2047 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 2048 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2049 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2051 Appendix A: Acknowledgment Timeouts 2053 DIAMETER uses sliding windows and timeouts to provide flow-control 2054 across the underlying medium and to perform efficient data buffering 2055 to keep two DIAMETER peers' receive window full without causing 2056 receive buffer overflow. DIAMETER requires that a timeout be used to 2057 recover from dropped messages. 2059 When the timeout for a peer expires, the previously transmitted 2060 message with Ns value equal to the highest in-sequence value of Nr 2061 received from the peer is retransmitted. The receiving peer does not 2062 advance its value for the receive sequence number state, Sr, until it 2063 receives a message with Ns equal to its current value of Sr. 2065 This rule assures that all subsequent acknowledgements to this peer 2066 will contain an Nr value equal to the Ns value of the first missing 2067 message until a message with the missing Ns value is received. 2069 The exact implementation of the acknowledgment timeout is vendor- 2070 specific. It is suggested that an adaptive timeout be implemented 2071 with back-off for flow control. The timeout mechanism proposed here 2072 has the following properties: 2074 Independent timeouts for each peer. A device will have to 2075 maintain and calculate timeouts for every active peer. 2077 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 2078 each device. 2080 An adaptive timeout mechanism that compensates for changing 2081 throughput. To reduce message processing overhead, vendors may 2082 choose not to recompute the adaptive timeout for every received 2083 acknowledgment. The result of this overhead reduction is that the 2084 timeout will not respond as quickly to rapid network changes. 2086 Timer back-off on timeout to reduce congestion. The backed-off 2087 timer value is limited by the configurable maximum timeout value. 2088 Timer back-off is done every time an acknowledgment timeout 2089 occurs. 2091 In general, this mechanism has the desirable behavior of quickly 2092 backing off upon a timeout and of slowly decreasing the timeout value 2093 as messages are delivered without errors. 2095 A.1 Calculating Adaptive Acknowledgment Timeout 2097 We must decide how much time to allow for acknowledgments to return. 2099 If the timeout is set too high, we may wait an unnecessarily long 2100 time for dropped messages. If the timeout is too short, we may time 2101 out just before the acknowledgment arrives. The acknowledgment 2102 timeout should also be reasonable and responsive to changing network 2103 conditions. 2105 The suggested adaptive algorithm detailed below is based on the TCP 2106 1989 implementation and is explained in Richard Steven's book TCP/IP 2107 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 2108 calculation, and 'n-1' refers to values from the last calculation. 2110 DIFF[n] = SAMPLE[n] - RTT[n-1] 2111 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 2112 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 2113 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2115 DIFF represents the error between the last estimated round-trip time 2116 and the measured time. DIFF is calculated on each iteration. 2118 DEV is the estimated mean deviation. This approximates the standard 2119 deviation. DEV is calculated on each iteration and stored for use in 2120 the next iteration. Initially, it is set to 0. 2122 RTT is the estimated round-trip time of an average message. RTT is 2123 calculated on each iteration and stored for use in the next 2124 iteration. Initially, it is set to PPD. 2126 ATO is the adaptive timeout for the next transmitted message. ATO is 2127 calculated on each iteration. Its value is limited, by the MIN 2128 function, to be a maximum of the configure MaxTimeOut value. 2130 Alpha is the gain for the round trip estimate error and is typically 2131 1/8 (0.125). 2133 Beta is the gain for the deviation and is typically 1/4 (0.250). 2135 Chi is the gain for the timeout and is typically set to 4. 2137 To eliminate division operations for fractional gain elements, the 2138 entire set of equations can be scaled. With the suggested gain 2139 constants, they should be scaled by 8 to eliminate all division. To 2140 simplify calculations, all gain values are kept to powers of two so 2141 that shift operations can be used in place of multiplication or 2142 division. The above calculations are carried out each time an 2143 acknowledgment is received for a message that was not retransmitted 2144 (no timeout occurred). 2146 A.2 Flow Control: Adjusting for Timeout 2148 This section describes how the calculation of ATO is modified in the 2149 case where a timeout does occur. When a timeout occurs, the timeout 2150 value should be adjusted rapidly upward. To compensate for shifting 2151 internetwork time delays, a strategy must be employed to increase the 2152 timeout when it expires. A simple formula called Karn's Algorithm is 2153 used in TCP implementations and may be used in implementing the 2154 back-off timers for the DIAMETER peers. Notice that in addition to 2155 increasing the timeout, we also shrink the size of the window as 2156 described in the next section. 2158 Karn's timer back-off algorithm, as used in TCP, is: 2160 NewTIMEOUT = delta * TIMEOUT 2162 Adapted to our timeout calculations, for an interval in which a 2163 timeout occurs, the new timeout interval ATO is calculated as: 2165 RTT[n] = delta * RTT[n-1] 2166 DEV[n] = DEV[n-1] 2167 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2169 In this modified calculation of ATO, only the two values that 2170 contribute to ATO and that are stored for the next iteration are 2171 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 2172 not carried forward and is not used in this scenario. A value of 2 2173 for Delta, the timeout gain factor for RTT, is suggested. 2175 Appendix B: Examples of sequence numbering 2177 This appendix uses several common scenarios to illustrate how 2178 sequence number state progresses and is interpreted. 2180 B.1 Lock-step session establishment 2182 In this example, a DIAMETER host establishes communication with a 2183 peer, with the exchange involving each side alternating in the 2184 sending of messages. This example is contrived, in that the final 2185 acknowledgement typically would be included in the Device-Watchdog- 2186 Ind message. 2188 DIAMETER Host A DIAMETER Host B 2189 -> Device-Reboot-Ind 2190 Nr: 0, Ns: 0 2192 (ZLB) <- 2193 Nr: 1, Ns: 0 2195 -> Device-Watchdog-Ind 2196 Nr: 0, Ns: 1 2198 (delay) 2200 (ZLB) <- 2201 Nr: 2, Ns: 0 2203 B.2 Multiple messages acknowledged 2205 This example shows a flow of messages from DIAMETER Host B to Host A, 2206 with Host A having no traffic of its own. Host A is waiting 1/4 of 2207 its timeout interval, and then acknowledging all messages seen since 2208 the last interval. 2210 DIAMETER Host A DIAMETER Host B 2211 (previous message flow precedes this) 2213 -> (ZLB) 2214 Nr: 7000, Ns: 1000 2215 (non-ZLB) <- 2216 Nr: 1000, Ns: 7000 2217 (non-ZLB) <- 2218 Nr: 1000, Ns: 7001 2219 (non-ZLB) <- 2220 Nr: 1000, Ns: 7002 2222 (Host A's timer indicates it should acknowledge pending 2223 traffic) 2225 -> (ZLB) 2226 Nr: 7003, Ns: 1000 2228 B.3 Lost message with retransmission 2230 Host A attempts to communicate with Host B. The Device-Reboot-Ind 2231 sent from B to A is lost and must be retransmitted by Host B. 2233 DIAMETER Host A DIAMETER Host B 2234 -> Device-Reboot-Ind 2235 Nr: 0, Ns: 0 2237 (message lost) Device-Reboot-Ind <- 2238 Nr: 1, Ns: 0 2240 (pause; Host A's timer started first, so fires first) 2242 -> Device-Reboot-Ind 2243 Nr: 0, Ns: 0 2245 (Host B realizes it has already seen this message) 2246 (Host B might use this as a cue to retransmit, as in this 2247 example) 2249 Device-Reboot-Ind <- 2250 Nr: 1, Ns: 0 2251 -> Device-Watchdog-Ind 2252 Nr: 1, Ns: 1 2254 (delay) 2256 (ZLB) <- 2257 Nr: 2, Ns: 1 2259 Appendix C Backward Compatibility with RADIUS 2261 The DIAMETER protocol was designed with RADIUS [1] compatibility in 2262 mind. A DIAMETER node MAY listen for incoming RADIUS and DIAMETER 2263 packets on the same UDP port. The first octet in the message would 2264 indicate whether the message is of type RADIUS or DIAMETER. 2266 The RADIUS protocol defines a one octet attribute space, and the 2267 DIAMETER protocol reserves the first 255 attribute identifiers to be 2268 the same as those defined in RADIUS. This allows DIAMETER servers to 2269 easily perform protocol conversion, since a dictionary lookup would 2270 not be necessary in order to map a RADIUS attribute to a DIAMETER 2271 AVP. 2273 By re-using the RADIUS attribute space, a DIAMETER server could 2274 easily read a typical RADIUS user profile without any additional 2275 conversions. This reduces the need to create duplicate user profiles 2276 for both protocols, and also does not require any database conversion 2277 while reading the profiles. 2279 Appendix D Delayed Acknowledgement Optimization 2281 This optimization will potentially reduce the amount of traffic sent 2282 between DIAMETER peers. This optimization affects when 2283 acknowledgments are sent, as presented in Section 3.1. 2285 If a peer does not have a message queued to transmit at the time a 2286 non-ZLB message is received then it should delay a short time before 2287 sending a ZLB message containing the latest values of Sr and Ss, as 2288 described above. This short delay is to allow for the possible 2289 arrival of a message to be transmitted back to its peer, thus 2290 avoiding the need to issue a ZLB. The suggested value for this time 2291 delay is 1/4 the receiving peer's value of Round-Trip-Time (RTT - see 2292 Appendix A), if it computes RTT, or a maximum of 1/2 of its fixed 2293 acknowledgment timeout interval otherwise. This timeout should 2294 provide a reasonable opportunity for the receiving peer to obtain a 2295 payload message destined for its peer, upon which the ACK of the 2296 received message can be piggybacked. Note that if a peer's window is 2297 full, it MAY advertise an older Nr value if it is not ready to accept 2298 new messages. 2300 This delay value should be treated as a suggested maximum; an 2301 implementation could make this delay quite small without adversely 2302 affecting the protocol. The default time delay is 2 seconds. To 2303 provide for better throughput, the receiving peer should skip this 2304 delay entirely and send a ZLB message immediately in the case where 2305 its receive window is filled and it has no queued data to send for 2306 this connection or it can't send queued data because the transmit 2307 window is closed. 2309 Appendix E Device-Reboot-Ind Message Flow 2311 The following figure depicts a sample flow of Device-Reboot-Ind 2312 between three DIAMETER peers, one being a proxy or broker server. In 2313 this example DIA1 initiates the bootstrap sequence with DIA2, and 2314 later DIA3 initiates the bootstrap sequence with DIA2. After some 2315 time DIA1 needs to reboot and informs DIA2. The details of each 2316 message is provided below. 2318 +-------+ +-------+ +-------+ 2319 | DIA1 | | PROXY | | DIA3 | 2320 | | | DIA2 | | | 2321 +-------+ +-------+ +-------+ 2322 | | | 2323 |DRI (ns=0, nr=0) | | 2324 | Rebooted | | 2325 | version 1, | | 2326 | extensions 1, 4 | | 2327 (a) |------------------->| | 2328 |DRI (ns=0, nr=1) | | 2329 | Rebooted | | 2330 | version 1, | | 2331 | extension 1 | | 2332 (b) |<-------------------| | 2333 |ZLB (ns=0, nr=1) | | 2334 (c) |------------------->| | 2335 | . |DRI (ns=0, nr=0) | 2336 | . | Rebooted | 2337 | | version 1, | 2338 | | extensions 1, 2 | 2339 (d) | |<------------------| 2340 | |DRI (ns=0, nr=1) | 2341 | | Rebooted | 2342 | | version 1, | 2343 | | extension 1 | 2344 (e) | |------------------>| 2345 | |ZLB (ns=0, nr=1) | 2346 (f) | |<------------------| 2347 |DRI (ns=x, nr=y) | . | 2348 | Upcoming Reboot | . | 2349 (g) |------------------->| | 2350 | . | | 2351 | . | | 2352 |DRI (ns=0, nr=0) | | 2353 | Rebooted | | 2354 | version 1, | | 2355 | extensions 1, 4 | | 2356 (h) |------------------->| | 2357 | | | 2358 Figure 4: Sample DRI Message Flow in a Proxy Environment 2360 (a) DIA1 sends a DRI message to DIA2 indicating that its version 2361 is one (1) and that its supported extensions are 1 (Roamops) and 4 2362 (Mobile-IP). 2364 (b) DIA2 sends a DRI message to DIA1 indicating that its version 2365 is one (1) and that its supported extension is 1 (Roamops). This 2366 message also includes a piggy-backed acknowledgement of (a). 2368 (c) DIA1 sends an acknowledgement of (b) 2370 (d) DIA3 sends a DRI message to DIA2 indicating that its version 2371 is one (1) and that its supported extensions are 1 (Roamops) and 2 2372 (Secure Proxy). 2374 (e) DIA2 sends a DRI message to DIA3 indicating that its version 2375 is one (1) and that its supported extension is 1 (Roamops). This 2376 message also includes a piggy-backed acknowledgement of (d). 2378 (f) DIA3 sends an acknowledgement of (e) 2380 (g) after some time DIA1 sends an indication to DIA2 that it is 2381 about to reboot. All messages destined to the domain for which 2382 DIA1 is responsible for should be redirected to an alternate 2383 DIAMETER Server. 2385 (h) Once the reboot is complete, DIA sends the DRI, which causes 2386 steps (a) through (c) to be repeated. 2388 Appendix F Device-Watchdog-Ind Message Flow 2390 The following figure provides an example of how the Device-Watchdog- 2391 Ind message is used in a proxy environment. The details of each 2392 message is provided below. 2394 +-------+ +-------+ +-------+ 2395 | DIA1 | | PROXY | | DIA3 | 2396 | | | DIA2 | | | 2397 +-------+ +-------+ +-------+ 2398 | | | 2399 |CMD-X (ns=23, nr=40)| | 2400 (a) |------------------->| | 2401 |ZLB (ns=40, nr=24) | | 2402 (b) |<-------------------| | 2403 | . | | 2404 | . | | 2405 | |CMD-Y (ns=12, nr=20)| 2406 (c) | |------------------->| 2407 | |ZLB (ns=20, nr=13) | 2408 (d) | |<-------------------| 2409 |WDI (ns=24, nr=40) | . | 2410 (e) |------------------->| . | 2411 |ZLB (ns=40, nr=25) | | 2412 (f) |<-------------------| | 2413 | |WDI (ns=21, nr=13) | 2414 (g) | |<-------------------| 2415 | |ZLB (ns=13, nr=22) | 2416 (h) | |------------------->| 2417 | | | 2418 Figure 5: Sample WDI Message in a Proxy Environment 2420 (a) DIA1 issues a message to DIA2 2422 (b) DIA2 acknowledges the receipt of (a) 2424 (c) DIA2 issues a message to DIA3 2426 (d) DIA3 acknowleges the receipt of (c) 2428 (e) After some time of inactivity, DIA1 issues a WDI to DIA2 2430 (f) DIA2 acknowledges the receipt of (e) 2432 (g) After some period of inactivity, DIA3 issues a WDI to DIA2 2434 (h) DIA2 acknowledges the receipt of (g) 2436 Appendix G Message-Reject-Ind Message Flow 2438 The following figure show sample flows of MRI command between two 2439 DIAMETER peers.In this example DIA1 and DIA2 servers generates error 2440 messages. The details of the messages are provided below. 2442 +-------+ +-------+ 2443 | DIA1 | | DIA2 | 2444 +-------+ +-------+ 2445 | | 2446 |Unknown command | 2447 (a) |------------------------------------>| 2448 |MRI(Unrecognized Command Code) | 2449 (b) |<------------------------------------| 2450 | . | 2451 | . | 2452 |Unknown AVP | 2453 (c) |<------------------------------------| 2454 |MRI(Failed AVP Code) | 2455 (d) |------------------------------------>| 2456 | . | 2457 | . | 2458 |Bad value in a valid AVP | 2459 (e) |------------------------------------>| 2460 |MRI (Error Code | Failed AVP Code) | 2461 (f) |<------------------------------------| 2462 Figure 6: Sample MRI Message Flow 2464 (a) DIA2 receives an unknown command from DIA1. 2466 (b) DIA2 recognizes that it received an unknown command and 2467 hence sends an MRI with Unrecognized Command Code AVP. 2469 (c) DIA1 receives an unknown AVP in a message sent by DIA2. 2471 (d) DIA1 recognizes that it received an unknown AVP and 2472 returns an MRI with Failed AVP Code to DIA2. 2474 (e) DIA2 receives a bad parameter within a otherwise 2475 valid AVP from DIA1. 2477 (f) As soon as it discovers that it has received a bad 2478 parameter, it returns an MRI message to DIA1 with 2479 Error Code AVP and Failed AVP Code.