idnits 2.17.1 draft-calhoun-diameter-08.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 1 longer page, the longest (page 1) being 2941 lines 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 4 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 2169 has weird spacing: '...invalid clea...' == Line 2572 has weird spacing: '... copied and ...' == Line 2573 has weird spacing: '...s, and deriv...' == Line 2575 has weird spacing: '...blished and d...' == Line 2576 has weird spacing: '...hat the above...' == (6 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). -- 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) -- Looks like a reference, but probably isn't: 'XXX' on line 139 == Unused Reference: '3' is defined on line 2504, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2505, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2507, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2517, 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) Summary: 15 errors (**), 0 flaws (~~), 16 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-08.txt Allan C. Rubens 4 Date: August 1999 Ascend Communications 6 DIAMETER Base Protocol 8 Status of this Memo 10 This document is an individual contribution for consideration by the 11 AAA Working Group of the Internet Engineering Task Force. Comments 12 should be submitted to the diameter@ipass.com mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The DIAMETER base protocol is intended to provide a framework for any 38 services which require AAA/Policy support. The protocol is intended 39 to be flexible enough to allow services to add building blocks (or 40 extensions) to DIAMETER in order to meet their requirements. 42 This draft specifies the message format and transport to be used by 43 all DIAMETER extensions and MUST be supported by all DIAMETER 44 implementations, regardless of the specific underlying service. 46 Table of Contents 48 1.0 Introduction 49 1.1 Copyright Statement 50 1.2 Requirements language 51 1.3 Terminology 52 1.4 Changes in Revision 8 53 2.0 Protocol Overview 54 2.1 Header Format 55 2.1.1 ZLB Message Format 56 2.2 AVP Format 57 2.3 Error Reporting 58 3.0 Reliable Transport 59 3.1 Flow Control 60 3.2 Suggested implementation 61 3.3 Peer failure recovery 62 4.0 DIAMETER AVPs 63 4.1 DIAMETER-Command AVP 64 4.1.1 Message-Reject-Ind 65 4.1.2 Device-Reboot-Ind 66 4.1.3 Device-Watchdog-Ind 67 4.2 Host-IP-Address 68 4.3 Host-Name 69 4.4 State 70 4.5 Class 71 4.6 Session-Timeout 72 4.7 Extension-Id 73 4.8 Integrity-Check-Vector 74 4.9 Nonce 75 4.10 Timestamp 76 4.11 Session-Id 77 4.12 Vendor-Name 78 4.13 Firmware-Revision 79 4.14 Result-Code 80 4.15 Error-Code 81 4.16 Unrecognized-Command-Code 82 4.17 Reboot-Type 83 4.18 Reboot-Time 84 4.19 Failed-AVP-Code 85 4.20 User-Name 86 4.21 Receive-Window 87 4.22 Proxy-State 88 5.0 Protocol Definition 89 5.1 DIAMETER Bootstrap Message 90 5.1.1 State Machine 91 5.2 Keepalive Exchange 92 5.3 Unrecognized Command Support 93 5.4 The art of AVP Tagging 94 5.5 Using the Integrity-Check-Vector 95 5.6 DIAMETER Proxying 96 5.7 AVP Encryption with Shared Secrets 97 6.0 IANA Considerations 98 6.1 AVP Attributes 99 6.2 Command Code AVP Values 100 6.3 Extension Identifier Values 101 6.4 Result Code AVP Values 102 6.5 Integrity Check Vector Transform Values 103 6.7 AVP Header Bits 104 6.6 Reboot Type Values 105 7.0 References 106 8.0 Acknowledgements 107 9.0 Author's Address 108 10.0 Full Copyright Statement 109 Appendix A: Acknowledgment Timeouts 110 A.1 Calculating Adaptive Acknowledgment Timeout 111 A.2 Flow Control: Adjusting for Timeout 112 Appendix B: Examples of sequence numbering 113 B.1 Lock-step tunnel establishment 114 B.2 Multiple packets acknowledged 115 B.3 Lost packet with retransmission 117 1.0 Introduction 119 Since the RADIUS protocol is being used today for much more than 120 simple authentication and accounting of dial-up users (i.e. 121 authentication of WWW clients, etc), a more extensible protocol was 122 necessary which could support new services being deployed in the 123 internet and corporate networks. 125 RADIUS in itself is not an extensible protocol largely due to its 126 very limited command and attribute address space. In addition, the 127 RADIUS protocol assumes that there cannot be any unsolicited messages 128 from a server to a client. In order to support new services it is 129 imperative that a server be able to send unsolicited messages to 130 clients on a network, and this is a requirement for any DIAMETER 131 implementation. 133 This document describes the base DIAMETER protocol, which is used as 134 the transport for all DIAMETER extensions. This document in itself is 135 not complete and MUST be used with an accompanying applicability 136 extension document. 138 An example of such a document would be [7] that defines extensions to 139 the base protocol to support user authentication and [XXX] which 140 defines extensions to support accounting. 142 1.1 Copyright Statement 144 Copyright (C) The Internet Society 1999. All Rights Reserved. 146 1.2 Requirements language 148 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 149 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 150 described in [13]. 152 1.3 Terminology 154 AVP 156 The DIAMETER protocol consists of a header followed by objects. 157 Each object is encapsulated in a header known as an Attribute- 158 Value-Pair (AVP). 160 DIAMETER Device 162 A Diameter device is a client or server system that supports the 163 Diameter Base protocol and 0 or more extensions. 165 ICV 167 An Integrity Check Vector (ICV) is a hash of the packet with a 168 shared secret. 170 Session 172 The DIAMETER protocol is session based. When an authentication 173 request is initially transmitted, it includes a session identifier 174 that is used for the duration of the session. The Session- 175 Identifier AVP contains the identifier and must be globally 176 unique. Section 4.11 describes the semantics of a session 177 identifier. 179 1.4 Changes in Revision 8 181 The following changes were made to version 8 of this specification: 183 - Added text to clear up the Identifier field description. 185 - Clarified the text for all AVPs of type "time". 187 - Added a warning about all "time" AVPs in regards to the end of 188 life of a 32 bit time value. 190 - Added a placeholder in the Session-Id AVP description about the 191 protocol's interactions with NAT. 193 - Renamed the Initialization-Vector AVP to the Nonce AVP. This 194 makes sense since the IV was also used for authentication 195 purposes, and an IV is normally used for encryption purposes. 197 - Added a placeholder to the Nonce AVP section regarding the fact 198 that some crypto transforms have known attacks if there is no 199 random value in the plaintext early within a message. 201 - Clarification of the "Tag" and the "Mandatory" bits in the AVP 202 header. 204 - Added text specifying that the Session-Id AVP can only appear 205 once in a message. 207 - Clarified the conditions that cause a "Bad Packet" situation. 209 - Removed all support for TCP. 211 - Removed all references to the 'P' and 'E' bits, given that these 212 bit are defined in the proxy draft, and should not be specified in 213 the base protocol. 215 - The removal of the 'E' bit caused a shift in the bits, changing 216 the AVP header. 218 - A statement was added in the AVP Header definition that new AVP 219 flags may be added in the future and that an unrecognized flag 220 SHOULD be considered an error. 222 - Most AVPs flag field requirements have changed. 224 - Added descriptions for the 'A' bit, the Ns and Nr in the 225 DIAMETER header in section 2.1. 227 - Added section 2.1.1, which describes DIAMETER Acknowledgements. 229 - Added Command-Specific bits in the AVP Header in section 2.2. 230 This will eliminate the overlap problem found between the proxy 231 draft and the authent draft. 233 - Added section 3.0 (Reliable Transport) (from the Reliable 234 Transport document). 236 - Fixed up text in section 3.1 about updating the time in the 237 Timestamp AVP in retransmissions. 239 - Section 4.1 does not allow the Command Code AVP to be encrypted. 241 - Cleaned up some language in section 4.2, describing when a 242 Device-Reboot-Ind should be used. 244 - The Integrity-Check-Vector description now clearly states that 245 any AVPs found after it must be ignored. 247 - Added section 4.21, which is the Receive-Window AVP (from the 248 Reliable Transport document). 250 - Added section 4.22, which is the Proxy-State AVP. This AVP used 251 to be defined in the proxy extension, but has been deemed more 252 appropriate in the base protocol. 254 - The Timestamp AVP (section 4.10) was incorrect since it stated 255 that NTP time started on January 1st, 1970 instead of 1900. 257 - Added section 5.1.1 that describes the DIAMETER state machine. 259 - Fixed up a problem in the definition of Hop-by-Hop encryption 260 (section 4.6) since the original text defined using the two octet 261 Command Code instead of four octets. 263 - Added section 5.6, which provides a detailed description of how 264 DIAMETER server should proxy messages. 266 - Added IANA Considerations 268 - Removed all references to the DIAMETER Reliable Transport 269 document. 271 - Added appendix A and B (from the Reliable Transport document). 273 2.0 Protocol Overview 275 2.1 Header Format 277 The base DIAMETER protocol is run over UDP port 1812. Due to the fact 278 that both the client and server can receive unsolicited messages, it 279 is highly recommended that the source and destination field for all 280 DIAMETER messages be 1812. 282 When a request is received, the source and destination ports in the 283 reply are reversed. 285 A summary of the DIAMETER data format is shown below. The fields are 286 transmitted from left to right. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | RADIUS PCC |Flags|A|W| Ver | Packet Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Identifier | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Next Send (Ns) | Next Received (Nr) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | AVPs ... 298 +-+-+-+-+-+-+-+-+-+-+-+-+- 300 RADIUS PCC (Packet Compatibility Code) 302 The RADIUS PCC field is a one octet field which is used for 303 backward compatibility with RADIUS. In order to easily distinguish 304 DIAMETER packets from RADIUS a special value has been reserved and 305 allows an implementation to support both protocols concurrently 306 using the first octet in the header. The RADIUS PCC field MUST be 307 set as follows: 309 254 DIAMETER packet 311 PKT Flags 313 The Packet Flags field is five bits, and is used in order to 314 identify any options. This field MUST be initialized to zero. The 315 following flag may be set: 317 The 'W' bit (Window-Present) is set when the Next Send (Ns) and 318 Next Received (Nr) fields are present in the header. Should 319 DIAMETER be implemented over a reliable transport, the 'W' 320 should not be set. 322 The 'A' bit is set to indicate that the packet is an 323 acknowledgement only and does not contain a Command-Code AVP 324 following the header. Note that the Security AVPs MUST still be 325 present within an acknowledgment message. 327 Version 329 The Version field is three bits, and indicates the version number 330 which is associated with the packet received. This field MUST be 331 set to 1 to indicate DIAMETER Version 1. 333 Packet Length 335 The Packet Length field is two octets. It indicates the length of 336 the packet including the header fields. For messages received via 337 UDP, octets outside the range of the Length field should be 338 treated as padding and should be ignored upon receipt. 340 Identifier 342 The Identifier field is four octets, and aids in matching requests 343 and replies. The sender MUST ensure that the identifier in a 344 message is locally unique (to the sender) at any given time, and 345 MAY attempt to ensure that the number is unique across reboots. 346 The identifier is normally a monotonically increasing number, 347 whose start value was randomly generated. The random algorithm 348 used should ensure low probability of duplication. Given the size 349 of the Identifier field it is unlikely that 2^32 requests could be 350 outstanding at any given time. 352 Next Send 354 This field is present when the Window-Present bit is set in the 355 header flags. The Next Send (Ns) is copied from the send sequence 356 number state variable, Ss, at the time the message is transmitted. 357 Ss is incremented after copying if the message is not a ZLB ACK. 359 Next Received 361 This field is present when the Window-Present bit is set in the 362 header flags. Nr is copied from the receive sequence number state 363 variable, Sr, and indicates the sequence number, Ns, +1 of the 364 highest (modulo 2^16) in-sequence message received. See section 365 2.0 for more information. 367 AVPs 369 AVPs is a method of encapsulating information relevant to the 370 DIAMETER message. See section 2.2 for more information on AVPs. 372 2.1.1 ZLB Message Format 374 Zero Length Body messages are used to explicitly acknowledge one or 375 more DIAMETER message, and contain no additional Authentication, 376 Authorization or Accounting related AVPs. ZLB messages must contain 377 authentication AVPs, otherwise attacks could be mounted against 378 DIAMETER nodes. Consider the following example. 380 +------+ -----> +------+ 381 | | Ns=10 | | 382 | DIA1 +--------------------+ DIA3 | 383 | | Ns=40 | | 384 +------+ <----- +-+----+ 385 / 386 / 387 +------+ / Nr = 41 388 |Malici| / 389 | ous +-/ 390 | Node | 391 +------+ 393 In the above figure, DIA3 sends a stream of messages to DIA, with 394 sequence number 40 being the last message sent. A malicious user 395 could send an acknowledgement for Ns 40 to DIA3, effectively opening 396 up the window. Furthermore, if any of the messages from DIA3 were 397 lost in transit to DIA1, DIA3 would not attempt to retransmit them 398 since it received an acknowledgement. Therefore, it is necessary that 399 all acknowledgement messages also include the same authentication 400 related AVPs are normal DIAMETER messages. 402 The format of a ZLB message will be as follows: 404 ::= 405 406 407 { || 408 ::= 907 908 909 [] 910 [] 911 912 [ ] 913 { || 914 } 915 916 917 { || 918 ::= 1008 1009 1010 [] 1011 1012 [] 1013 1014 1015 1016 [] 1017 [] 1018 1019 1020 { || 1021 ::= 1062 1063 1064 [] 1065 1066 1067 { || 1068 1526 It is suggested that the monotonically increasing 32 bit value NOT 1527 start at zero upon reboot, but rather start at a random value. 1528 This will minimize the possibility of overlapping Session-Ids 1529 after a reboot. The optional value is implementation specific but 1530 may include a modem's device Id, a random value, etc. 1532 The session Id is created by the DIAMETER device initiating the 1533 session, which in most cases is done by the client. Note that a 1534 Session-Id can be used by more than one extension. 1536 NOTE: The fact that the Sender's IP Address is used in the 1537 construction of the Session-Id means that the introduction of 1538 Network Address Translation can cause two hosts to represent the 1539 same Session Identifier. This area needs to be investigated 1540 further to be able to support DIAMETER hosts on a private network. 1542 AVP Format 1544 0 1 2 3 1545 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 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | AVP Code | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | AVP Length | Reserved |T|V|H|M| 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Data ... 1552 +-+-+-+-+-+-+-+-+ 1554 AVP Code 1556 263 Session-Id 1558 AVP Length 1560 The length of this attribute MUST be at least 9. 1562 AVP Flags 1564 The 'M' bit MUST be set. The 'T' and 'H' bits MAY be set. The 1565 'V' bit MUST NOT be set. 1567 Data 1569 The Data field contains the session identifier assigned to the 1570 session. 1572 4.12 Vendor-Name 1574 Description 1576 The Vendor-Name attribute is used in order to inform a DIAMETER 1577 peer of the Vendor Name of the DIAMETER device. This MAY be used 1578 in order to know which vendor specific attributes may be sent to 1579 the peer. 1581 It is also envisioned that the combination of the Vendor-Name and 1582 the Firmware-Revision AVPs can provide very useful debugging 1583 information. 1585 AVP Format 1587 0 1 2 3 1588 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 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | AVP Code | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | AVP Length | Reserved |T|V|H|M| 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | String ... 1595 +-+-+-+-+-+-+-+-+ 1597 AVP Code 1599 266 Vendor-Name 1601 AVP Length 1603 The length of this attribute MUST be at least 9. 1605 AVP Flags 1607 The 'H' bits MAY be set. The 'T', 'V' and 'M' bits MUST NOT be 1608 set. 1610 String 1612 The String field contains the vendor name. 1614 4.13 Firmware-Revision 1616 Description 1618 The Firmware-Revision AVP is used to inform a DIAMETER peer of the 1619 firmware revision of the issuing device. 1621 For devices which do not have a firmware revision (general purpose 1622 computers running DIAMETER software modules, for instance), the 1623 revision of the DIAMETER software module may be reported instead. 1625 AVP Format 1627 0 1 2 3 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | AVP Code | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | AVP Length | Reserved |T|V|H|M| 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | Integer32 | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 AVP Code 1639 267 Firmware-Revision 1641 AVP Length 1643 The length of this attribute MUST be at least 12. 1645 AVP Flags 1647 The 'H' bits MAY be set. The 'T', 'V' and 'M' bits MUST NOT be 1648 set. 1650 Integer32 1652 The Integer32 field contains the firmware revision number of 1653 the issuing device. 1655 4.14 Result-Code 1657 Description 1659 The Result-Code AVP is used in order to indicate whether a 1660 particular command was completed successfully or whether an error 1661 occurred. The Result-Code AVP MUST be present in all DIAMETER 1662 messages of type -Request or -Answer. 1664 AVP Format 1666 0 1 2 3 1667 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 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | AVP Code | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | AVP Length | Reserved |T|V|H|M| 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Integer32 | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 AVP Code 1678 268 Result-Code 1680 AVP Length 1682 The length of this attribute MUST be 12. 1684 AVP Flags 1686 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1687 'V' bits MUST NOT be set. 1689 Integer32 1691 The Integer32 field contains the result code associated with 1692 the DIAMETER command. The following codes have been defined: 1694 DIAMETER_SUCCESS 0 1695 The Request was successfully completed. 1697 DIAMETER_FAILURE 1 1698 The Request was not successfully completed for an 1699 unspecified reason. A DIAMETER Message-Reject message 1700 returning this result SHOULD whenever possible also 1701 contain one or more Failed-AVP-Code AVPs indicating the 1702 attributes which caused the failure. 1704 DIAMETER_POOR_REQUEST 2 1705 The Request was poorly constructed. A DIAMETER Message- 1706 Reject message returning this result SHOULD whenever 1707 possible also contain one or more Failed-AVP-Code AVPs 1708 indicating the attributes which caused the failure. 1710 DIAMETER_INVALID_MAC 3 1711 The Request did not contain a valid Integrity-Check- 1712 Vector or Digital-Signature [11]. 1714 DIAMETER_UNKNOWN_SESSION_ID 4 1715 The Request contained an unknown Session-Id. 1717 DIAMETER_SEE_ERROR_CODE 5 1718 The Request failed. The message MUST also contain an 1719 Error-Code AVP which provides command-specific 1720 information on the failure. A DIAMETER Message-Reject- 1721 Ind message returning this result SHOULD whenever 1722 possible also contain one or more Failed-AVP-Code AVPs 1723 indicating the attributes which caused the failure. 1725 DIAMETER_COMMAND_UNSUPPORTED 6 1727 The Request contained a command code which the DIAMETER 1728 implementation does not recognize or does not support. 1729 The Message-Reject-Ind message MUST also contain an 1730 Unrecognized-Command-Code AVP which contains the Command 1731 Code value which was rejected. 1733 DIAMETER_ATTRIBUTE_UNSUPPORTED 8 1735 The Request contained an AVP with an AVP Code which the 1736 DIAMETER implementation does not recognize or does not 1737 support. An DIAMETER Message-Reject-Ind message returning 1738 this result MUST also contain one or more Failed-AVP-Code 1739 AVPs indicating the AVP Codes which caused the failure. 1741 4.15 Error-Code 1743 Description 1745 The Error-Code AVP contains the message specific error code, if 1746 any. This AVP only needs to be present if the Result-Code AVP is 1747 present with the DIAMETER_SEE_ERROR_CODE. 1749 Error-Code values and corresponding semantics are specific to the 1750 command to which the Error-Code is a response, and MUST therefore 1751 be documented as part of the description of that command. 1753 AVP Format 1755 0 1 2 3 1756 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 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | AVP Code | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | AVP Length | Reserved |T|V|H|M| 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Integer32 | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 AVP Code 1767 269 Error-Code 1769 AVP Length 1771 The length of this attribute MUST be 12. 1773 AVP Flags 1775 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1776 'V' bits MUST NOT be set. 1778 Integer32 1780 The Integer32 field contains the error code. 1782 4.16 Unrecognized-Command-Code 1784 Description 1786 The Unrecognized-Command-Code AVP contains the offending Command 1787 Code that resulted in sending the Message-Reject-Ind message. 1789 AVP Format 1791 0 1 2 3 1792 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 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | AVP Code | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | AVP Length | Reserved |T|V|H|M| 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | Integer32 | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 AVP Code 1803 270 Unrecognized-Command-Code 1805 AVP Length 1807 The length of this attribute MUST be 12. 1809 AVP Flags 1811 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1812 'V' bits MUST NOT be set. 1814 Integer32 1816 The Integer32 field contains the unrecognized command code that 1817 resulted in sending an Message-Reject-Ind message. 1819 4.17 Reboot-Type 1821 Description 1823 The Reboot-Type AVP MUST be present in the Device-Reboot- 1824 Indication message and contains an indication of the type of 1825 reboot. 1827 AVP Format 1829 0 1 2 3 1830 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 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | AVP Code | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | AVP Length | Reserved |T|V|H|M| 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Integer32 | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 AVP Code 1841 271 Reboot-Type 1843 AVP Length 1845 The length of this attribute MUST be 12. 1847 AVP Flags 1849 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1850 'V' bits MUST NOT be set. 1852 Integer32 1854 The Integer32 field contains the reboot type associated with 1855 the DRI command. The following value are currently defined: 1857 REBOOT_IMMINENT 1 1858 When the Reboot-Type AVP is set to this value it is an 1859 indication that the DIAMETER peer is about to reboot and 1860 should not be sent any additional DIAMETER messages 1861 besides the acknowledgement. 1863 REBOOTED 2 1864 When the Reboot-Type AVP is set to this value it is an 1865 indication that the DIAMETER peer has recently rebooted 1866 and is ready to accept new DIAMETER messages. 1868 CLEAN_REBOOT 3 1869 When the Reboot-Type AVP is set to this value the server 1870 is in the process of shutting down and MAY be available 1871 at some time in the future. 1873 4.18 Reboot-Time 1875 Description 1877 The Reboot-Time AVP MAY be present in the DRI and indicates the 1878 number of seconds before the issuer expects to be ready to receive 1879 new DIAMETER messages. This AVP MUST only be present when the 1880 Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by 1881 this AVP should be used as an estimate and is not a hard rule. 1883 AVP Format 1885 0 1 2 3 1886 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 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | AVP Code | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | AVP Length | Reserved |T|V|H|M| 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Integer32 | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 AVP Code 1897 272 Reboot-Time 1899 AVP Length 1901 The length of this attribute MUST be 12. 1903 AVP Flags 1905 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1906 'V' bits MUST NOT be set. 1908 Integer32 1910 The Integer32 field contains the expected amount of seconds 1911 before the issuer of the DRI expects to be receive to receive 1912 new DIAMETER messages. 1914 4.19 Failed-AVP-Code 1916 Description 1918 The Failed-AVP-Code AVP provides debugging information in cases 1919 where a request is rejected or not fully processed due to 1920 erroneous information in a specific AVP. The documentation of the 1921 Result-Code AVP and of the Message-Reject-Ind command provide 1922 information on the use of the Failed-AVP-Code AVP. This AVP has 1923 the following format: 1925 AVP Format 1927 0 1 2 3 1928 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 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | AVP Code | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | AVP Length | Reserved |T|V|H|M| 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | Data... 1935 +-+-+-+-+-+-+-+-+ 1937 AVP Code 1939 279 Failed-AVP-Code 1941 AVP Length 1943 The length of this attribute MUST be 12. 1945 AVP Flags 1947 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1948 'V' bits MUST NOT be set. 1950 Data 1952 The Data field contains the complete AVP that could not be 1953 processed successfully. Possible reasons for this are an 1954 improperly-constructed AVP, an unsupported or unrecognized AVP 1955 Code, or an invalid value. 1957 4.20 User-Name 1959 Description 1961 This attribute contains the User-Name in a format consistent with 1962 the NAI specification [8]. 1964 A summary of the User-Name AVP format is shown below. The fields 1965 are transmitted from left to right. 1967 AVP Format 1969 0 1 2 3 1970 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 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | AVP Code | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | AVP Length | Reserved |T|V|H|M| 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | String ... 1977 +-+-+-+-+-+-+-+-+ 1979 Type 1981 1 for User-Name. 1983 AVP Length 1985 The length of this AVP MUST be at least 9. 1987 AVP Flags 1989 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 1990 'V' bits MUST NOT be set. 1992 String 1994 The String field is one or more octets. All DIAMETER systems 1995 SHOULD support User-Name lengths of at least 63 octets. The 1996 format of the User-Name SHOULD follow the format defined in 1997 [8]. 1999 4.21 Receive-Window 2001 Description 2003 This AVP is used by a peer to inform its peer of its local receive 2004 window size. The size indicated is the number of packets that it 2005 is willing to accept before the window is full. 2007 A sending peer MUST stop sending new DIAMETER messages when this 2008 many messages are outstanding (sent but not yet acknowledged). 2010 If a peer does not issue this attribute, a receive window size of 2011 7 is assumed by its peer. 2013 This attribute is only valid in the Device-Reboot-Ind message. 2015 AVP Format 2017 0 1 2 3 2018 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 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | AVP Code | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | AVP Length | Reserved |T|V|H|M| 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Integer32 | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 AVP Code 2029 277 Receive-Window 2031 AVP Length 2033 The length of this attribute MUST be 12. 2035 AVP Flags 2037 The 'M' bit MUST be set. The 'H' bits MAY be set. The 'T' and 2038 'V' bits MUST NOT be set. 2040 Integer32 2042 This field contains the receive window size. 2044 4.22 Proxy-State 2046 Description 2048 The Proxy-State AVP is used by proxy servers when forwarding 2049 requests and contains opaque data that is used by the proxy to 2050 further process the response. Such data may include AVPs that are 2051 to be added to the response, information about the downstream 2052 peer, etc. 2054 A DIAMETER node that receives such an AVP in a request MUST return 2055 the identical AVP in the response. Furthermore, only one such AVP 2056 may be present in a message at any given time, so implmentations 2057 MUST ensure that they remove any Proxy-State AVPs before adding 2058 their own. 2060 If the Proxy-State AVP was removed from a request, the same AVP 2061 must be inserted in the corresponding response before forwarding 2062 the message to the downstream peer. 2064 The Proxy-State AVP's Address field is intended to be used by 2065 DIAMETER hosts in order to assist in determining if the AVP was 2066 locally generated. 2068 AVP Format 2070 A summary of the Proxy-State AVP format is shown below. The fields 2071 are transmitted from left to right. 2073 0 1 2 3 2074 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 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 | AVP Code | 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 | AVP Length | Reserved |T|V|H|M| 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 | Address | 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Data ... 2083 +-+-+-+-+-+-+-+-+ 2085 AVP Code 2087 33 for Proxy-State. 2089 AVP Length 2091 The length of this attribute MUST be at least 13. 2093 AVP Flags 2095 The 'M' bit MUST be set. The 'V', 'H' and 'T' bits MUST NOT be 2096 set. 2098 Address 2100 The Address field contains the IP Address of the system that 2101 created the Proxy-State AVP. This field is intended to assist 2102 hosts in determining if a Proxy-State AVP in a message was 2103 locally created. 2105 Data 2107 The Data field is one or more octets. The actual format of the 2108 information is site or application specific, and a robust 2109 implementation SHOULD support the field as undistinguished 2110 octets. 2112 5.0 Protocol Definition 2114 This section will describe how the base protocol works (or is at 2115 least an attempt to). 2117 5.1 DIAMETER Bootstrap Message 2119 DIAMETER provides a message that is used to indicate either an 2120 imminent reboot, or that a reboot has occurred. The DRI message MUST 2121 be sent to all known DIAMETER peers both previous to a reboot when 2122 possible as well as following a reboot. 2124 The Reboot-Type AVP is used to indicate the type of reboot associated 2125 with the DRI. When set to REBOOT_IMMINENT, all peers should be warned 2126 that any new DIAMETER requests sent to the issuer will probably not 2127 be received or processed. If a request MUST be sent it would be 2128 preferable to issue the request to an alternate peer if available. 2130 The message includes an optional Reboot-Time AVP that specifies an 2131 estimate of how long before the issuer is available to receive new 2132 DIAMETER messages. 2134 Upon reboot, the host MUST issue a DRI message with the Reboot-Type 2135 AVP set to REBOOTED. This is an indication that new DIAMETER messages 2136 may be sent to the transmitter of the DRI. 2138 Note that the Reboot-Time AVP is not required, and when present 2139 provides an estimate and should not be used as a hard value. In the 2140 case of a software implementation (server) running on a general 2141 purpose operating system, the Reboot-Time AVP will probably not be 2142 present since it is possible that the DIAMETER server has been 2143 stopped and it is not possible to know how long before (and if) it 2144 will be restarted. 2146 Upon receipt of this message the peer's Ss and Sr variables must be 2147 reset. It is possible for this message to be received outside the 2148 window (Ns and Nr set to zero) when it follows a reboot. 2150 The DIAMETER Reboot-Ind message does not require a reply. The message 2151 is acknowledged using DIAMETER's reliable transport. 2153 5.1.1 State Machine 2155 A DIAMETER node initially considers all known peers to be in the 2156 closed state, and should not process any DIAMETER message with the 2157 exception of acknowledgements and the DRI. Once the DIAMETER peer is 2158 set to the open state, any DIAMETER message may be accepted and 2159 processed. The following is a suggested state machine. 2161 State Event Action New State 2162 ----- ----- ------ --------- 2163 closed Local Open send DRI wait-ack1 2164 Request 2166 closed receive DRI send ACK wait-ack2 2167 send DRI 2169 closed receive invalid cleanup closed 2170 DRI 2172 wait-ack1 receive ACK accept Incoming wait-ack1 2173 Messages 2175 wait-ack1 receive DRI send ACK open 2176 Accept Incoming 2177 Messages 2179 wait-ack2 received ACK Accept Incoming open 2180 Messages 2182 open receive DRI cleanup closed 2184 open receive DWI send ACK open 2186 open receive other send ACK open 2187 messages 2189 5.2 Keepalive Exchange 2191 DIAMETER uses the Device-Watchdog-Ind message as a keepalive 2192 mechanism. DIAMETER entities that need to ensure that connectivity 2193 with a peer is not lost may use this mechanism. 2195 A DIAMETER Client can use this mechanism to ensure that failover to 2196 an alternate server occurs even without any AAA traffic. DIAMETER 2197 Servers use this mechanism to identify when a particular client is no 2198 longer reachable. Redundant DIAMETER Servers can use this mechanism 2199 to identify when the primary server is no longer available. Proxy 2200 Servers can equally use this method to identify when a particular 2201 domain's server is no longer reachable. 2203 The DIAMETER Device-Watchdog-Ind message does not require a reply. 2204 The message is acknowledged using DIAMETER's reliable transport. 2206 5.3 Unrecognized Command Support 2208 The DIAMETER protocol provides a message that is used to inform a 2209 peer that a DIAMETER message was received with an unrecognized 2210 command. The following provides a DIAMETER message that is sent to a 2211 peer: 2213 ::= 2214 2215 2216 [] 2217 2218 2219 { || 2220 ::= 2226 2227 2228 2229 [] 2230 2231 2232 { || 2233 ::= 2280 2281 [] 2282 2283 2284 2286 Any AVPs in a message that is not succeeded by the Integrity-Check- 2287 Vector AVP MUST be ignored. 2289 5.6 DIAMETER Proxying 2291 This section will describe how DIAMETER server implementations can 2292 proxy requests to upstream servers. Consider the following diagram, 2293 which depicts DIA1 sending a request to DIA2. Typically, the request 2294 will contain the User-Name AVP (section 4.20), which conforms to the 2295 format defined in the NAI specification [8]. Server DIA2 normally 2296 will extract that domain name portion of the NAI to determine if the 2297 request can be locally processed, or if the request must be proxied 2298 to an upstream server (in this case DIA3). 2300 (Request) (Request) 2301 (User-Name = joe@abc.com) (Proxy-State=1) 2302 +------+ ------> +------+ ------> +------+ 2303 | | | | | | 2304 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 2305 | | | | | | 2306 +------+ <------ +------+ <------ +------+ 2307 (Response) (Response) 2308 (Proxy-State=1) 2309 mno.net xyz.com abc.com 2311 Prior to forwarding the request, DIA2 must establish some state 2312 information in order to be able to forward the corresponding response 2313 from DIA3 to DIA1. There are two methods of doing so: 2315 1. DIA2 can maintain state information locally, and using the 2316 session-Id and possible the Identifier in the header, can match 2317 the request with the response. The state information would contain 2318 sufficient information for it to know where the response should be 2319 forwarded. Additionally, it may be necessary for DIA2 to attach 2320 AVPs to the response that were created when the request was 2321 received. These AVPs could be kept in the state table. 2323 2. DIA2 can attach a Proxy-State AVP (section 4.22), which may 2324 contain any information, including information regarding the 2325 source of the request, additional AVPs that must be attached to 2326 the response, etc. Upon receipt of the response, DIA2 must find 2327 the Proxy-State AVP, determine if the AVP was created locally, and 2328 if so use the information included within the AVP. If AVPs were 2329 found within the Proxy-State AVP, they could easily be attached to 2330 the response. Finally, the Proxy-State AVP is removed from the 2331 response before being forwarded to DIA1. 2333 Althought both methods work, the latter is much simpler as it 2334 reduces the amount of state information each proxy must maintain 2335 on a per request basis. 2337 When DIA3 receives a request that includes the Proxy-State AVP, it 2338 MUST include the same AVP in the corresponding response. 2339 Furthermore, should DIA3 have to proxy the request to another 2340 upstream server, it would have to replace the existing Proxy-State 2341 AVP with its own. It must, however, be able to replace the Proxy- 2342 State AVP in the corresponding response back to the one it had 2343 received in the request. One suggested implementation is to 2344 include the Proxy-State AVPs in a newly created Proxy-State AVP, 2345 allowing a server to easily replace the Proxy-State AVPs in the 2346 responses. 2348 5.7 AVP Encryption with Shared Secrets 2350 This method of encrypting AVP data is the simplest to use and MUST be 2351 supported by all DIAMETER implementations. However, local policy MAY 2352 determine that the use of this mechanism is not permitted. 2354 The 'H' bit MUST only be set if a shared secret exists between both 2355 DIAMETER peers. If the 'H' bit is set in any DIAMETER AVP, the Nonce 2356 AVP MUST be present prior to the first encrypted AVP. 2358 The length of the AVP value to be encrypted is first encoded in the 2359 following Subformat, which is included in the AVP's data field. 2361 0 1 2 3 2362 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 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | Length of ClearText Data | ClearText Data ... 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | Padding ... 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 Length 2371 The Length field contains the length of the decrypted data. 2373 ClearText Data 2375 Data of AVP that is to be obscured. 2377 Padding 2379 Random additional octets used to obscure length of the ClearText 2380 Data. 2382 The resulting subformat MAY be padded to a multiple of 16 octets in 2383 length. For example, if the ClearText Data to be obscured is a string 2384 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 2385 octets of padding would be applied. Padding does NOT alter the value 2386 placed in the Length of the ClearText Data, only the length of the 2387 AVP itself. 2389 Next, An MD5 hash is performed on the concatenation of: 2391 - the four octet Command Code of the AVP 2392 - the shared authentication secret 2393 - an arbitrary length random vector 2395 The value of the random vector used in this hash is passed in the 2396 Data field of a Nonce AVP. This Nonce AVP must appear in the message 2397 before any hidden AVPs. The same Nonce may be used for more than one 2398 hidden AVP in the same message. If a different Nonce is used for the 2399 hiding of subsequent AVPs then a new Nonce AVP must be placed before 2400 the first AVP to which it applies. 2402 The MD5 hash value is then XORed with the first 16 octet or less 2403 segment of the AVP Subformat and placed in the Data field of the AVP. 2404 If the AVP Subformat is less than 16 octets, the Subformat is 2405 transformed as if the Value field had been padded to 16 octets before 2406 the XOR, but only the actual octets present in the Subformat are 2407 modified, and the length of the AVP is not altered. 2409 If the Subformat is longer than 16 octets, a second one-way MD5 hash 2410 is calculated over a stream of octets consisting of the shared secret 2411 followed by the result of the first XOR. That hash is XORed with the 2412 second 16 octet or less segment of the Subformat and placed in the 2413 corresponding octets of the Data field of the AVP. 2415 If necessary, this operation is repeated, with each XOR result being 2416 used along with the shared secret to generate the next hash to XOR 2417 the next segment of the value with. This technique results in the 2418 content of the AVP being obscured, although the length of the AVP is 2419 still known. 2421 On receipt, the Nonce is taken from the last Nonce AVP encountered in 2422 the message prior to the AVP to be decrypted. The above process is 2423 then reversed to yield the original value. For more details on this 2424 hiding method, consult RFC2138 [1]. 2426 Please note that in the case where the DIAMETER message needs to be 2427 processed by an intermediate non-trusted DIAMETER server (also known 2428 as a proxy server, depicted as DIA2 in the figure below) the AVP 2429 needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 2430 using Shared-Secret-2. 2432 (Shared-Secret-1) (Shared-Secret-2) 2433 +------+ -----> +------+ ------> +------+ 2434 | | | | | | 2435 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 2436 | | | | | | 2437 +------+ +------+ +------+ 2439 Unfortunately in this case the non-trusted server DIA2 has access to 2440 sensitive information (such as a password). 2442 6.0 IANA Considerations 2444 This document defines a number of "magic" numbers to be maintained by 2445 the IANA. This section explains the criteria to be used by the IANA 2446 to assign additional numbers in each of these lists. The following 2447 subsections describe the assignment policy for the namespaces defined 2448 elsewhere in this document. 2450 6.1 AVP Attributes 2452 As defined in Section 4.0, AVPs contain vendor ID, Attribute and 2453 Value fields. For vendor ID value of 0, IANA will maintain a registry 2454 of assigned Attributes and in some case also values. Attribute 0-254 2455 are assigned from the RADIUS protocol [1], whose attributes are also 2456 maintained through IANA. Attributes 256-280 are assigned within this 2457 document in section 4.0. The remaining values are available for 2458 assignment through IETF Consensus [12]. 2460 6.2 Command Code AVP Values 2462 As defined in Section 4.1, the Command Code AVPs (AVP Code 256) have 2463 an associated value maintained by IANA. Values 0-255 are reserved for 2464 backward RADIUS compatibility, and values 256-258 are defined in this 2465 specification. The remaining values are available for assignment via 2466 IETF Consensus [12]. 2468 6.3 Extension Identifier Values 2470 as defined in Section 4.7, the Extension Identifier is used to 2471 identify a specific DIAMETER Extension. All values, other than zero 2472 (0) are available for assignment via IETF Consensus [12]. 2474 6.4 Result Code AVP Values 2476 As defined in Section 4.14, the Result Code AVP (AVP Code 268) 2477 defines the values 0-8. All remaining values are available for 2478 assignment via IETF Consensus [12]. 2480 6.5 Integrity Check Vector Transform Values 2482 Section 4.8 defines the Integrity-Check-Vector AVP (AVP Code 259) 2483 which contains a field called the Transform. This document reserves 2484 the value 1. All remaining values are available for assignment via 2485 IETF Consensus [12]. 2487 6.6 Reboot Type Values 2489 Section 4.17 defines the Reboot-Type AVP (AVP Code 271), which is 2490 used to inform the peer of the cause for the reboot. This document 2491 defines the values 1-3. All remaining values are available for 2492 assignment via IETF Consensus [12]. 2494 6.7 AVP Header Bits 2496 There are six remaining reserved bits in the AVP header. Additional 2497 bits should only be assigned via a Standards Action [12]. 2499 7.0 References 2501 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 2502 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, 2503 October 1994. 2504 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 2505 [4] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 2506 RFC 1321, April 1992. 2507 [5] Kaufman, Perlman, Speciner, "Network Security: Private 2508 Communications in a Public World", Prentice Hall, 2509 March 1995, ISBN 0-13-061466-1. 2510 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 2511 Authentication", RFC 2104, January 1997. 2512 [7] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 2513 draft-calhoun-diameter-authen-06.txt, Work in Progress, 2514 August 1999. 2515 [8] Aboba, Beadles "The Network Access Identifier." RFC 2486. 2516 January 1999. 2517 [9] Calhoun, Zorn, Pan, "DIAMETER Framework", 2518 draft-calhoun-diameter-framework-02.txt, Work in Progress, 2519 December 1998. 2520 [10] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for 2521 Tunnel Protocol Support", 2522 draft-ietf-radius-tunnel-auth-05.txt, Work in Progress, 2523 April 1998. 2524 [11] Calhoun, Bulley, "DIAMETER Proxy Extension", 2525 draft-calhoun-diameter-proxy-02.txt, Work in Progress, 2526 August 1999. 2527 [12] Narten, Alvestrand,"Guidelines for Writing an IANA 2528 Considerations Section in RFCs", BCP 26, RFC 2434, 2529 October 1998 2530 [13] S. Bradner, "Key words for use in RFCs to Indicate 2531 Requirement Levels", BCP 14, RFC 2119, March 1997. 2533 8.0 Acknowledgements 2535 The Authors would like to acknowledge the following people for their 2536 contribution in the development of the DIAMETER protocol: 2538 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2539 Ignacio Goyret, Nancy Greene, Erik Guttman, Peter Heitman, Paul 2540 Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, 2541 Nenad Trifunovic, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and 2542 Glen Zorn 2544 9.0 Author's Address 2546 Questions about this memo can be directed to: 2548 Pat R. Calhoun 2549 Network and Security Research Center, Sun Labs 2550 Sun Microsystems, Inc. 2551 15 Network Circle 2552 Menlo Park, California, 94025 2553 USA 2555 Phone: 1-650-786-7733 2556 Fax: 1-650-786-6445 2557 E-mail: pcalhoun@eng.sun.com 2559 Allan C. Rubens 2560 Ascend Communications 2561 1678 Broadway 2562 Ann Arbor, MI 48105-1812 2563 USA 2565 Phone: 1-734-761-6025 2566 E-Mail: acr@del.com 2568 10.0 Full Copyright Statement 2570 Copyright (C) The Internet Society (1999). All Rights Reserved. 2572 This document and translations of it may be copied and furnished 2573 to others, and derivative works that comment on or otherwise 2574 explain it or assist in its implmentation may be prepared, copied, 2575 published and distributed, in whole or in part, without 2576 restriction of any kind, provided that the above copyright notice 2577 and this paragraph are included on all such copies and derivative 2578 works. However, this docu- ment itself may not be modified in any 2579 way, such as by removing the copyright notice or references to the 2580 Internet Society or other Inter- net organizations, except as needed 2581 for the purpose of developing Internet standards in which case 2582 the procedures for copyrights defined in the Internet Standards 2583 process must be followed, or as required to translate it into 2584 languages other than English. The limited permis- sions granted 2585 above are perpetual and will not be revoked by the Internet 2586 Society or its successors or assigns. This document and the 2587 information contained herein is provided on an "AS IS" basis and 2588 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 2589 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2590 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 2591 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2592 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2594 Appendix A: Acknowledgment Timeouts 2596 DIAMETER uses sliding windows and timeouts to provide flow-control 2597 across the underlying medium and to perform efficient data buffering 2598 to keep two DIAMETER peers' receive window full without causing 2599 receive buffer overflow. DIAMETER requires that a timeout be used to 2600 recover from dropped packets. 2602 When the timeout for a peer expires, the previously transmitted 2603 message with Ns value equal to the highest in-sequence value of Nr 2604 received from the peer is retransmitted. The receiving peer does not 2605 advance its value for the receive sequence number state, Sr, until it 2606 receives a message with Ns equal to its current value of Sr. 2608 This rule assures that all subsequent acknowledgements to this peer 2609 will contain an Nr value equal to the Ns value of the first missing 2610 message until a message with the missing Ns value is received. 2612 The exact implementation of the acknowledgment timeout is vendor- 2613 specific. It is suggested that an adaptive timeout be implemented 2614 with backoff for flow control. The timeout mechanism proposed here 2615 has the following properties: 2617 Independent timeouts for each peer. A device will have to 2618 maintain and calculate timeouts for every active peer. 2620 An administrator-adjustable maximum timeout, MaxTimeOut, unique to 2621 each device. 2623 An adaptive timeout mechanism that compensates for changing 2624 throughput. To reduce packet processing overhead, vendors may 2625 choose not to recompute the adaptive timeout for every received 2626 acknowledgment. The result of this overhead reduction is that the 2627 timeout will not respond as quickly to rapid network changes. 2629 Timer backoff on timeout to reduce congestion. The backed-off 2630 timer value is limited by the configurable maximum timeout value. 2631 Timer backoff is done every time an acknowledgment timeout occurs. 2633 In general, this mechanism has the desirable behavior of quickly 2634 backing off upon a timeout and of slowly decreasing the timeout value 2635 as packets are delivered without errors. 2637 A.1 Calculating Adaptive Acknowledgment Timeout 2639 We must decide how much time to allow for acknowledgments to return. 2640 If the timeout is set too high, we may wait an unnecessarily long 2641 time for dropped packets. If the timeout is too short, we may time 2642 out just before the acknowledgment arrives. The acknowledgment 2643 timeout should also be reasonable and responsive to changing network 2644 conditions. 2646 The suggested adaptive algorithm detailed below is based on the TCP 2647 1989 implementation and is explained in Richard Steven's book TCP/IP 2648 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 2649 calculation, and 'n-1' refers to values from the last calculation. 2651 DIFF[n] = SAMPLE[n] - RTT[n-1] 2652 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 2653 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 2654 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2656 DIFF represents the error between the last estimated round-trip 2657 time and the measured time. DIFF is calculated on each iteration. 2659 DEV is the estimated mean deviation. This approximates the 2660 standard deviation. DEV is calculated on each iteration and 2661 stored for use in the next iteration. Initially, it is set to 0. 2663 RTT is the estimated round-trip time of an average packet. RTT is 2664 calculated on each iteration and stored for use in the next 2665 iteration. Initially, it is set to PPD. 2667 ATO is the adaptive timeout for the next transmitted packet. ATO 2668 is calculated on each iteration. Its value is limited, by the MIN 2669 function, to be a maximum of the configured MaxTimeOut value. 2671 Alpha is the gain for the round trip estimate error and is 2672 typically 1/8 (0.125). 2674 Beta is the gain for the deviation and is typically 1/4 (0.250). 2676 Chi is the gain for the timeout and is typically set to 4. 2678 To eliminate division operations for fractional gain elements, the 2679 entire set of equations can be scaled. With the suggested gain 2680 constants, they should be scaled by 8 to eliminate all division. To 2681 simplify calculations, all gain values are kept to powers of two so 2682 that shift operations can be used in place of multiplication or 2683 division. The above calculations are carried out each time an 2684 acknowledgment is received for a packet that was not retransmitted 2685 (no timeout occured). 2687 A.2 Flow Control: Adjusting for Timeout 2689 This section describes how the calculation of ATO is modified in the 2690 case where a timeout does occur. When a timeout occurs, the timeout 2691 value should be adjusted rapidly upward. To compensate for shifting 2692 internetwork time delays, a strategy must be employed to increase the 2693 timeout when it expires. A simple formula called Karn's Algorithm is 2694 used in TCP implementations and may be used in implementing the 2695 backoff timers for the DIAMETER peers. Notice that in addition to 2696 increasing the timeout, we also shrink the size of the window as 2697 described in the next section. 2699 Karn's timer backoff algorithm, as used in TCP, is: 2701 NewTIMEOUT = delta * TIMEOUT 2703 Adapted to our timeout calculations, for an interval in which a 2704 timeout occurs, the new timeout interval ATO is calculated as: 2706 RTT[n] = delta * RTT[n-1] 2707 DEV[n] = DEV[n-1] 2708 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2710 In this modified calculation of ATO, only the two values that 2711 contribute to ATO and that are stored for the next iteration are 2712 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 2713 not carried forward and is not used in this scenario. A value of 2 2714 for Delta, the timeout gain factor for RTT, is suggested. 2716 Appendix B: Examples of sequence numbering 2718 This appendix uses several common scenarios to illustrate how 2719 sequence number state progresses and is interpreted. 2721 B.1 Lock-step session establishment 2723 In this example, a DIAMETER host establishes communication with a 2724 peer, with the exchange involving each side alternating in the 2725 sending of messages. This example is contrived, in that the final 2726 acknowledgement typically would be included in the Device-Watchdog- 2727 Ind message. 2729 DIAMETER Host A DIAMETER Host B 2730 -> Device-Reboot-Ind 2731 Nr: 0, Ns: 0 2733 (ZLB) <- 2734 Nr: 1, Ns: 0 2736 -> Device-Watchdog-Ind 2737 Nr: 0, Ns: 1 2739 (delay) 2741 (ZLB) <- 2742 Nr: 2, Ns: 0 2744 B.2 Multiple packets acknowledged 2746 This example shows a flow of packets from DIAMETER Host B to Host A, 2747 with Host A having no traffic of its own. Host A is waiting 1/4 of 2748 its timeout interval, and then acknowledging all packets seen since 2749 the last interval. 2751 DIAMETER Host A DIAMETER Host B 2752 (previous packet flow precedes this) 2754 -> (ZLB) 2755 Nr: 7000, Ns: 1000 2756 (non-ZLB) <- 2757 Nr: 1000, Ns: 7000 2758 (non-ZLB) <- 2759 Nr: 1000, Ns: 7001 2760 (non-ZLB) <- 2761 Nr: 1000, Ns: 7002 2763 (Host A's timer indicates it should acknowledge pending 2764 traffic) 2766 -> (ZLB) 2767 Nr: 7003, Ns: 1000 2769 B.3 Lost packet with retransmission 2771 Host A attempts to communicate with Host B. The Device-Reboot-Ind 2772 sent from B to A is lost and must be retransmitted by Host B. 2774 DIAMETER Host A DIAMETER Host B 2775 -> Device-Reboot-Ind 2776 Nr: 0, Ns: 0 2778 (packet lost) Device-Reboot-Ind <- 2779 Nr: 1, Ns: 0 2781 (pause; Host A's timer started first, so fires first) 2783 -> Device-Reboot-Ind 2784 Nr: 0, Ns: 0 2786 (Host B realizes it has already seen this packet) 2787 (Host B might use this as a cue to retransmit, as in this 2788 example) 2790 Device-Reboot-Ind <- 2791 Nr: 1, Ns: 0 2792 -> Device-Watchdog-Ind 2793 Nr: 1, Ns: 1 2795 (delay) 2797 (ZLB) <- 2798 Nr: 2, Ns: 1