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):
------------------------------------------
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }
-----------------------------------
Proposed Changes, Sec 6.11, Ver-00:
-----------------------------------
<Vendor-Specific-Application-Id> ::= < 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]