Network Working Group V. Fajardo Internet-Draft Toshiba America Research Inc. Intended status: Informational October 14, 2006 Expires: April 17, 2007 Diameter Specification Errata and Issues draft-fajardo-dime-diameter-errata-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document is a compilation the defects found in the DIAMETER protocol specification based on interoperability event(s) and general implementation discussions. This document is meant to be a companion document to RFC3588 and provides a historical reference to the changes that will incorporated in RFC3588's BIS document. Fajardo Expires April 17, 2007 [Page 1] Internet-Draft Diameter Specification Errata and Issues October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Corrections to RFC3588 . . . . . . . . . . . . . . . . . . . . 4 2.1. Usage of the Error bit and Error Answer Message . . . . . 4 2.1.1. Problem Description . . . . . . . . . . . . . . . . . 4 2.1.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 5 2.1.3. Solution Description . . . . . . . . . . . . . . . . . 6 2.2. Usage of E-bit in the CEA message . . . . . . . . . . . . 6 2.2.1. Problem Description . . . . . . . . . . . . . . . . . 6 2.2.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Solution Description . . . . . . . . . . . . . . . . . 7 2.3. Inconsistent Result-code Error classification . . . . . . 7 2.3.1. Problem Description . . . . . . . . . . . . . . . . . 7 2.3.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. Solution Description . . . . . . . . . . . . . . . . . 10 2.4. Composing Failed AVP for Invalid AVP length . . . . . . . 11 2.4.1. Problem Description . . . . . . . . . . . . . . . . . 11 2.4.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 11 2.4.3. Solution Description . . . . . . . . . . . . . . . . . 13 2.5. Capabilities Exchange in the Open State . . . . . . . . . 13 2.5.1. Problem Description . . . . . . . . . . . . . . . . . 13 2.5.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 13 2.5.3. Solution Description . . . . . . . . . . . . . . . . . 14 2.6. ABNF for Vendor-Specific-Application-Id allows multiple Vendor-Ids . . . . . . . . . . . . . . . . . . . 14 2.6.1. Problem Description . . . . . . . . . . . . . . . . . 14 2.6.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 14 2.6.3. Solution Description . . . . . . . . . . . . . . . . . 14 2.7. Definition URI Schemes . . . . . . . . . . . . . . . . . . 15 2.7.1. Problem Description . . . . . . . . . . . . . . . . . 15 2.7.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 15 2.7.3. Solution Description . . . . . . . . . . . . . . . . . 15 2.8. Application ID to be used by ASR/ASA, RAR/RAA, STR/STA . . 15 2.8.1. Problem Description . . . . . . . . . . . . . . . . . 15 2.8.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 15 2.8.3. Solution Description . . . . . . . . . . . . . . . . . 16 2.9. Removal of Trailing [fixed*] avp in Command Code ABNF specification . . . . . . . . . . . . . . . . . . . . . . 16 2.9.1. Problem Description . . . . . . . . . . . . . . . . . 16 2.9.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 16 2.9.3. Solution Description . . . . . . . . . . . . . . . . . 16 2.10. Mapping between Disconnect-Cause AVP and the Reconnect Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.10.1. Problem Description . . . . . . . . . . . . . . . . . 16 2.10.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 17 2.10.3. Solution Description . . . . . . . . . . . . . . . . . 19 2.11. Advertising of Relay application-id and the Election Fajardo Expires April 17, 2007 [Page 2] Internet-Draft Diameter Specification Errata and Issues October 2006 Process . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.11.1. Problem Description . . . . . . . . . . . . . . . . . 19 2.11.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 19 2.11.3. Solution Description . . . . . . . . . . . . . . . . . 19 2.12. Duplication of Application ID in the Header and Application Id AVPs . . . . . . . . . . . . . . . . . . . 19 2.12.1. Problem Description . . . . . . . . . . . . . . . . . 20 2.12.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 20 2.12.3. Solution Description . . . . . . . . . . . . . . . . . 23 3. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1. Predictive Loop Avoidance . . . . . . . . . . . . . . . . 23 3.1.1. Problem Description . . . . . . . . . . . . . . . . . 23 3.1.2. Text Changes . . . . . . . . . . . . . . . . . . . . . 24 3.1.3. Solution Description . . . . . . . . . . . . . . . . . 24 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. Normative References . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Fajardo Expires April 17, 2007 [Page 3] Internet-Draft Diameter Specification Errata and Issues October 2006 1. Introduction This document provides a compilation of the defects found in DIAMETER protocol specification RFC3588 [1]. It is meant to be a companion document to RFC3588 [1] to aid in the eventual publication of RFC3588's BIS document. It is also meant to assist implementations in clarifying errors in the original DIAMETER protocol specification. The issues enumerated in this document are deltas to text found in RFC3588 [1]. The issues are classified either as a corrections or optimization. Issues classified under corrections maybe technical or editorial whereas those issues classified as optimizations maybe deemed as additional features. Note that these features requires carefully scrutiny before inclusion. It must meet the strict criteria of backward compatibility, simplicity and zero disruption to interoperability with existing implementations. The issues detailed within this document have the following format: o The problem description o Text changes or additions o A description of the solution In reading this document one must use care to assure that an enumerated issues is not updated in any subsequent issues(s) within the document. Each section should be applied in sequence to the original RFC3588 [1] since this document is a historical record of the sequential changes that have been found necessary during inter-op events and through implementation discussion. 2. Corrections to RFC3588 2.1. Usage of the Error bit and Error Answer Message 2.1.1. Problem Description The issue is comprised of an editorial problem in Sec 7.1.3 of [1] and the optional use of the error answer grammar for permanent errors as well as protocol errors. Regarding the use of the E-bit for permanent errors, in certain situations it is not be possible to completely decode a request, e.g. invalid AVP length for an AVP which is of type OctetString. In such a case, it may not be possible to generate an answer message based on the original command's answer grammar. Fajardo Expires April 17, 2007 [Page 4] Internet-Draft Diameter Specification Errata and Issues October 2006 2.1.2. Text Changes ------------------------ Original Text: Sec 7.1.3 ------------------------ Errors that fall within the Protocol Error category SHOULD be treated on a per-hop basis, and Diameter proxies MAY attempt to correct the error, if it is possible. Note that these and only these errors MUST only be used in answer messages whose 'E' bit is set. ------------------------------------ Proposed Changes, Sec 7.1.3, Ver-00: ------------------------------------ Errors that fall within the Protocol Error category SHOULD be treated on a per-hop basis, and Diameter proxies MAY attempt to correct the error, if it is possible. Note that these errors MUST be used in answer messages whose 'E' bit is set. ------------------------ Original Text: Sec 7.1.4 ------------------------ Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but MAY be able to satisfy the request in the future. ------------------------------------ Proposed Changes, Sec 7.1.4, Ver-00: ------------------------------------ Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but MAY be able to satisfy the request in the future. Note that these errors MUST be used in answer messages whose 'E' bit not is set. ------------------------ Original Text: Sec 7.1.5 ------------------------ Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again. Fajardo Expires April 17, 2007 [Page 5] Internet-Draft Diameter Specification Errata and Issues October 2006 ------------------------------------ Proposed Changes, Sec 7.1.5, Ver-00: ------------------------------------ Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again. Note that these errors SHOULD be used in answer messages whose 'E' bit is not set. Answer messages with E-bit set and complying to the grammar described in 7.2 MAY be used for permanent errors may be used as well. 2.1.3. Solution Description The proposal adds text to each error class to clarify whether the error class should use the E-bit and Error answer grammar. It allows for optional use of the E-bit for permanent errors as well. 2.2. Usage of E-bit in the CEA message 2.2.1. Problem Description An issue came up where certain implementations are not setting the E-bit in the CEA when errors in the CER have been detected. The rationale is that as long as the CER can be completely understood, and the CEA is used to terminate the transport connection with a non- successful Result-Code, it doesn't constitute a protocol error, but rather an expected event. A good example is the DIAMETER_UNKNOWN_PEER Result-Code, which shouldn't require the E-bit to be set because the CER/CEA sequence is well-defined and not a protocol error per se. Sending a CEA which this Result-Code is optional, but if an implementation does so, it also has to set the E-bit, which doesn't make much sense. 2.2.2. Text Changes Fajardo Expires April 17, 2007 [Page 6] Internet-Draft Diameter Specification Errata and Issues October 2006 ----------------------------------------------------- Proposed Removal of Original Text, Sec 7.1.3, Ver-00: ----------------------------------------------------- DIAMETER_UNKNOWN_PEER 3010 A CER was received from an unknown peer. -------------------------------------------- Proposed Addition of Text, Sec 7.1.5, Ver-00: -------------------------------------------- DIAMETER_UNKNOWN_PEER 5018 A CER was received from an unknown peer. 2.2.3. Solution Description The proposal re-classifies the DIAMETER_UNKNOWN_PEER result code from a protocol error to a permanent error class. Note that the renumbering results in addition of new values in the affected protocol classes and does not re-use any previous values that may have been deprecated. This is an attempt to aid in backward compatibility but this may change in future revisions of this document. 2.3. Inconsistent Result-code Error classification 2.3.1. Problem Description The following are problem descriptions for error codes that are either duplicated or classified incorrectly. o In RFC3588 [1] there is two(2) separate errors for invalid AVP flags, DIAMETER_INVALID_AVP_BITS and DIAMETER_INVALID_AVP_BIT_COMBO. It is unclear from the current text what the difference are between these errors, and more importantly they have different error classes. Since both errors imply similar situation where the received message cannot be completely/correctly decoded, it is more appropriate to simply use one error code under the protocol error class. o DIAMETER_INVALID_BIT_IN_HEADER and DIAMETER_INVALID_MESSAGE_LENGTH should be considered protocol errors since these error scenarios is caused by a received message that cannot be completely/ correctly decoded. Therefore, it is more appropriate to re- classify these errors. Fajardo Expires April 17, 2007 [Page 7] Internet-Draft Diameter Specification Errata and Issues October 2006 o DIAMETER_COMMAND_UNSUPPORTED and DIAMETER_INVALID_AVP_BITS seem to be related with end-to-end behavior. It is unclear what type of action a relay agent should take when receiving an answer with this error code. It is more appropriate to re-classify these error codes to the permanent failures class. 2.3.2. Text Changes --------------------------------------------------------- *** Re-Classification of DIAMETER_COMMAND_UNSUPPORTED *** --------------------------------------------------------- ----------------------------------------------------- Proposed Removal of Original Text, Sec 7.1.3, Ver-00: ----------------------------------------------------- DIAMETER_COMMAND_UNSUPPORTED 3001 The Request contained a Command-Code that the receiver did not recognize or support. This MUST be used when a Diameter node receives an experimental command that it does not understand. -------------------------------------------- Proposed Addition of Text, Sec 7.1.5, Ver-00: -------------------------------------------- DIAMETER_COMMAND_UNSUPPORTED 5019 The Request contained a Command-Code that the receiver did not recognize or support. This MUST be used when a Diameter node receives an experimental command that it does not understand. ------------------------------------------------------ *** Re-Classification of DIAMETER_INVALID_HDR_BITS *** ------------------------------------------------------ ----------------------------------------------------- Proposed Removal of Original Text, Sec 7.1.3, Ver-00: ----------------------------------------------------- DIAMETER_INVALID_HDR_BITS 3008 A request was received whose bits in the Diameter header were either set to an invalid combination, or to a value that is inconsistent with the command code's definition. -------------------------------------------- Proposed Addition of Text, Sec 7.1.5, Ver-00: -------------------------------------------- Fajardo Expires April 17, 2007 [Page 8] Internet-Draft Diameter Specification Errata and Issues October 2006 DIAMETER_INVALID_HDR_BITS 5020 A request was received whose bits in the Diameter header were either set to an invalid combination, or to a value that is inconsistent with the command code's definition. ------------------------------------------------------ *** Re-Classification of DIAMETER_INVALID_AVP_BITS *** ------------------------------------------------------ ----------------------------------------------------- Proposed Removal of Original Text, Sec 7.1.3, Ver-00: ----------------------------------------------------- DIAMETER_INVALID_AVP_BITS 3009 A request was received that included an AVP whose flag bits are set to an unrecognized value, or that is inconsistent with the AVPs definition. --------------------------------------------- Proposed Addition of Text, Sec 7.1.5, Ver-00: --------------------------------------------- DIAMETER_INVALID_AVP_BITS 5021 A request was received that included an AVP whose flag bits are set to an unrecognized value, or that is inconsistent with the AVPs definition. ----------------------------------------------------- *** Deprecation of DIAMETER_INVALID_AVP_BIT_COMBO *** ----------------------------------------------------- -------------------------------------------- Proposed Removal of Text, Sec 7.1.5, Ver-00: -------------------------------------------- DIAMETER_INVALID_AVP_BIT_COMBO 5016 The request contained an AVP with which is not allowed to have the given value in the AVP Flags field. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. ----------------------------------------------------------- *** Re-Classification of DIAMETER_INVALID_BIT_IN_HEADER *** ----------------------------------------------------------- ----------------------------------------------------- Proposed Removal of Original Text, Sec 7.1.5, Ver-00: Fajardo Expires April 17, 2007 [Page 9] Internet-Draft Diameter Specification Errata and Issues October 2006 ----------------------------------------------------- DIAMETER_INVALID_BIT_IN_HEADER 5013 This error is returned when an unrecognized bit in the Diameter header is set to one (1). --------------------------------------------- Proposed Addition of Text, Sec 7.1.3, Ver-00: --------------------------------------------- DIAMETER_INVALID_BIT_IN_HEADER 3011 This error is returned when an unrecognized bit in the Diameter header is set to one (1). ------------------------------------------------------------ *** Re-Classification of DIAMETER_INVALID_MESSAGE_LENGTH *** ------------------------------------------------------------ ----------------------------------------------------- Proposed Removal of Original Text, Sec 7.1.5, Ver-00: ----------------------------------------------------- DIAMETER_INVALID_MESSAGE_LENGTH 5015 This error is returned when a request is received with an invalid message length. --------------------------------------------- Proposed Addition of Text, Sec 7.1.3, Ver-00: --------------------------------------------- DIAMETER_INVALID_MESSAGE_LENGTH 3012 This error is returned when a request is received with an invalid message length. 2.3.3. Solution Description The proposal re-classifies the affected error codes to the proper category. The re-classifications allows implementation to react properly depending on whether the request was decoded completely/ properly. Note that the renumbering results in addition of new values in the affected protocol classes and does not re-use any previous values that may have been deprecated. This is an attempt to aid in backward compatibility but this may change in future revisions of this document. Fajardo Expires April 17, 2007 [Page 10] Internet-Draft Diameter Specification Errata and Issues October 2006 2.4. Composing Failed AVP for Invalid AVP length 2.4.1. Problem Description It may not be possible to properly compose a Failed-AVP as defined in Sec 7.5 of RFC3588 [1] in situations where the offending AVP is reporting an AVP length that is: o Greater than the message length o Less than the AVP header length In such a case, it is sufficient to that the Failed-AVP carry only the copy of the offending AVP header. 2.4.2. Text Changes Fajardo Expires April 17, 2007 [Page 11] Internet-Draft Diameter Specification Errata and Issues October 2006 ------------------------ Original Text: Sec 7.1.5 ------------------------ DIAMETER_INVALID_AVP_LENGTH 5014 The request contained an AVP with an invalid length. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. ------------------------------------ Proposed Changes, Sec 7.1.5, Ver-00: ------------------------------------ DIAMETER_INVALID_AVP_LENGTH 5014 The request contained an AVP with an invalid length. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. In cases where the erroneous avp length value exceeds the message length or is less than the minimum AVP header length, it is sufficient to include the offending AVP header and a zero filled payload of the minimum required length. ----------------------------------- Original Text: Paragraph 3, Sec 7.5 ----------------------------------- A Diameter message MAY contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing vendor id, and a zero filled payload of the minimum required length for the omitted AVP will be added. ----------------------------------------------- Proposed Changes, Paragraph 3, Sec 7.5, Ver-00: ----------------------------------------------- A Diameter message MAY contain one Failed-AVP AVP, containing the entire AVP that could not be processed successfully. If the failure reason is omission of a required AVP, an AVP with the missing AVP code, the missing vendor id, and a zero filled payload of the minimum required length for the omitted AVP will be added. If the failure reason is an invalid AVP length where the reported length is less than the minimum AVP header length or greater than the reported message length, a copy of the offending AVP header and a zero filled payload of the minimum required length SHOULD be added. Fajardo Expires April 17, 2007 [Page 12] Internet-Draft Diameter Specification Errata and Issues October 2006 2.4.3. Solution Description The proposal allows for the inclusion of the offending AVP header only in the Failed-AVP content in the cases stated above. 2.5. Capabilities Exchange in the Open State 2.5.1. Problem Description Currently, the peer state machine described in described in Sec 5.6 of RFC3588 [1] implies that peers can perform capabilities exchange (CER/CEA) during the open state. However, there is not associated text clearly defining this process or the consequences of it. 2.5.2. Text Changes ------------------------------------------- Proposed Addition of new Sec 5.6.5, Ver-00: ------------------------------------------- 5.6.5. Capabilities Update A Diameter node MUST initiate peer capabilities update by sending a Capabilities-Exchange-Req (CER) to all its peers which supports peer capabilities update and is in OPEN state. The receiver of CER in open state MUST process and reply to the CER as a described in Section 5.3. The CEA which the receiver sends MUST contain its latest capabilities. Note that peers which successfully process the peer capabilities update SHOULD also update their routing tables to reflect the change. The receiver of the CEA, with a Result-Code AVP other than DIAMETER_SUCCESS, initiates the transport disconnect. The peer may periodically attempt to reconnect, as stated in Section 2.1. Peer capabilities update in the open state SHOULD be limited to the advertisement of the new list of supported applications and MUST preclude re-negotiation of security mechanism or other capabilities. If any capabilities change happens in the node (e.g. change in security mechanisms), other than a change in the supported applications, the node SHOULD gracefully terminate (setting the Disconnect-Cause AVP value to REBOOTING) and re-establish the diameter connections to all the peers. Fajardo Expires April 17, 2007 [Page 13] Internet-Draft Diameter Specification Errata and Issues October 2006 2.5.3. Solution Description The proposal defines a clear behavior on how peer can exchange new capabilities during the open state. The proposal reuses the CER/CEA behavior currently existing in Sec 5.3. However, it became evident during further discussion that the capabilities update should be limited to advertisement of changes in application support and precludes any other capabilities changes such as security. 2.6. ABNF for Vendor-Specific-Application-Id allows multiple Vendor-Ids 2.6.1. Problem Description The current definition of Vendor-Specific-Application-Id in Sec 6.11 in RFC3588 [1] allows for multiple Vendor-Id AVPs instances. This definition is unclear since the natural assumption should be to have only a single Vendor-Id for this grouped AVP, i.e. only a single vendor has ownership of the set of application ids. 2.6.2. Text Changes ------------------------------------------ Original Text, Sec 6.11 (ABNF definition): ------------------------------------------ ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } ----------------------------------- Proposed Changes, Sec 6.11, Ver-00: ----------------------------------- ::= < AVP Header: 260 > < Vendor-Id > 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } 2.6.3. Solution Description The proposal defines only a single instance of Vendor-Id AVP in Vendor-Specific-Application-Id. Fajardo Expires April 17, 2007 [Page 14] Internet-Draft Diameter Specification Errata and Issues October 2006 2.7. Definition URI Schemes 2.7.1. Problem Description The problem description can be found in draft-garcia-dime-aaa-uri-00.txt. 2.7.2. Text Changes None. 2.7.3. Solution Description None. 2.8. Application ID to be used by ASR/ASA, RAR/RAA, STR/STA 2.8.1. Problem Description A question arose regarding what application id should session level messages defined in the base protocol (RFC3588 [1]) use. Specifically, should session level messages such as ASR/ASA, RAR/RAA and STR/STA use the application id defined for the application using them or should they use an application id of zero (0). There has been some level of dis-agreement regarding this issue. On one hand, implementers interpretation of RFC3588 falls in a software component model where the applications themselves are components and responsible for sending/receiving application specific messages and that the diameter base protocol is merely a transport service. Therefore, this naturally implies that all application/session level messages including ASR/ASA, RAR/RAA and STR/STA would use the application id of the application. On the other hand, the original authors of RFC3588 followed the interpretation of a supported application model where a diameter entity supports (or does not support) a specific application and that entity itself is responsible for sending messages rather than a separate application entity. The latter model has been followed by the authors of other documents such as RFC4005 [2] and RFC4072 [3]. 2.8.2. Text Changes There is a need to clarify which model RFC3588 should use. Work is ongoing. Fajardo Expires April 17, 2007 [Page 15] Internet-Draft Diameter Specification Errata and Issues October 2006 2.8.3. Solution Description Ongoing. 2.9. Removal of Trailing [fixed*] avp in Command Code ABNF specification 2.9.1. Problem Description The diameter-message in Sec 3.2 of RFC3588 [1] specifies that trailing [fixed*] AVPs can be present in a diameter- message. This requires additional processing for current implementations to validate trailing fixed AVPs when there seems to be no usage for it. So far appending of trailing avps seems relevant to proxies and relays. However, route-records and proxy-info are normally tagged as optional as they should be. So this format can be relaxed to help simplify parsing. 2.9.2. Text Changes ----------------------------------------------------- Original Text, Sec 3.2 (diameter-message definition): ----------------------------------------------------- diameter-message = header[ *fixed] [ *required] [ *optional] [ *fixed] ---------------------------------------------------------------- Proposed Changes, Sec 3.2 (diameter-message definition), Ver-00: ---------------------------------------------------------------- diameter-message = header[ *fixed] [ *required] [ *optional] 2.9.3. Solution Description Removal of trailing [*fixed] definition in diameter-message ABNF. 2.10. Mapping between Disconnect-Cause AVP and the Reconnect Behavior 2.10.1. Problem Description Some implementations require clarification of the reconnect behavior of Diameter peers which receive DPR. The relevant section is Sec 5.4 paragraph one(1) where it hints no re-connection attempts in the following cases: o "Shortage of internal resources" which is assumed to correspond to "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Fajardo Expires April 17, 2007 [Page 16] Internet-Draft Diameter Specification Errata and Issues October 2006 o "Node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future" is assumed to correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect- Cause AVP. o However, there are hints in re-connection attempts in case: o "or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1" which corresponds to "REBOOTING" value for Disconnect-Cause AVP. Considering these assumptions, there is a need to clarify a mapping between the value of Disconnect-Cause AVP and the expected re-connect behavior. Especially in a high traffic scenario: the peer (the client) will always have something to send/forward. Hence it will always attempt to reconnect. This nullifies the result-code indication of the DPR/DPA procedure. Therefore there should be some DPR Disconnect causes which helps the peer to understand when it should/should not reconnect. Say for example: if the Disconnect- Cause AVP is REBOOTING then reconnect else if the Disconnect-Cause AVP is BUSY || DO_NOT_WANT_TO_TALK_TO_YOU then do not reconnect. Such re-connection behavior mapping maybe justified considering the following potential deployment problems if they are not: o A node (especially servers) does not initiate connections but expects peers (read clients) to know about it & connect to it. Such behavior may be justified by the fact that dynamic peer discovery is not supported and that static configuration of large number of peers is considered unwieldy. o As per the item above, such a node cannot send DPR, because if it does, the peers (read clients) will not attempt reconnection. This will result in a scenario where there is no connection at all & neither party is attempting too. o Such deadlock can only be broken by restart of the peer (of no fault of its own) 2.10.2. Text Changes ------------------------- Original Text, Sec 5.4.3: ------------------------- Fajardo Expires April 17, 2007 [Page 17] Internet-Draft Diameter Specification Errata and Issues October 2006 5.4.3. Disconnect-Cause AVP The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A Diameter node MUST include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shutdown the transport connection. The following values are supported: REBOOTING 0 A scheduled reboot is imminent. BUSY 1 The peer's internal resources are constrained, and it has determined that the transport connection needs to be closed. DO_NOT_WANT_TO_TALK_TO_YOU 2 The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future. ------------------------------------ Proposed Changes, Sec 5.4.3, Ver-00: ------------------------------------ 5.4.3. Disconnect-Cause AVP The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A Diameter node MUST include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shutdown the transport connection. The following values are supported: REBOOTING 0 A scheduled reboot is imminent. Receiver of DPR with above result code MAY attempt reconnection. BUSY 1 The peer's internal resources are constrained, and it has determined that the transport connection needs to be closed. Receiver of DPR with above result code SHOULD NOT attempt reconnection. DO_NOT_WANT_TO_TALK_TO_YOU 2 The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future. Receiver of DPR with above result code SHOULD NOT attempt reconnection. Fajardo Expires April 17, 2007 [Page 18] Internet-Draft Diameter Specification Errata and Issues October 2006 2.10.3. Solution Description Added when and when not to attempt reconnection based on the value of the Disconnect-Cause AVP. 2.11. Advertising of Relay application-id and the Election Process 2.11.1. Problem Description There needs to be a clarification on which AVP a peer should use when it's trying to advertise itself as a relay. The issue is that the relay application is neither an auth nor an acct application, but the protocol only specifies explicit AVPs for advertising one or the other. An editorial issue also exists in the 4th paragraph of Sec 11.3. The term Application-Id is assumed to pertain to Auth-Application-Id. 2.11.2. Text Changes --------------------------------------- Original Text, Sec 11.3, 4th Paragraph: --------------------------------------- Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. ------------------------------------------ Proposed Changes, Sec 11.3, 4th Paragraph: ------------------------------------------ Both Auth-Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. A diameter node advertising itself as a relay agent MUST set either Application-Id or Acct-Application-Id to 0xffffffff. 2.11.3. Solution Description A peer advertising itself as a relay application can use either the Auth-Application-Id AVP or Acct-Application-Id AVP. Such a peer should set either AVP to 0xffffffff values as specified in Sec 11.3 of RFC3588 [1]. 2.12. Duplication of Application ID in the Header and Application Id AVPs Fajardo Expires April 17, 2007 [Page 19] Internet-Draft Diameter Specification Errata and Issues October 2006 2.12.1. Problem Description There exists a confusion regarding the relationship of the application id in the diameter header and the application id AVP containers (Auth-Application-Id, Acct-Application-Id etc.). The following specific issues where raised: o Why is there a need to have two(2) copies of the application id information. One in the header and the other in the relevant application id AVPs. Also, more clarification is required with regards to their relationship. o Why is the application id in the header defined as a 32-bit value while application id AVPs may represented by a more complex container, i.e. Vendor-Specific-Application-Id where there is an optional 32 bits for Vendor-Id and a binary selector between Auth versus Acct application id. There seems to be lead to some confusion as to whether the application id numbering space is flat or not. 2.12.2. Text Changes ------------------------------- Original Text, Sec 6.8 and 6.9: ------------------------------- 6.8. Auth-Application-Id AVP The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used in order to advertise support of the Authentication and Authorization portion of an application (see Section 2.4). The Auth-Application-Id MUST also be present in all Authentication and/or Authorization messages that are defined in a separate Diameter specification and have an Application ID assigned. 6.9. Acct-Application-Id AVP The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and is used in order to advertise support of the Accounting portion of an application (see Section 2.4). The Acct-Application-Id MUST also be present in all Accounting messages. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present. ---------------------------------- Proposed Changes, Sec 6.8 and 6.9: ---------------------------------- Fajardo Expires April 17, 2007 [Page 20] Internet-Draft Diameter Specification Errata and Issues October 2006 6.8. Auth-Application-Id AVP The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used in order to advertise support of the Authentication and Authorization portion of an application (see Section 2.4). The Auth-Application-Id MUST also be present in all Authentication and/or Authorization messages that are defined in a separate Diameter specification and have an Application ID assigned. If present in a message, the value of the Auth-Application-Id AVP MUST match the application id present in the diameter message header except when used in a CER or CEA messages. 6.9. Acct-Application-Id AVP The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and is used in order to advertise support of the Accounting portion of an application (see Section 2.4). The Acct-Application-Id MUST also be present in all Accounting messages. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present. If present in a message, the value of the Acct-Application-Id AVP MUST match the application id present in the diameter message header except when used in a CER or CEA messages. --------------------------------------- Original Text, Sec 6.11, 1st Paragraph: --------------------------------------- The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present. ------------------------------------------ Proposed Changes, Sec 6.11, 1st Paragraph: ------------------------------------------ The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one instance of Auth-Application-Id or Acct-Application-Id AVP MAY be present. The application identifier carried by either Auth-Application-Id or Acct-Application-Id AVP MUST comply with vendor specific application identifier assignment described in Sec 11.3. It MUST also match the application id present in the diameter header except when used in a CER or CEA messages. Fajardo Expires April 17, 2007 [Page 21] Internet-Draft Diameter Specification Errata and Issues October 2006 The Vendor-Id AVP is an informational AVP pertaining to the vendor who may have authorship of the vendor specific diameter application. It should not be used to as a further discriminator against application identifiers specified in Sec 11.3. ----------------------------------------------- Original Text, Sec 6.1.1, Last Enumerated Item: ----------------------------------------------- - an Acct-Application-Id AVP, an Auth-Application-Id or a Vendor- Specific-Application-Id AVP must be included if the request is proxiable. -------------------------------------------------- Proposed Changes, Sec 6.1.1, Last Enumerated Item: -------------------------------------------------- - an Acct-Application-Id AVP, an Auth-Application-Id or a Vendor- Specific-Application-Id AVP must be included if the request is proxiable. The application id present in any of these AVPs must match the application id present in the diameter message header. ----------------------------------------- Original Text, Sec 6.1.6, 1st Paragraph: ----------------------------------------- 6.1.6. Request Routing Diameter request message routing is done via realms and applications. A Diameter message that may be forwarded by Diameter agents (proxies, redirects or relays) MUST include the target realm in the Destination-Realm AVP and one of the application identification AVPs Auth-Application-Id, Acct-Application-Id or Vendor-Specific-Application-Id. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. -------------------------------------------- Proposed Changes, Sec 6.1.6, 1st Paragraph: -------------------------------------------- 6.1.6. Request Routing Diameter request message routing is done via realms and applications. A Diameter message that may be forwarded by Fajardo Expires April 17, 2007 [Page 22] Internet-Draft Diameter Specification Errata and Issues October 2006 Diameter agents (proxies, redirects or relays) MUST include the target realm in the Destination-Realm AVP. Request routing SHOULD rely on the Destination-Realm AVP and the application id present in the request message header to aid in the routing decision. It MAY also rely on the application identification AVPs Auth-Application-Id, Acct-Application-Id or Vendor-Specific-Application-Id instead of the application id in the message header as a secondary measure. The realm MAY be retrieved from the User-Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. 2.12.3. Solution Description The solution attempts to clarify the following cases: o Given that existing implementations already accommodate both application id in the message header and application id AVPs as currently defined in RFC3588 [1], the proposed text further reinforces the fact that both entities must match. o The proposal clearly defines how an implementation should treat Vendor-Specific-Application-Id. It specifies that the Auth or Acct application id contained within the Vendor-Specific- Application-Id must use the same application id assignment space along with the standards based application id. It reinforces Sec 11.3 of RFC388 [1] in complying with the IANA assignments process. o The proposal clarifies the use of the application id in the diameter header as the primary method for aiding in realm routing. And that the use of the application id AVPs in request routing is secondary in order to accommodate existing implementations. 3. Optimizations 3.1. Predictive Loop Avoidance 3.1.1. Problem Description Loop detection mechanism specified in Sec 6.1.3 of RFC3588 [1] has the following drawbacks: o It does not provide loop avoidance mechanism. In the absence of agents which correct the error and retries, potential successful routes to the destination might not be tried even if one exists. Fajardo Expires April 17, 2007 [Page 23] Internet-Draft Diameter Specification Errata and Issues October 2006 o No recovery mechanism is specified, RFC3588 [1] seems to suggest only a manual or administrative correction. 3.1.2. Text Changes ------------------------------------------- Proposed Addition of new Sec 6.1.7, Ver-00: ------------------------------------------- 6.1.7. Predictive Loop Avoidance Before forwarding or routing a request, Diameter agents, in addition to processing done in Section 6.1.3, SHOULD check for the presence of candidate route's peer identity in any of the Route-Record AVPs. In an event of the agent detecting the presence of a candidate route's peer identity in a Route-Record AVP, the agent MUST ignore such route for the Diameter request message and attempt alternate routes if any. In case all the candidate routes are eliminated by the above criteria, the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER message. 3.1.3. Solution Description Added a new section under Sec 6.1 describing predictive loop avoidance. Note that this solution is backward compatible and optional and hence will not affect existing implementations. 4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. 5. IANA Considerations This document does not require any action from IANA. 6. Security Considerations This document does not contain a security protocol; it is a compilation of issues found in the DIAMETER protocol specification. All security issues of DIAMETER protocol must be considered in implementing this specification. This extension does not add any Fajardo Expires April 17, 2007 [Page 24] Internet-Draft Diameter Specification Errata and Issues October 2006 unique concerns. 7. Acknowledgements The authors would like to thank the following people that have provided proposals and contributions to this document: Vishnu Ram, Satendra Gera, Tolga Asveren, Timothy Smith and Tony Zhang. Special thanks also to people who have provided comments and input: Jan Nordqvist, Anders Kristensen, Yoshihiro Ohba, Marco Stura, and German Blanco. 8. Normative References [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [2] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Victor Fajardo Toshiba America Research Inc. One Telcordia Drive Piscataway, NJ 08854 USA Email: vfajardo@tari.toshiba.com Fajardo Expires April 17, 2007 [Page 25] Internet-Draft Diameter Specification Errata and Issues October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Fajardo Expires April 17, 2007 [Page 26]