idnits 2.17.1 draft-calhoun-diameter-09.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 71 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 72 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 2409 has weird spacing: '...invalid clea...' == Line 2974 has weird spacing: '... copied and ...' == Line 2975 has weird spacing: '...s, and deriv...' == Line 2977 has weird spacing: '...blished and d...' == Line 2978 has weird spacing: '...hat the above...' == (8 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: - Removed some text in section 4.1.2 that pertained to proxies. The DRI message SHOULD not be proxied. This section also has some small change in the text to state that only packets of extensions supported by the peer should be sent to it. A new sentence stating that the DRI should be periodically transmitted to a peer until an acknowlegement has been received. -- 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 2888, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2889, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2891, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2901, 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-02 -- 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-02 -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2434 (ref. '12') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2560 (ref. '14') (Obsoleted by RFC 6960) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-00 -- Possible downref: Normative reference to a draft: ref. '15' Summary: 15 errors (**), 0 flaws (~~), 19 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-09.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 any 40 services which require AAA/Policy support. The protocol is intended 41 to be flexible enough to allow services to add building blocks (or 42 extensions) to DIAMETER in order to meet their requirements. 44 This draft specifies the message format and transport to be used by 45 all DIAMETER extensions and MUST be supported by all DIAMETER 46 implementations, regardless of the specific underlying service. 48 Table of Contents 50 1.0 Introduction 51 1.1 Copyright Statement 52 1.2 Requirements language 53 1.3 Terminology 54 1.4 Changes in Revision 8 55 1.5 Changes in Revision 9 56 2.0 Protocol Overview 57 2.1 Header Format 58 2.1.1 ZLB Message Format 59 2.2 AVP Format 60 2.3 Error Reporting 61 3.0 Reliable Transport 62 3.1 Flow Control 63 3.2 Suggested implementation 64 3.3 Peer failure recovery 65 4.0 DIAMETER AVPs 66 4.1 DIAMETER-Command AVP 67 4.1.1 Message-Reject-Ind 68 4.1.2 Device-Reboot-Ind 69 4.1.3 Device-Watchdog-Ind 70 4.2 Host-IP-Address 71 4.3 Host-Name 72 4.4 State 73 4.5 Class 74 4.6 Session-Timeout 75 4.7 Extension-Id 76 4.8 Integrity-Check-Vector 77 4.9 Nonce 78 4.10 Timestamp 79 4.11 Session-Id 80 4.12 Vendor-Name 81 4.13 Firmware-Revision 82 4.14 Result-Code 83 4.15 Error-Code 84 4.16 Unrecognized-Command-Code 85 4.17 Reboot-Type 86 4.18 Reboot-Time 87 4.19 Failed-AVP-Code 88 4.20 User-Name 89 4.21 Receive-Window 90 4.22 Proxy-State 91 4.23 Redirected-Host 92 4.24 Broker-Certificate 93 5.0 Protocol Definition 94 5.1 DIAMETER Bootstrap Message 95 5.1.1 State Machine 97 5.2 Keepalive Exchange 98 5.3 Unrecognized Command Support 99 5.4 The art of AVP Tagging 100 5.5 Using the Integrity-Check-Vector 101 5.6 DIAMETER Proxying 102 5.7 Message Redirection 103 5.8 AVP Encryption with Shared Secrets 104 6.0 IANA Considerations 105 6.1 AVP Attributes 106 6.2 Command Code AVP Values 107 6.3 Extension Identifier Values 108 6.4 Result Code AVP Values 109 6.5 Integrity Check Vector Transform Values 110 6.7 AVP Header Bits 111 6.6 Reboot Type Values 112 7.0 References 113 8.0 Acknowledgements 114 9.0 Author's Address 115 10.0 Full Copyright Statement 116 Appendix A: Acknowledgment Timeouts 117 A.1 Calculating Adaptive Acknowledgment Timeout 118 A.2 Flow Control: Adjusting for Timeout 119 Appendix B: Examples of sequence numbering 120 B.1 Lock-step tunnel establishment 121 B.2 Multiple packets acknowledged 122 B.3 Lost packet with retransmission 124 1.0 Introduction 126 Since the RADIUS protocol is being used today for much more than 127 simple authentication and accounting of dial-up users (i.e. 128 authentication of WWW clients, etc), a more extensible protocol was 129 necessary which could support new services being deployed in the 130 internet and corporate networks. 132 RADIUS in itself is not an extensible protocol largely due to its 133 very limited command and attribute address space. In addition, the 134 RADIUS protocol assumes that there cannot be any unsolicited messages 135 from a server to a client. In order to support new services it is 136 imperative that a server be able to send unsolicited messages to 137 clients on a network, and this is a requirement for any DIAMETER 138 implementation. 140 This document describes the base DIAMETER protocol, which is used as 141 the transport for all DIAMETER extensions. This document in itself is 142 not complete and MUST be used with an accompanying applicability 143 extension document. 145 An example of such a document would be [7] that defines extensions to 146 the base protocol to support user authentication and [15] which 147 defines extensions to support accounting. 149 1.1 Copyright Statement 151 Copyright (C) The Internet Society 1999. All Rights Reserved. 153 1.2 Requirements language 155 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 156 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 157 described in [13]. 159 1.3 Terminology 161 AVP 163 The DIAMETER protocol consists of a header followed by objects. 164 Each object is encapsulated in a header known as an Attribute- 165 Value-Pair (AVP). 167 DIAMETER Device 168 A Diameter device is a client or server system that supports the 169 Diameter Base protocol and 0 or more extensions. 171 ICV 173 An Integrity Check Vector (ICV) is a hash of the packet with a 174 shared secret. 176 Session 178 The DIAMETER protocol is session based. When an authentication 179 request is initially transmitted, it includes a session identifier 180 that is used for the duration of the session. The Session- 181 Identifier AVP contains the identifier and must be globally 182 unique. Section 4.11 describes the semantics of a session 183 identifier. 185 1.4 Changes in Revision 8 187 The following changes were made to version 8 of this specification: 189 - Added text to clear up the Identifier field description. 191 - Clarified the text for all AVPs of type "time". 193 - Added a warning about all "time" AVPs in regards to the end of 194 life of a 32 bit time value. 196 - Added a placeholder in the Session-Id AVP description about the 197 protocol's interactions with NAT. 199 - Renamed the Initialization-Vector AVP to the Nonce AVP. This 200 makes sense since the IV was also used for authentication 201 purposes, and an IV is normally used for encryption purposes. 203 - Added a placeholder to the Nonce AVP section regarding the fact 204 that some crypto transforms have known attacks if there is no 205 random value in the plaintext early within a message. 207 - Clarification of the "Tag" and the "Mandatory" bits in the AVP 208 header. 210 - Added text specifying that the Session-Id AVP can only appear 211 once in a message. 213 - Clarified the conditions that cause a "Bad Packet" situation. 215 - Removed all support for TCP. 217 - Removed all references to the 'P' and 'E' bits, given that these 218 bit are defined in the proxy draft, and should not be specified in 219 the base protocol. 221 - The removal of the 'E' bit caused a shift in the bits, changing 222 the AVP header. 224 - A statement was added in the AVP Header definition that new AVP 225 flags may be added in the future and that an unrecognized flag 226 SHOULD be considered an error. 228 - Most AVPs flag field requirements have changed. 230 - Added descriptions for the 'A' bit, the Ns and Nr in the 231 DIAMETER header in section 2.1. 233 - Added section 2.1.1, which describes DIAMETER Acknowledgements. 235 - Added Command-Specific bits in the AVP Header in section 2.2. 236 This will eliminate the overlap problem found between the proxy 237 draft and the authent draft. 239 - Added section 3.0 (Reliable Transport) (from the Reliable 240 Transport document). 242 - Fixed up text in section 3.1 about updating the time in the 243 Timestamp AVP in retransmissions. 245 - Section 4.1 does not allow the Command Code AVP to be encrypted. 247 - Cleaned up some language in section 4.2, describing when a 248 Device-Reboot-Ind should be used. 250 - The Integrity-Check-Vector description now clearly states that 251 any AVPs found after it must be ignored. 253 - Added section 4.21, which is the Receive-Window AVP (from the 254 Reliable Transport document). 256 - Added section 4.22, which is the Proxy-State AVP. This AVP used 257 to be defined in the proxy extension, but has been deemed more 258 appropriate in the base protocol. 260 - The Timestamp AVP (section 4.10) was incorrect since it stated 261 that NTP time started on January 1st, 1970 instead of 1900. 263 - Added section 5.1.1 that describes the DIAMETER state machine. 265 - Fixed up a problem in the definition of Hop-by-Hop encryption 266 (section 4.6) since the original text defined using the two octet 267 Command Code instead of four octets. 269 - Added section 5.6, which provides a detailed description of how 270 DIAMETER server should proxy messages. 272 - Added IANA Considerations 274 - Removed all references to the DIAMETER Reliable Transport 275 document. 277 - Added appendix A and B (from the Reliable Transport document). 279 1.5 Changes in Revision 9 281 The following changes were made to version 9 of this specification: 283 - Added the missing reference to the Accounting Extension. 285 - Added the DIAMETER_REDIRECT_REQUEST and 286 DIAMETER_PEER_NOT_IN_GOOD_STANDING Result-Code in Section 4.14., 288 - Removed some text in section 4.1.2 that pertained to proxies. The 289 DRI message SHOULD not be proxied. This section also has some small 290 change in the text to state that only packets of extensions supported 291 by the peer should be sent to it. A new sentence stating that the DRI 292 should be periodically transmitted to a peer until an acknowlegement 293 has been received. 295 - Added the Redirect-Host AVP in Section 4.23. 297 - Added the Broker-Certificate AVP in Section 4.24. 299 - Added section 5.7, which describes how the Redirect-Host AVP and 300 the new Result-Code are used. 302 - Added a Device-Reboot-Ind message flow figure and explanation to 303 section 5.1 305 - Added a Device-Watchdog-Ind message flow figure and explanation to 306 section 5.2 308 - Added a Message-Reject-Ind message flow figure and explanation to 309 section 5.3 311 2.0 Protocol Overview 313 2.1 Header Format 315 The base DIAMETER protocol is run over UDP port 1812. Due to the fact 316 that both the client and server can receive unsolicited messages, it 317 is highly recommended that the source and destination field for all 318 DIAMETER messages be 1812. 320 When a request is received, the source and destination ports in the 321 reply are reversed. 323 A summary of the DIAMETER data format is shown below. The fields are 324 transmitted from left to right. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | RADIUS PCC |Flags|A|W| Ver | Packet Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Identifier | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Next Send (Ns) | Next Received (Nr) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | AVPs ... 336 +-+-+-+-+-+-+-+-+-+-+-+-+- 338 RADIUS PCC (Packet Compatibility Code) 340 The RADIUS PCC field is a one octet field which is used for 341 backward compatibility with RADIUS. In order to easily distinguish 342 DIAMETER packets from RADIUS a special value has been reserved and 343 allows an implementation to support both protocols concurrently 344 using the first octet in the header. The RADIUS PCC field MUST be 345 set as follows: 347 254 DIAMETER packet 349 PKT Flags 351 The Packet Flags field is five bits, and is used in order to 352 identify any options. This field MUST be initialized to zero. The 353 following flag may be set: 355 The 'W' bit (Window-Present) is set when the Next Send (Ns) and 356 Next Received (Nr) fields are present in the header. Should 357 DIAMETER be implemented over a reliable transport, the 'W' 358 should not be set. 360 The 'A' bit is set to indicate that the packet is an 361 acknowledgement only and does not contain a Command-Code AVP 362 following the header. Note that the Security AVPs MUST still be 363 present within an acknowledgment message. 365 Version 367 The Version field is three bits, and indicates the version number 368 which is associated with the packet received. This field MUST be 369 set to 1 to indicate DIAMETER Version 1. 371 Packet Length 373 The Packet Length field is two octets. It indicates the length of 374 the packet including the header fields. For messages received via 375 UDP, octets outside the range of the Length field should be 376 treated as padding and should be ignored upon receipt. 378 Identifier 380 The Identifier field is four octets, and aids in matching requests 381 and replies. The sender MUST ensure that the identifier in a 382 message is locally unique (to the sender) at any given time, and 383 MAY attempt to ensure that the number is unique across reboots. 384 The identifier is normally a monotonically increasing number, 385 whose start value was randomly generated. The random algorithm 386 used should ensure low probability of duplication. Given the size 387 of the Identifier field it is unlikely that 2^32 requests could be 388 outstanding at any given time. 390 Next Send 392 This field is present when the Window-Present bit is set in the 393 header flags. The Next Send (Ns) is copied from the send sequence 394 number state variable, Ss, at the time the message is transmitted. 395 Ss is incremented after copying if the message is not a ZLB ACK. 397 Next Received 399 This field is present when the Window-Present bit is set in the 400 header flags. Nr is copied from the receive sequence number state 401 variable, Sr, and indicates the sequence number, Ns, +1 of the 402 highest (modulo 2^16) in-sequence message received. See section 403 3.0 for more information. 405 AVPs 407 AVPs is a method of encapsulating information relevant to the 408 DIAMETER message. See section 2.2 for more information on AVPs. 410 2.1.1 ZLB Message Format 412 Zero Length Body messages are used to explicitly acknowledge one or 413 more DIAMETER message, and contain no additional Authentication, 414 Authorization or Accounting related AVPs. ZLB messages must contain 415 authentication AVPs, otherwise attacks could be mounted against 416 DIAMETER nodes. Consider the following example. 418 +------+ -----> +------+ 419 | | Ns=10 | | 420 | DIA1 +--------------------+ DIA3 | 421 | | Ns=40 | | 422 +------+ <----- +-+----+ 423 / 424 / 425 +------+ / Nr = 41 426 |Malici| / 427 | ous +-/ 428 | Node | 429 +------+ 430 Figure 1: DIAMETER Message Sequencing 432 In the above figure, DIA3 sends a stream of messages to DIA1, with 433 sequence number 40 being the last message sent. A malicious user 434 could send an acknowledgement for Ns 40 to DIA3, effectively opening 435 up the window. Furthermore, if any of the messages from DIA3 were 436 lost in transit to DIA1, DIA3 would not attempt to retransmit them 437 since it received an acknowledgement. Therefore, it is necessary that 438 all acknowledgement messages also include the same authentication 439 related AVPs are normal DIAMETER messages. 441 The format of a ZLB message will be as follows: 443 ::= 444 445 446 { || 447 ::= 949 950 951 [] 952 [] 953 954 [ ] 955 { || 956 } 957 958 959 { || 960 ::= 1045 1046 1047 [] 1048 1049 [] 1050 1051 1052 1053 [] 1054 [] 1055 1056 1057 { || 1058 ::= 1098 1099 1100 [] 1101 1102 1103 { || 1104 1557 It is suggested that the monotonically increasing 32 bit value NOT 1558 start at zero upon reboot, but rather start at a random value. 1559 This will minimize the possibility of overlapping Session-Ids 1560 after a reboot. The optional value is implementation specific but 1561 may include a modem's device Id, a random value, etc. 1563 The session Id is created by the DIAMETER device initiating the 1564 session, which in most cases is done by the client. Note that a 1565 Session-Id can be used by more than one extension. 1567 NOTE: The fact that the Sender's IP Address is used in the 1568 construction of the Session-Id means that the introduction of 1569 Network Address Translation can cause two hosts to represent the 1570 same Session Identifier. This area needs to be investigated 1571 further to be able to support DIAMETER hosts on a private network. 1573 AVP Format 1574 0 1 2 3 1575 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 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | AVP Code | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | AVP Length | Reserved |T|V|H|M| 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | Data ... 1582 +-+-+-+-+-+-+-+-+ 1584 AVP Code 1586 263 Session-Id 1588 AVP Length 1590 The length of this attribute MUST be at least 9. 1592 AVP Flags 1594 The 'M' bit MUST be set. The 'T' and 'H' bits MAY be set. The 1595 'V' bit MUST NOT be set. 1597 Data 1599 The Data field contains the session identifier assigned to the 1600 session. 1602 4.12 Vendor-Name 1604 Description 1606 The Vendor-Name attribute is used in order to inform a DIAMETER 1607 peer of the Vendor Name of the DIAMETER device. This MAY be used 1608 in order to know which vendor specific attributes may be sent to 1609 the peer. 1611 It is also envisioned that the combination of the Vendor-Name and 1612 the Firmware-Revision AVPs can provide very useful debugging 1613 information. 1615 AVP Format 1616 0 1 2 3 1617 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 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | AVP Code | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | AVP Length | Reserved |T|V|H|M| 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | String ... 1624 +-+-+-+-+-+-+-+-+ 1626 AVP Code 1628 266 Vendor-Name 1630 AVP Length 1632 The length of this attribute MUST be at least 9. 1634 AVP Flags 1636 The 'H' bits MAY be set. The 'T', 'V' and 'M' bits MUST NOT be 1637 set. 1639 String 1641 The String field contains the vendor name. 1643 4.13 Firmware-Revision 1645 Description 1647 The Firmware-Revision AVP is used to inform a DIAMETER peer of the 1648 firmware revision of the issuing device. 1650 For devices which do not have a firmware revision (general purpose 1651 computers running DIAMETER software modules, for instance), the 1652 revision of the DIAMETER software module may be reported instead. 1654 AVP Format 1655 0 1 2 3 1656 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 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | AVP Code | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | AVP Length | Reserved |T|V|H|M| 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Integer32 | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 AVP Code 1667 267 Firmware-Revision 1669 AVP Length 1671 The length of this attribute MUST be at least 12. 1673 AVP Flags 1675 The 'H' bits MAY be set. The 'T', 'V' and 'M' bits MUST NOT be 1676 set. 1678 Integer32 1680 The Integer32 field contains the firmware revision number of 1681 the issuing device. 1683 4.14 Result-Code 1685 Description 1687 The Result-Code AVP is used in order to indicate whether a 1688 particular command was completed successfully or whether an error 1689 occurred. The Result-Code AVP MUST be present in all DIAMETER 1690 messages of type -Request or -Answer. 1692 AVP Format 1693 0 1 2 3 1694 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 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | AVP Code | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | AVP Length | Reserved |T|V|H|M| 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Integer32 | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 AVP Code 1705 268 Result-Code 1707 AVP Length 1709 The length of this attribute MUST be 12. 1711 AVP Flags 1713 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1714 'V' bits MUST NOT be set. 1716 Integer32 1718 The Integer32 field contains the result code associated with 1719 the DIAMETER command. The following codes have been defined: 1721 DIAMETER_SUCCESS 0 1722 The Request was successfully completed. 1724 DIAMETER_FAILURE 1 1725 The Request was not successfully completed for an 1726 unspecified reason. A DIAMETER Message-Reject message 1727 returning this result SHOULD whenever possible also 1728 contain one or more Failed-AVP-Code AVPs indicating the 1729 attributes which caused the failure. 1731 DIAMETER_POOR_REQUEST 2 1732 The Request was poorly constructed. A DIAMETER Message- 1733 Reject message returning this result SHOULD whenever 1734 possible also contain one or more Failed-AVP-Code AVPs 1735 indicating the attributes which caused the failure. 1737 DIAMETER_INVALID_MAC 3 1738 The Request did not contain a valid Integrity-Check- 1739 Vector or Digital-Signature [11]. 1741 DIAMETER_UNKNOWN_SESSION_ID 4 1742 The Request contained an unknown Session-Id. 1744 DIAMETER_SEE_ERROR_CODE 5 1745 The Request failed. The message MUST also contain an 1746 Error-Code AVP which provides command-specific 1747 information on the failure. A DIAMETER Message-Reject- 1748 Ind message returning this result SHOULD whenever 1749 possible also contain one or more Failed-AVP-Code AVPs 1750 indicating the attributes which caused the failure. 1752 DIAMETER_COMMAND_UNSUPPORTED 6 1754 The Request contained a command code which the DIAMETER 1755 implementation does not recognize or does not support. 1756 The Message-Reject-Ind message MUST also contain an 1757 Unrecognized-Command-Code AVP which contains the Command 1758 Code value which was rejected. 1760 DIAMETER_ATTRIBUTE_UNSUPPORTED 8 1762 The Request contained an AVP with an AVP Code which the 1763 DIAMETER implementation does not recognize or does not 1764 support. An DIAMETER Message-Reject-Ind message returning 1765 this result MUST also contain one or more Failed-AVP-Code 1766 AVPs indicating the AVP Codes which caused the failure. 1768 DIAMETER_REDIRECT_INDICATION 9 1770 A proxy or broker has determined that the request could 1771 not be satisfied locally and the initiator of the request 1772 should direct the request directly to the server, whose 1773 contact information has been added to the response. 1775 DIAMETER_PEER_NOT_IN_GOOD_STANDING 10 1777 A proxy or broker has determined that the request could 1778 not be forwarded because the destination DIAMETER server 1779 is no longer in good standing. This is typically used by 1780 a broker to indicate that the relationship with the 1781 requested domain is not longer valid. 1783 4.15 Error-Code 1785 Description 1787 The Error-Code AVP contains the message specific error code, if 1788 any. This AVP only needs to be present if the Result-Code AVP is 1789 present with the DIAMETER_SEE_ERROR_CODE. 1791 Error-Code values and corresponding semantics are specific to the 1792 command to which the Error-Code is a response, and MUST therefore 1793 be documented as part of the description of that command. 1795 AVP Format 1797 0 1 2 3 1798 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 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | AVP Code | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | AVP Length | Reserved |T|V|H|M| 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Integer32 | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 AVP Code 1809 269 Error-Code 1811 AVP Length 1813 The length of this attribute MUST be 12. 1815 AVP Flags 1817 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1818 'V' bits MUST NOT be set. 1820 Integer32 1822 The Integer32 field contains the error code. 1824 4.16 Unrecognized-Command-Code 1826 Description 1828 The Unrecognized-Command-Code AVP contains the offending Command 1829 Code that resulted in sending the Message-Reject-Ind message. 1831 AVP Format 1832 0 1 2 3 1833 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 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | AVP Code | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | AVP Length | Reserved |T|V|H|M| 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | Integer32 | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 AVP Code 1844 270 Unrecognized-Command-Code 1846 AVP Length 1848 The length of this attribute MUST be 12. 1850 AVP Flags 1852 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1853 'V' bits MUST NOT be set. 1855 Integer32 1857 The Integer32 field contains the unrecognized command code that 1858 resulted in sending an Message-Reject-Ind message. 1860 4.17 Reboot-Type 1862 Description 1864 The Reboot-Type AVP MUST be present in the Device-Reboot- 1865 Indication message and contains an indication of the type of 1866 reboot. 1868 AVP Format 1870 0 1 2 3 1871 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 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | AVP Code | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | AVP Length | Reserved |T|V|H|M| 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | Integer32 | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 AVP Code 1881 271 Reboot-Type 1883 AVP Length 1885 The length of this attribute MUST be 12. 1887 AVP Flags 1889 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1890 'V' bits MUST NOT be set. 1892 Integer32 1894 The Integer32 field contains the reboot type associated with 1895 the DRI command. The following value are currently defined: 1897 REBOOT_IMMINENT 1 1898 When the Reboot-Type AVP is set to this value it is an 1899 indication that the DIAMETER peer is about to reboot and 1900 should not be sent any additional DIAMETER messages 1901 besides the acknowledgement. 1903 REBOOTED 2 1904 When the Reboot-Type AVP is set to this value it is an 1905 indication that the DIAMETER peer has recently rebooted 1906 and is ready to accept new DIAMETER messages. 1908 CLEAN_REBOOT 3 1909 When the Reboot-Type AVP is set to this value the server 1910 is in the process of shutting down and MAY be available 1911 at some time in the future. 1913 4.18 Reboot-Time 1915 Description 1917 The Reboot-Time AVP MAY be present in the DRI and indicates the 1918 number of seconds before the issuer expects to be ready to receive 1919 new DIAMETER messages. This AVP MUST only be present when the 1920 Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by 1921 this AVP should be used as an estimate and is not a hard rule. 1923 AVP Format 1924 0 1 2 3 1925 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 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | AVP Code | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | AVP Length | Reserved |T|V|H|M| 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | Integer32 | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 AVP Code 1936 272 Reboot-Time 1938 AVP Length 1940 The length of this attribute MUST be 12. 1942 AVP Flags 1944 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1945 'V' bits MUST NOT be set. 1947 Integer32 1949 The Integer32 field contains the expected amount of seconds 1950 before the issuer of the DRI expects to be receive to receive 1951 new DIAMETER messages. 1953 4.19 Failed-AVP-Code 1955 Description 1957 The Failed-AVP-Code AVP provides debugging information in cases 1958 where a request is rejected or not fully processed due to 1959 erroneous information in a specific AVP. The documentation of the 1960 Result-Code AVP and of the Message-Reject-Ind command provide 1961 information on the use of the Failed-AVP-Code AVP. This AVP has 1962 the following format: 1964 AVP Format 1965 0 1 2 3 1966 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 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | AVP Code | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | AVP Length | Reserved |T|V|H|M| 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Data... 1973 +-+-+-+-+-+-+-+-+ 1975 AVP Code 1977 279 Failed-AVP-Code 1979 AVP Length 1981 The length of this attribute MUST be 12. 1983 AVP Flags 1985 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1986 'V' bits MUST NOT be set. 1988 Data 1990 The Data field contains the complete AVP that could not be 1991 processed successfully. Possible reasons for this are an 1992 improperly-constructed AVP, an unsupported or unrecognized AVP 1993 Code, or an invalid value. 1995 4.20 User-Name 1997 Description 1999 This attribute contains the User-Name in a format consistent with 2000 the NAI specification [8]. 2002 A summary of the User-Name AVP format is shown below. The fields 2003 are transmitted from left to right. 2005 AVP Format 2007 0 1 2 3 2008 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 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | AVP Code | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | AVP Length | Reserved |T|V|H|M| 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 | String ... 2015 +-+-+-+-+-+-+-+-+ 2017 Type 2019 1 for User-Name. 2021 AVP Length 2023 The length of this AVP MUST be at least 9. 2025 AVP Flags 2027 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 2028 'V' bits MUST NOT be set. 2030 String 2032 The String field is one or more octets. All DIAMETER systems 2033 SHOULD support User-Name lengths of at least 63 octets. The 2034 format of the User-Name SHOULD follow the format defined in 2035 [8]. 2037 4.21 Receive-Window 2039 Description 2041 This AVP is used by a peer to inform its peer of its local receive 2042 window size. The size indicated is the number of packets that it 2043 is willing to accept before the window is full. 2045 A sending peer MUST stop sending new DIAMETER messages when this 2046 many messages are outstanding (sent but not yet acknowledged). 2048 If a peer does not issue this attribute, a receive window size of 2049 7 is assumed by its peer. 2051 This attribute is only valid in the Device-Reboot-Ind message. 2053 AVP Format 2054 0 1 2 3 2055 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 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | AVP Code | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | AVP Length | Reserved |T|V|H|M| 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Integer32 | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 AVP Code 2066 277 Receive-Window 2068 AVP Length 2070 The length of this attribute MUST be 12. 2072 AVP Flags 2074 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 2075 'V' bits MUST NOT be set. 2077 Integer32 2079 This field contains the receive window size. 2081 4.22 Proxy-State 2083 Description 2085 The Proxy-State AVP is used by proxy servers when forwarding 2086 requests and contains opaque data that is used by the proxy to 2087 further process the response. Such data may include AVPs that are 2088 to be added to the response, information about the downstream 2089 peer, etc. 2091 A DIAMETER node that receives such an AVP in a request MUST return 2092 the identical AVP in the response. Furthermore, only one such AVP 2093 may be present in a message at any given time, so implmentations 2094 MUST ensure that they remove any Proxy-State AVPs before adding 2095 their own. 2097 If the Proxy-State AVP was removed from a request, the same AVP 2098 must be inserted in the corresponding response before forwarding 2099 the message to the downstream peer. 2101 The Proxy-State AVP's Address field is intended to be used by 2102 DIAMETER hosts in order to assist in determining if the AVP was 2103 locally generated. 2105 AVP Format 2107 A summary of the Proxy-State AVP format is shown below. The fields 2108 are transmitted from left to right. 2110 0 1 2 3 2111 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 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | AVP Code | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | AVP Length | Reserved |T|V|H|M| 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | Address | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | Data ... 2120 +-+-+-+-+-+-+-+-+ 2122 AVP Code 2124 33 for Proxy-State. 2126 AVP Length 2128 The length of this attribute MUST be at least 13. 2130 AVP Flags 2132 The 'M' bit MUST be set. The 'V', 'H' and 'T' bits MUST NOT be 2133 set. 2135 Address 2137 The Address field contains the IP Address of the system that 2138 created the Proxy-State AVP. This field is intended to assist 2139 hosts in determining if a Proxy-State AVP in a message was 2140 locally created. 2142 Data 2144 The Data field is one or more octets. The actual format of the 2145 information is site or application specific, and a robust 2146 implementation SHOULD support the field as undistinguished 2147 octets. 2149 4.23 Redirect-Host 2151 Description 2153 The Redirect-Host AVP is returned in a response that has the 2154 Result-Code AVP set to DIAMETER_REDIRECT_REQUEST, and includes 2155 information about the DIAMETER host to which the request must be 2156 redirected. Upon receipt of such a Result-Code, and this AVP, a 2157 DIAMETER host should send the request directly to the host, whose 2158 address information is found in this AVP. A proxy server returning 2159 such an AVP may include more than one, if there is a group of 2160 DIAMETER servers that can satisfy the request. 2162 AVP Format 2164 A summary of the Redirect-Host AVP format is shown below. The 2165 fields are transmitted from left to right. 2167 0 1 2 3 2168 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 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | AVP Code | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | AVP Length | Reserved |T|V|H|M| 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Address | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 AVP Code 2179 278 for Redirect-Host. 2181 AVP Length 2183 The length of this attribute MUST be at least 12. 2185 AVP Flags 2187 The 'M' bit MUST be set. The 'V', 'H' and 'T' bits MUST NOT be 2188 set. 2190 Address 2192 The Address field contains the IP Address of a DIAMETER server 2193 that can satisfy the request that generated the response 2194 containing this AVP. 2196 4.24 Broker-Certificate 2198 Description 2200 The Broker-Certificate AVP is typically added by a broker in a 2201 network where the broker's organization also provides certificate 2202 authority services. In such networks, certificates are issued to 2203 all DIAMETER servers within the roaming consortium. The Broker- 2204 Certificate AVP contains a timestamp and an expiration time, which 2205 CAN be used by DIAMETER hosts in order to determine whether they 2206 should further validate the certificate against a certification 2207 validation infrastructure (see section 5.7 for more information). 2209 AVP Format 2211 A summary of the Broker-Certificate AVP format is shown below. The 2212 fields are transmitted from left to right. 2214 0 1 2 3 2215 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 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | AVP Code | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 | AVP Length | Reserved |T|V|H|M| 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Timestamp | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | Expiration Time | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 | Certificate Length | 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 | Digital Signature Length | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | Certificate ... 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 | Digital Signature ... 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 AVP Code 2236 280 for Broker-Certificate. 2238 AVP Length 2240 The length of this attribute MUST be at least 24. 2242 AVP Flags 2243 The 'M' bit MUST be set. The 'V', 'H' and 'T' bits MUST NOT be 2244 set. 2246 Timestamp 2248 The Timestamp field contains the number of seconds since Jan. 2249 1, 1900 when the AVP was created. 2251 Expiration 2253 The Expiration field contains the time after which the broker 2254 recommends that a new Broker-Certificate be retrieved. 2256 Certificate Length 2258 The Certificate Length field contains the number of octets of 2259 the certificate in the certificate field. 2261 Digital-Signature Length 2263 The Digital-Signature Length field contains the number of 2264 octets of the signature found in the Digital Signature field. 2266 Certificate 2268 The certificate field contains the X.509 certificate. 2270 Digital-Signature 2272 The Digital-Signature field contains the broker's digital 2273 signature. 2275 5.0 Protocol Definition 2277 This section will describe how the base protocol works (or is at 2278 least an attempt to). 2280 5.1 DIAMETER Bootstrap Message 2282 DIAMETER provides a message that is used to indicate either an 2283 imminent reboot, or that a reboot has occurred. The DRI message MUST 2284 be sent to all known DIAMETER peers both previous to a reboot when 2285 possible as well as following a reboot. 2287 The Reboot-Type AVP is used to indicate the type of reboot associated 2288 with the DRI. When set to REBOOT_IMMINENT, all peers should be warned 2289 that any new DIAMETER requests sent to the issuer will probably not 2290 be received or processed. If a request MUST be sent it would be 2291 preferable to issue the request to an alternate peer if available. 2293 The message includes an optional Reboot-Time AVP that specifies an 2294 estimate of how long before the issuer is available to receive new 2295 DIAMETER messages. 2297 Upon reboot, the host MUST issue a DRI message with the Reboot-Type 2298 AVP set to REBOOTED. This is an indication that new DIAMETER messages 2299 may be sent to the transmitter of the DRI. 2301 Note that the Reboot-Time AVP is not required, and when present 2302 provides an estimate and should not be used as a hard value. In the 2303 case of a software implementation (server) running on a general 2304 purpose operating system, the Reboot-Time AVP will probably not be 2305 present since it is possible that the DIAMETER server has been 2306 stopped and it is not possible to know how long before (and if) it 2307 will be restarted. 2309 Upon receipt of this message the peer's Ss and Sr variables must be 2310 reset. It is possible for this message to be received outside the 2311 window (Ns and Nr set to zero) when it follows a reboot. 2313 The DIAMETER Reboot-Ind message does not require a reply. The message 2314 is acknowledged using DIAMETER's reliable transport. 2316 The following figure depicts a sample flow of Device-Reboot-Ind 2317 between three DIAMETER peers, one being a proxy or broker server. In 2318 this example DIA1 initiates the bootstrap sequence with DIA, and 2319 later DIA3 initiates the bootstrap sequence with DIA. After some time 2320 DIA1 needs to reboot and informs DIA2. The details of each message is 2321 provided below. 2323 +-------+ +-------+ +-------+ 2324 | DIA1 | | PROXY | | DIA3 | 2325 | | | DIA2 | | | 2326 +-------+ +-------+ +-------+ 2327 | | | 2328 |DRI (ns=0, nr=0) | | 2329 | Rebooted | | 2330 | version 1, | | 2331 | extensions 1, 4 | | 2332 (a) |------------------->| | 2333 |DRI (ns=0, nr=1) | | 2334 | Rebooted | | 2335 | version 1, | | 2336 | extension 1 | | 2337 (b) |<-------------------| | 2338 |ZLB (ns=0, nr=1) | | 2339 (c) |<-------------------| | 2340 | . |DRI (ns=0, nr=0) | 2341 | . | Rebooted | 2342 | | version 1, | 2343 | | extensions 1, 2 | 2344 (d) | |<------------------| 2345 | |DRI (ns=0, nr=1) | 2346 | | Rebooted | 2347 | | version 1, | 2348 | | extension 1 | 2349 (e) | |------------------>| 2350 | |ZLB (ns=0, nr=1) | 2351 (f) | |------------------>| 2352 |DRI (ns=x, nr=y) | . | 2353 | Upcoming Reboot | . | 2354 (g) |------------------->| | 2355 | . | | 2356 | . | | 2357 |DRI (ns=0, nr=0) | | 2358 | Rebooted | | 2359 | version 1, | | 2360 | extensions 1, 4 | | 2361 (h) |------------------->| | 2362 | | | 2363 Figure 2: Sample DRI Message Flow in a Proxy Environment 2365 (a) DIA1 sends a DRI message to DIA2 indicating that its version 2366 is one (1) and that its supported extensions are 1 (Roamops) and 4 2367 (Mobile-IP). 2369 (b) DIA2 sends a DRI message to DIA1 indicating that its version 2370 is one (1) and that its supported extension is 1 (Roamops). This 2371 message also includes a piggy-backed acknowledgement of (a). 2373 (c) DIA1 sends an acknowledgement of (b) 2375 (d) DIA3 sends a DRI message to DIA2 indicating that its version 2376 is one (1) and that its supported extensions are 1 (Roamops) and 2 2377 (Secure Proxy). 2379 (e) DIA2 sends a DRI message to DIA1 indicating that its version 2380 is one (1) and that its supported extension is 1 (Roamops). This 2381 message also includes a piggy-backed acknowledgement of (d). 2383 (f) DIA1 sends an acknowledgement of (e) 2385 (g) after some time DIA1 sends an indication to DIA2 that it is 2386 about to reboot. All messages destined to the domain for which 2387 DIA1 is responsible for should be redirected to an alternate 2388 DIAMETER Server. 2390 (h) Once the reboot is complete, DIA sends the DRI, which causes 2391 steps (a) through (c) to be repeated. 2393 5.1.1 State Machine 2395 A DIAMETER node initially considers all known peers to be in the 2396 closed state, and should not process any DIAMETER message with the 2397 exception of acknowledgements and the DRI. Once the DIAMETER peer is 2398 set to the open state, any DIAMETER message may be accepted and 2399 processed. The following is a suggested state machine. 2401 State Event Action New State 2402 ----- ----- ------ --------- 2403 closed Local Open send DRI wait-ack1 2404 Request 2406 closed receive DRI send ACK wait-ack2 2407 send DRI 2409 closed receive invalid cleanup closed 2410 DRI 2412 wait-ack1 receive ACK accept Incoming wait-ack1 2413 Messages 2415 wait-ack1 receive DRI send ACK open 2416 Accept Incoming 2417 Messages 2419 wait-ack2 received ACK Accept Incoming open 2420 Messages 2422 open receive DRI cleanup closed 2424 open receive DWI send ACK open 2426 open receive other send ACK open 2427 messages 2429 5.2 Keepalive Exchange 2431 DIAMETER uses the Device-Watchdog-Ind message as a keepalive 2432 mechanism. DIAMETER entities that need to ensure that connectivity 2433 with a peer is not lost may use this mechanism. 2435 A DIAMETER Client can use this mechanism to ensure that failover to 2436 an alternate server occurs even without any AAA traffic. DIAMETER 2437 Servers use this mechanism to identify when a particular client is no 2438 longer reachable. Redundant DIAMETER Servers can use this mechanism 2439 to identify when the primary server is no longer available. Proxy 2440 Servers can equally use this method to identify when a particular 2441 domain's server is no longer reachable. 2443 The DIAMETER Device-Watchdog-Ind message does not require a reply. 2444 The message is acknowledged using DIAMETER's reliable transport. 2446 The following figure provides an example of how the Device-Watchdog- 2447 Ind message is used in a proxy environment. Each node is responsible 2448 for sending their own Device-Watchdog-Ind message to its peer when no 2449 activity is present for some time, which can be configurable. Note 2450 that it is possible for each node in the network to have a different 2451 inactivity timer configured. The more aggresive the timer, the more 2452 traffic is generated, but the quicker it can detect if a peer is no 2453 longer reachable. The details of each message is provided below. 2455 +-------+ +-------+ +-------+ 2456 | DIA1 | | PROXY | | DIA3 | 2457 | | | DIA2 | | | 2458 +-------+ +-------+ +-------+ 2459 | | | 2460 |CMD-X (ns=23, nr=40)| | 2461 (a) |------------------->| | 2462 |ZLB (ns=40, nr=24) | | 2463 (b) |<-------------------| | 2464 | . | | 2465 | . | | 2466 | |CMD-Y (ns=12, nr=20)| 2467 (c) | |------------------->| 2468 | |ZLB (ns=20, nr=13) | 2469 (d) | |<-------------------| 2470 |WDI (ns=24, nr=40) | . | 2471 (e) |------------------->| . | 2472 |ZLB (ns=40, nr=25) | | 2473 (f) |<-------------------| | 2474 | |WDI (ns=21, nr=13) | 2475 (g) | |<-------------------| 2476 | |ZLB (ns=13, nr=22) | 2477 (h) | |------------------->| 2478 | | | 2479 Figure 3: Sample WDI Message in a Proxy Environment 2481 (a) DIA1 issues a packet to DIA2 2483 (b) DIA2 acknowledges the receipt of (a) 2485 (c) DIA3 issues a packet to DIA2 2487 (d) DIA2 acknowleges the receipt of (c) 2489 (e) After some time of inactivity, DIA1 issues a WDI to DIA2 2491 (f) DIA2 acknowledges the receipt of (e) 2493 (g) After some period of inactivity, DIA3 issues a WDI to DIA2 2495 (h) DIA2 acknowledges the receipt of (g) 2497 5.3 Unrecognized Command Support 2499 The DIAMETER protocol provides a message that is used to inform a 2500 peer that a DIAMETER message was received with an unrecognized 2501 command. The following provides a DIAMETER message that is sent to a 2502 peer: 2504 ::= 2505 2506 2507 [] 2508 2509 2510 { || 2511 ::= 2517 2518 2519 2520 [] 2521 2522 2523 { || 2524 | 2536 |MRI(Unrecognized Command Code) | 2537 (b) |<------------------------------------| 2538 | . | 2539 | . | 2540 |Unknown AVP | 2541 (c) |<------------------------------------| 2542 |MRI(Failed AVP Code) | 2543 (d) |------------------------------------>| 2544 | . | 2545 | . | 2546 |Bad value in a valid AVP | 2547 (e) |------------------------------------>| 2548 |MRI (Error Code | Failed AVP Code) | 2549 (f) |<------------------------------------| 2550 Figure 4: Sample MRI Message Flow 2552 (a) DIA2 receives an unknown command from DIA1. 2554 (b) DIA2 recognizes that it received an unknown command and 2555 hence sends an MRI with Unrecognized Command Code AVP. 2557 (c) DIA1 receives an unknown AVP in a message sent by DIA2. 2559 (d) DIA1 recognizes that it received an unknown AVP and 2560 returns an MRI with Failed AVP Code to DIA2. 2562 (e) DIA2 receives a bad parameter within a otherwise 2563 valid AVP from DIA1. 2565 (f) As soon as it discovers that it has received a bad 2566 parameter, it returns an MRI message to DIA1 with 2567 Error Code AVP and Failed AVP Code. 2569 5.4 The art of AVP Tagging 2571 The AVP Header provides the 'T' bit that is used for grouping AVPs 2572 together. Although the base protocol does not define any AVPs that 2573 need to be grouped, it is envisioned that DIAMETER extensions will 2574 require tag support. 2576 In the case where multiple AVPs are needed to indicate a specific 2577 authorization "rule" tagging is appropriate. Such an example is taken 2578 from [10] that discusses Tunneling attributes. In this case multiple 2579 AVPs are required in order to specify tunnel parameter, and more than 2580 one set of AVPs MAY be present in the message. This is necessary in 2581 order to support redundant tunnel servers. 2583 In this case, the AVPs that need to be grouped together would have a 2584 specific tag value, and each group would use a different tag value. 2586 5.5 Using the Integrity-Check-Vector 2588 The use of the Integrity-Check-Vector (ICV) AVP requires a pre- 2589 configured shared secret. Although this mechanism does not scale as 2590 well as the Digital Signature, it may be desirable to use this 2591 mechanism in the case where asymmetric technology is not required or 2592 available. 2594 Note that in the case where two DIAMETER nodes need to communicate 2595 through an intermediate node (i.e. Proxy) it does not offer any end- 2596 to-end data integrity or encryption as each node must re-compute the 2597 Integrity-Check-Vector AVP. 2599 The Data field of the AVP contains an HMAC-MD5-96[6] of the message 2600 up to the ICV AVP. Using the example code provided in [6], the 2601 following call would be used to generate the Integrity-Check-Vector: 2603 The Timestamp and Nonce AVPs MUST be present in the message PRIOR to 2604 the Integrity-Check-Vector AVP. The Timestamp AVP provides replay 2605 protection and the Nonce AVP provides randomness. 2607 hmac_md5(DiameterMessage, MessageLength, Secret, Secretlength, 2608 Output) 2610 The following is an example of a message that include hop-by-hop 2611 security: 2613 ::= 2614 2615 [] 2616 2617 2618 2620 Any AVPs in a message that is not succeeded by the Integrity-Check- 2621 Vector AVP MUST be ignored. 2623 5.6 DIAMETER Proxying 2625 This section will describe how DIAMETER server implementations can 2626 proxy requests to upstream servers. Consider the following diagram, 2627 which depicts DIA1 sending a request to DIA2. Typically, the request 2628 will contain the User-Name AVP (section 4.20), which conforms to the 2629 format defined in the NAI specification [8]. Server DIA2 normally 2630 will extract that domain name portion of the NAI to determine if the 2631 request can be locally processed, or if the request must be proxied 2632 to an upstream server (in this case DIA3). 2634 (Request) (Request) 2635 (User-Name = joe@abc.com) (Proxy-State=1) 2636 +------+ ------> +------+ ------> +------+ 2637 | | | | | | 2638 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 2639 | | | | | | 2640 +------+ <------ +------+ <------ +------+ 2641 (Response) (Response) 2642 (Proxy-State=1) 2643 mno.net xyz.com abc.com 2644 Figure 5: DIAMETER Proxying 2646 Prior to forwarding the request, DIA2 must establish some state 2647 information in order to be able to forward the corresponding response 2648 from DIA3 to DIA1. There are two methods of doing so: 2650 1. DIA2 can maintain state information locally, and using the 2651 session-Id and possible the Identifier in the header, can match 2652 the request with the response. The state information would contain 2653 sufficient information for it to know where the response should be 2654 forwarded. Additionally, it may be necessary for DIA2 to attach 2655 AVPs to the response that were created when the request was 2656 received. These AVPs could be kept in the state table. 2658 2. DIA2 can attach a Proxy-State AVP (section 4.22), which may 2659 contain any information, including information regarding the 2660 source of the request, additional AVPs that must be attached to 2661 the response, etc. Upon receipt of the response, DIA2 must find 2662 the Proxy-State AVP, determine if the AVP was created locally, and 2663 if so use the information included within the AVP. If AVPs were 2664 found within the Proxy-State AVP, they could easily be attached to 2665 the response. Finally, the Proxy-State AVP is removed from the 2666 response before being forwarded to DIA1. 2668 Althought both methods work, the latter is much simpler as it 2669 reduces the amount of state information each proxy must maintain 2670 on a per request basis. 2672 When DIA3 receives a request that includes the Proxy-State AVP, it 2673 MUST include the same AVP in the corresponding response. 2674 Furthermore, should DIA3 have to proxy the request to another 2675 upstream server, it would have to replace the existing Proxy-State 2676 AVP with its own. It must, however, be able to replace the Proxy- 2677 State AVP in the corresponding response back to the one it had 2678 received in the request. One suggested implementation is to 2679 include the Proxy-State AVPs in a newly created Proxy-State AVP, 2680 allowing a server to easily replace the Proxy-State AVPs in the 2681 responses. 2683 5.7 Message Redirection 2685 There are cases where a DIAMETER proxy, known as a broker, may wish 2686 to request that a server contact another directly instead of 2687 forwarding the message (figure x). This is typically done when the 2688 broker provides simple NAI to Home DIAMETER Server address resolution 2689 services. 2691 +------------------+ +---------+ 2692 | DIAMETER | | CRL DB/ | 2693 | Broker | | OCSP | 2694 +------------------+ +---------+ 2695 /|( 2696 Request | Response w/ | 2697 Result Code = | Redirect 2698 / 2699 +----------+ +----------+ 2700 | abc.net |/ xyz.net | 2701 | DIAMETER |--------------| DIAMETER | 2702 | Server | /| Server | 2703 +----------+ Direct +----------+ 2704 Communication 2705 Figure 6: DIAMETER Broker Returning Redirect Indication 2707 In the example provided in figure 6, abc.net's DIAMETER server issues 2708 a request to its broker, which in turn returns a response that 2709 includes the Result-Code AVP set to a specific value (see section 2710 4.14). When a response is received with such a value, the message 2711 MUST also include one or more Redirect-Host AVPs. These AVPs contain 2712 address information that can be then used to directly communicate 2713 with the Home DIAMETER Server. Note that the servers COULD cache the 2714 home server information in order to reduce the latency involved in 2715 any future messages destined for that home server. 2717 When returning the response with the Result-Code set to indicate a 2718 redirect indication, the broker can also include the certificates of 2719 both the requesting server, and the target server. These certificates 2720 are encapsulated in the Broker-Certificate AVP, which also includes a 2721 timestamp and an expiration time. The requesting server can forward 2722 the Broker-Certificate that belongs to it in the subsequent request 2723 to the home DIAMETER server. The Broker-Certificate is intended to 2724 allow the peers to communicate without having to validate the 2725 certificate against a certificate validation infrastructure, such as 2726 Certificate Revocation Lists (CRLs) or using Online Certificate 2727 Status Protocol (OCSP) [14]. Local policy at the individual servers 2728 will dictate whether they can trust the Broker-Certificate, or 2729 whether they must validate the certificate themselves. 2731 5.8 AVP Encryption with Shared Secrets 2733 This method of encrypting AVP data is the simplest to use and MUST be 2734 supported by all DIAMETER implementations. However, local policy MAY 2735 determine that the use of this mechanism is not permitted. 2737 The 'H' bit MUST only be set if a shared secret exists between both 2738 DIAMETER peers. If the 'H' bit is set in any DIAMETER AVP, the Nonce 2739 AVP MUST be present prior to the first encrypted AVP. 2741 The length of the AVP value to be encrypted is first encoded in the 2742 following Subformat, which is included in the AVP's data field. 2744 0 1 2 3 2745 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 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 | Length of ClearText Data | ClearText Data ... 2748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 | Padding ... 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 Length 2754 The Length field contains the length of the decrypted data. 2756 ClearText Data 2758 Data of AVP that is to be obscured. 2760 Padding 2762 Random additional octets used to obscure length of the ClearText 2763 Data. 2765 The resulting subformat MAY be padded to a multiple of 16 octets in 2766 length. For example, if the ClearText Data to be obscured is a string 2767 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 2768 octets of padding would be applied. Padding does NOT alter the value 2769 placed in the Length of the ClearText Data, only the length of the 2770 AVP itself. 2772 Next, An MD5 hash is performed on the concatenation of: 2774 - the four octet Command Code of the AVP 2775 - the shared authentication secret 2776 - an arbitrary length random vector 2778 The value of the random vector used in this hash is passed in the 2779 Data field of a Nonce AVP. This Nonce AVP must appear in the message 2780 before any hidden AVPs. The same Nonce may be used for more than one 2781 hidden AVP in the same message. If a different Nonce is used for the 2782 hiding of subsequent AVPs then a new Nonce AVP must be placed before 2783 the first AVP to which it applies. 2785 The MD5 hash value is then XORed with the first 16 octet or less 2786 segment of the AVP Subformat and placed in the Data field of the AVP. 2787 If the AVP Subformat is less than 16 octets, the Subformat is 2788 transformed as if the Value field had been padded to 16 octets before 2789 the XOR, but only the actual octets present in the Subformat are 2790 modified, and the length of the AVP is not altered. 2792 If the Subformat is longer than 16 octets, a second one-way MD5 hash 2793 is calculated over a stream of octets consisting of the shared secret 2794 followed by the result of the first XOR. That hash is XORed with the 2795 second 16 octet or less segment of the Subformat and placed in the 2796 corresponding octets of the Data field of the AVP. 2798 If necessary, this operation is repeated, with each XOR result being 2799 used along with the shared secret to generate the next hash to XOR 2800 the next segment of the value with. This technique results in the 2801 content of the AVP being obscured, although the length of the AVP is 2802 still known. 2804 On receipt, the Nonce is taken from the last Nonce AVP encountered in 2805 the message prior to the AVP to be decrypted. The above process is 2806 then reversed to yield the original value. For more details on this 2807 hiding method, consult RFC2138 [1]. 2809 Please note that in the case where the DIAMETER message needs to be 2810 processed by an intermediate non-trusted DIAMETER server (also known 2811 as a proxy server, depicted as DIA2 in the figure below) the AVP 2812 needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 2813 using Shared-Secret-2. 2815 (Shared-Secret-1) (Shared-Secret-2) 2816 +------+ -----> +------+ ------> +------+ 2817 | | | | | | 2818 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 2819 | | | | | | 2820 +------+ +------+ +------+ 2821 Figure 7: Message Forwarding 2823 Unfortunately in this case the non-trusted server DIA2 has access to 2824 sensitive information (such as a password). 2826 6.0 IANA Considerations 2828 This document defines a number of "magic" numbers to be maintained by 2829 the IANA. This section explains the criteria to be used by the IANA 2830 to assign additional numbers in each of these lists. The following 2831 subsections describe the assignment policy for the namespaces defined 2832 elsewhere in this document. 2834 6.1 AVP Attributes 2836 As defined in Section 4.0, AVPs contain vendor ID, Attribute and 2837 Value fields. For vendor ID value of 0, IANA will maintain a registry 2838 of assigned Attributes and in some case also values. Attribute 0-254 2839 are assigned from the RADIUS protocol [1], whose attributes are also 2840 maintained through IANA. Attributes 256-280 are assigned within this 2841 document in section 4.0. The remaining values are available for 2842 assignment through IETF Consensus [12]. 2844 6.2 Command Code AVP Values 2846 As defined in Section 4.1, the Command Code AVPs (AVP Code 256) have 2847 an associated value maintained by IANA. Values 0-255 are reserved for 2848 backward RADIUS compatibility, and values 256-258 are defined in this 2849 specification. The remaining values are available for assignment via 2850 IETF Consensus [12]. 2852 6.3 Extension Identifier Values 2854 as defined in Section 4.7, the Extension Identifier is used to 2855 identify a specific DIAMETER Extension. All values, other than zero 2856 (0) are available for assignment via IETF Consensus [12]. 2858 6.4 Result Code AVP Values 2860 As defined in Section 4.14, the Result Code AVP (AVP Code 268) 2861 defines the values 0-8. All remaining values are available for 2862 assignment via IETF Consensus [12]. 2864 6.5 Integrity Check Vector Transform Values 2866 Section 4.8 defines the Integrity-Check-Vector AVP (AVP Code 259) 2867 which contains a field called the Transform. This document reserves 2868 the value 1. All remaining values are available for assignment via 2869 IETF Consensus [12]. 2871 6.6 Reboot Type Values 2873 Section 4.17 defines the Reboot-Type AVP (AVP Code 271), which is 2874 used to inform the peer of the cause for the reboot. This document 2875 defines the values 1-3. All remaining values are available for 2876 assignment via IETF Consensus [12]. 2878 6.7 AVP Header Bits 2880 There are six remaining reserved bits in the AVP header. Additional 2881 bits should only be assigned via a Standards Action [12]. 2883 7.0 References 2885 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 2886 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, 2887 October 1994. 2888 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 2889 [4] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 2890 RFC 1321, April 1992. 2891 [5] Kaufman, Perlman, Speciner, "Network Security: Private 2892 Communications in a Public World", Prentice Hall, 2893 March 1995, ISBN 0-13-061466-1. 2894 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 2895 Authentication", RFC 2104, January 1997. 2896 [7] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 2897 draft-calhoun-diameter-authen-06.txt, Work in Progress, 2898 August 1999. 2899 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. 2900 January 1999. 2901 [9] Calhoun, Zorn, Pan, "DIAMETER Framework", 2902 draft-calhoun-diameter-framework-02.txt, Work in Progress, 2903 December 1998. 2904 [10] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for 2905 Tunnel Protocol Support", 2906 draft-ietf-radius-tunnel-auth-05.txt, Work in Progress, 2907 April 1998. 2908 [11] Calhoun, Bulley, "DIAMETER Proxy Extension", 2909 draft-calhoun-diameter-proxy-02.txt, Work in Progress, 2910 August 1999. 2911 [12] Narten, Alvestrand,"Guidelines for Writing an IANA 2912 Considerations Section in RFCs", BCP 26, RFC 2434, 2913 October 1998 2914 [13] S. Bradner, "Key words for use in RFCs to Indicate 2915 Requirement Levels", BCP 14, RFC 2119, March 1997. 2917 [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet 2918 Public Key Infrastructure Online Certificate Status 2919 Protocol (OCSP)", RFC 2560, June 1999. 2921 [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting 2922 Extension", draft-calhoun-diameter-accounting-00.txt, 2923 IETF Work in Progress, September 1999. 2925 8.0 Acknowledgements 2927 The Authors would like to acknowledge the following people for their 2928 contribution in the development of the DIAMETER protocol: 2930 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2931 Ignacio Goyret, Nancy Greene, Erik Guttman, Peter Heitman, Paul 2932 Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, 2933 Nenad Trifunovic, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and 2934 Glen Zorn 2936 9.0 Author's Address 2938 Questions about this memo can be directed to: 2940 Pat R. Calhoun 2941 Network and Security Research Center, Sun Labs 2942 Sun Microsystems, Inc. 2943 15 Network Circle 2944 Menlo Park, California, 94025 2945 USA 2947 Phone: 1-650-786-7733 2948 Fax: 1-650-786-6445 2949 E-mail: pcalhoun@eng.sun.com 2951 Allan C. Rubens 2952 Tut Systems, Inc. 2953 220 E. Huron, Suite 260 2954 Ann Arbor, MI 48104 2955 USA 2957 Phone: 1-734-995-1697 2958 E-Mail: arubens@tutsys.com 2960 Haseeb Akhtar 2961 Wireless Technology Labs 2962 Nortel Networks 2963 2221 Lakeside Blvd. 2964 Richardson, TX 75082-4399 2965 USA 2967 Phone: 1-972-684-8850 2968 E-Mail: haseeb@nortelnetworks.com 2970 10.0 Full Copyright Statement 2972 Copyright (C) The Internet Society (1999). All Rights Reserved. 2974 This document and translations of it may be copied and furnished 2975 to others, and derivative works that comment on or otherwise 2976 explain it or assist in its implmentation may be prepared, copied, 2977 published and distributed, in whole or in part, without 2978 restriction of any kind, provided that the above copyright notice 2979 and this paragraph are included on all such copies and derivative 2980 works. However, this docu- ment itself may not be modified in any 2981 way, such as by removing the copyright notice or references to the 2982 Internet Society or other Inter- net organizations, except as needed 2983 for the purpose of developing Internet standards in which case 2984 the procedures for copyrights defined in the Internet Standards 2985 process must be followed, or as required to translate it into 2986 languages other than English. The limited permis- sions granted 2987 above are perpetual and will not be revoked by the Internet 2988 Society or its successors or assigns. This document and the 2989 information contained herein is provided on an "AS IS" basis and 2990 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 2991 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2992 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 2993 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2994 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2996 Appendix A: Acknowledgment Timeouts 2998 DIAMETER uses sliding windows and timeouts to provide flow-control 2999 across the underlying medium and to perform efficient data buffering 3000 to keep two DIAMETER peers' receive window full without causing 3001 receive buffer overflow. DIAMETER requires that a timeout be used to 3002 recover from dropped packets. 3004 When the timeout for a peer expires, the previously transmitted 3005 message with Ns value equal to the highest in-sequence value of Nr 3006 received from the peer is retransmitted. The receiving peer does not 3007 advance its value for the receive sequence number state, Sr, until it 3008 receives a message with Ns equal to its current value of Sr. 3010 This rule assures that all subsequent acknowledgements to this peer 3011 will contain an Nr value equal to the Ns value of the first missing 3012 message until a message with the missing Ns value is received. 3014 The exact implementation of the acknowledgment timeout is vendor- 3015 specific. It is suggested that an adaptive timeout be implemented 3016 with backoff for flow control. The timeout mechanism proposed here 3017 has the following properties: 3019 Independent timeouts for each peer. A device will have to 3020 maintain and calculate timeouts for every active peer. 3022 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 3023 each device. 3025 An adaptive timeout mechanism that compensates for changing 3026 throughput. To reduce packet processing overhead, vendors may 3027 choose not to recompute the adaptive timeout for every received 3028 acknowledgment. The result of this overhead reduction is that the 3029 timeout will not respond as quickly to rapid network changes. 3031 Timer backoff on timeout to reduce congestion. The backed-off 3032 timer value is limited by the configurable maximum timeout value. 3033 Timer backoff is done every time an acknowledgment timeout occurs. 3035 In general, this mechanism has the desirable behavior of quickly 3036 backing off upon a timeout and of slowly decreasing the timeout value 3037 as packets are delivered without errors. 3039 A.1 Calculating Adaptive Acknowledgment Timeout 3041 We must decide how much time to allow for acknowledgments to return. 3042 If the timeout is set too high, we may wait an unnecessarily long 3043 time for dropped packets. If the timeout is too short, we may time 3044 out just before the acknowledgment arrives. The acknowledgment 3045 timeout should also be reasonable and responsive to changing network 3046 conditions. 3048 The suggested adaptive algorithm detailed below is based on the TCP 3049 1989 implementation and is explained in Richard Steven's book TCP/IP 3050 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 3051 calculation, and 'n-1' refers to values from the last calculation. 3053 DIFF[n] = SAMPLE[n] - RTT[n-1] 3054 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 3055 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 3056 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 3058 DIFF represents the error between the last estimated round-trip time 3059 and the measured time. DIFF is calculated on each iteration. 3061 DEV is the estimated mean deviation. This approximates the standard 3062 deviation. DEV is calculated on each iteration and stored for use in 3063 the next iteration. Initially, it is set to 0. 3065 RTT is the estimated round-trip time of an average packet. RTT is 3066 calculated on each iteration and stored for use in the next 3067 iteration. Initially, it is set to PPD. 3069 ATO is the adaptive timeout for the next transmitted packet. ATO is 3070 calculated on each iteration. Its value is limited, by the MIN 3071 function, to be a maximum of the configured MaxTimeOut value. 3073 Alpha is the gain for the round trip estimate error and is typically 3074 1/8 (0.125). 3076 Beta is the gain for the deviation and is typically 1/4 (0.250). 3078 Chi is the gain for the timeout and is typically set to 4. 3080 To eliminate division operations for fractional gain elements, the 3081 entire set of equations can be scaled. With the suggested gain 3082 constants, they should be scaled by 8 to eliminate all division. To 3083 simplify calculations, all gain values are kept to powers of two so 3084 that shift operations can be used in place of multiplication or 3085 division. The above calculations are carried out each time an 3086 acknowledgment is received for a packet that was not retransmitted 3087 (no timeout occured). 3089 A.2 Flow Control: Adjusting for Timeout 3091 This section describes how the calculation of ATO is modified in the 3092 case where a timeout does occur. When a timeout occurs, the timeout 3093 value should be adjusted rapidly upward. To compensate for shifting 3094 internetwork time delays, a strategy must be employed to increase the 3095 timeout when it expires. A simple formula called Karn's Algorithm is 3096 used in TCP implementations and may be used in implementing the 3097 backoff timers for the DIAMETER peers. Notice that in addition to 3098 increasing the timeout, we also shrink the size of the window as 3099 described in the next section. 3101 Karn's timer backoff algorithm, as used in TCP, is: 3103 NewTIMEOUT = delta * TIMEOUT 3105 Adapted to our timeout calculations, for an interval in which a 3106 timeout occurs, the new timeout interval ATO is calculated as: 3108 RTT[n] = delta * RTT[n-1] 3109 DEV[n] = DEV[n-1] 3110 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 3112 In this modified calculation of ATO, only the two values that 3113 contribute to ATO and that are stored for the next iteration are 3114 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 3115 not carried forward and is not used in this scenario. A value of 2 3116 for Delta, the timeout gain factor for RTT, is suggested. 3118 Appendix B: Examples of sequence numbering 3120 This appendix uses several common scenarios to illustrate how 3121 sequence number state progresses and is interpreted. 3123 B.1 Lock-step session establishment 3125 In this example, a DIAMETER host establishes communication with a 3126 peer, with the exchange involving each side alternating in the 3127 sending of messages. This example is contrived, in that the final 3128 acknowledgement typically would be included in the Device-Watchdog- 3129 Ind message. 3131 DIAMETER Host A DIAMETER Host B 3132 -> Device-Reboot-Ind 3133 Nr: 0, Ns: 0 3135 (ZLB) <- 3136 Nr: 1, Ns: 0 3138 -> Device-Watchdog-Ind 3139 Nr: 0, Ns: 1 3141 (delay) 3143 (ZLB) <- 3144 Nr: 2, Ns: 0 3146 B.2 Multiple packets acknowledged 3148 This example shows a flow of packets from DIAMETER Host B to Host A, 3149 with Host A having no traffic of its own. Host A is waiting 1/4 of 3150 its timeout interval, and then acknowledging all packets seen since 3151 the last interval. 3153 DIAMETER Host A DIAMETER Host B 3154 (previous packet flow precedes this) 3156 -> (ZLB) 3157 Nr: 7000, Ns: 1000 3158 (non-ZLB) <- 3159 Nr: 1000, Ns: 7000 3160 (non-ZLB) <- 3161 Nr: 1000, Ns: 7001 3162 (non-ZLB) <- 3163 Nr: 1000, Ns: 7002 3165 (Host A's timer indicates it should acknowledge pending 3166 traffic) 3168 -> (ZLB) 3169 Nr: 7003, Ns: 1000 3171 B.3 Lost packet with retransmission 3173 Host A attempts to communicate with Host B. The Device-Reboot-Ind 3174 sent from B to A is lost and must be retransmitted by Host B. 3176 DIAMETER Host A DIAMETER Host B 3177 -> Device-Reboot-Ind 3178 Nr: 0, Ns: 0 3180 (packet lost) Device-Reboot-Ind <- 3181 Nr: 1, Ns: 0 3183 (pause; Host A's timer started first, so fires first) 3185 -> Device-Reboot-Ind 3186 Nr: 0, Ns: 0 3188 (Host B realizes it has already seen this packet) 3189 (Host B might use this as a cue to retransmit, as in this 3190 example) 3192 Device-Reboot-Ind <- 3193 Nr: 1, Ns: 0 3194 -> Device-Watchdog-Ind 3195 Nr: 1, Ns: 1 3197 (delay) 3199 (ZLB) <- 3200 Nr: 2, Ns: 1