errata logo graphic

Found 7 records.

Status: Verified (4)

RFC6733, "Diameter Base Protocol", October 2012

Source of RFC: dime (ops)

Errata ID: 3805

Status: Verified
Type: Technical

Reported By: Lionel
Date Reported: 2013-11-18
Verifier Name: Benoit Claise
Date Verified: 2013-12-09

Section 3 says:

    Message Length

      The Message Length field is three octets and indicates the length
      of the Diameter message including the header fields and the padded
      AVPs.  Thus, the Message Length field is always a multiple of 4.

It should say:

    Message Length

      The Message Length field is three octets and indicates the number
      of octets of the Diameter message, including the header fields and
      the padded AVPs.  Thus, the Message Length field is always a 
      multiple of 4 octets.

Notes:

the actual text does not indicate the unit of length unit, which may lead to confusion and IOT issues, especially if someone considers bits instead of bytes.


Errata ID: 3806

Status: Verified
Type: Technical

Reported By: Lionel
Date Reported: 2013-11-18
Verifier Name: Benoit Claise
Date Verified: 2013-11-19

Section 2.7 says:

   Server Identifier

      The identity of one or more servers to which the message is to be
      routed.  This identity MUST also be present in the Host Identity
      field of the peer table (Section 2.6).  When the Local Action is
      set to RELAY or PROXY, this field contains the identity of the
      server(s) to which the message MUST be routed.  When the Local
      Action field is set to REDIRECT, this field contains the identity
      of one or more servers to which the message MUST be redirected.

It should say:

   Peer Identifier

      The identity of one or more peers to which the message is to be
      routed.  This identity MUST also be present in the Host Identity
      field of the peer table (Section 2.6).  When the Local Action is
      set to RELAY or PROXY, this field contains the identity of the
      peer(s) to which the message MUST be routed.  When the Local
      Action field is set to REDIRECT, this field contains the identity
      of one or more peers to which the message MUST be redirected.

Notes:

The host identified in a Routing Table entry is not necessarily a "server". It can also be a Relay, a redirect or a proxy agent. Using "peer" instead of "server" is more appropriate.


Errata ID: 3942

Status: Verified
Type: Technical

Reported By: Benoit Claise
Date Reported: 2014-04-01
Verifier Name: Benoit Claise
Date Verified: 2014-04-01

Section 8 says:

   When a Diameter server authorizes a user to implement network
   resources for a finite amount of time, and it is willing to extend
   the authorization via a future request, it MUST add the
   Authorization- Lifetime AVP to the answer message.

It should say:

   When a Diameter server authorizes a user to implement network
   resources for a finite amount of time, and it is willing to extend
   the authorization via a future request, it MUST add the
   Authorization-Lifetime AVP to the answer message.

Notes:

Authorization-Lifetime was mispelled


Errata ID: 3997

Status: Verified
Type: Technical

Reported By: Jouni Korhonen
Date Reported: 2014-05-24
Verifier Name: Benoit Claise
Date Verified: 2014-06-04

Throughout the document, when it says:

Section 2.1.

   The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
   and SCTP [RFC4960].  For TLS [RFC5246] and Datagram Transport Layer
   Security (DTLS) [RFC6347], a Diameter node that initiates a
   connection prior to any message exchanges MUST run on port 5658.  It
   is assumed that TLS is run on top of TCP when it is used, and DTLS is
   run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port 5658 (i.e., the peer complies only with RFC
   3588), then the initiator MAY revert to using TCP or SCTP on port
   3868.  Note that this scheme is kept only for the purpose of backward
   compatibility and that there are inherent security vulnerabilities
   when the initial CER/CEA messages are sent unprotected (see
   Section 5.6).

   Diameter clients MUST support either TCP or SCTP; agents and servers
   SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   it MUST always be prepared to receive connections on port 3868 for
   TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections.
   When DNS-based peer discovery (Section 5.2) is used, the port numbers
   received from SRV records take precedence over the default ports
   (3868 and 5658).

Section 4.3.1.

      port               = ":" 1*DIGIT

                      ; One of the ports used to listen for
                      ; incoming connections.
                      ; If absent, the default Diameter port
                      ; (3868) is assumed if no transport
                      ; security is used and port 5658 when
                      ; transport security (TLS/TCP and DTLS/SCTP)
                      ; is used.

It should say:

Section 2.1.

   The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
   and SCTP [RFC4960].  For TLS [RFC5246] and Datagram Transport Layer
   Security (DTLS) [RFC6347], a Diameter node that initiates a
   connection prior to any message exchanges MUST run on port 5868.  It
   is assumed that TLS is run on top of TCP when it is used, and DTLS is
   run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port 5868 (i.e., the peer complies only with RFC
   3588), then the initiator MAY revert to using TCP or SCTP on port
   3868.  Note that this scheme is kept only for the purpose of backward
   compatibility and that there are inherent security vulnerabilities
   when the initial CER/CEA messages are sent unprotected (see
   Section 5.6).

   Diameter clients MUST support either TCP or SCTP; agents and servers
   SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   it MUST always be prepared to receive connections on port 3868 for
   TCP or SCTP and port 5868 for TLS/TCP and DTLS/SCTP connections.
   When DNS-based peer discovery (Section 5.2) is used, the port numbers
   received from SRV records take precedence over the default ports
   (3868 and 5868).

Section 4.3.1.

      port               = ":" 1*DIGIT

                      ; One of the ports used to listen for
                      ; incoming connections.
                      ; If absent, the default Diameter port
                      ; (3868) is assumed if no transport
                      ; security is used and port 5868 when
                      ; transport security (TLS/TCP and DTLS/SCTP)
                      ; is used.

Notes:

RFC 6733 defined the Diameter port number for secure transport in IANA considerations Section 11.4. to be 5868. This is also in IANA port numbers registry "Service Name and Transport Protocol Port Number Registry". However, the RFC 6733 body text uses different port number in Sections 2.1. and 4.3.1. for secure transports. Since the IANA registry already contains the port number 5868 instead of the body text used value 5658, the values in Sections 2.1. and 4.3.1. should be 5868 instead of 5658.


Status: Held for Document Update (2)

RFC6733, "Diameter Base Protocol", October 2012

Source of RFC: dime (ops)

Errata ID: 4210

Status: Held for Document Update
Type: Editorial

Reported By: Hans Liu
Date Reported: 2014-12-25
Held for Document Update by: Benoit Claise
Date Held: 2015-01-07

Section 5.4.3 says:

   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 shut
   down the transport connection.  The following values are supported:
      REBOOTING                         0
         A scheduled reboot is imminent.  A receiver of a 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.
         A receiver of a 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.  A receiver of a
         DPR with above result code SHOULD NOT attempt reconnection.

It should say:

   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 shut
   down the transport connection.  The following values are supported:
      REBOOTING                         0
         A scheduled reboot is imminent.  A receiver of a DPR with
         above result code MAY attempt reconnection.
      BUSY                              1
         The internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.
      DO_NOT_WANT_TO_TALK_TO_YOU        2
         The node 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.  A receiver of a
         DPR with above result code SHOULD NOT attempt reconnection.

Notes:

A peer can either be a sender or receiver, depending on the contexst.

However in same section describing usage for the same AVP (description for cause), the 1st appearance represents the role of receiver, the 2nd and 3rd appearances has changed to the role of senders, it's confusing literally.


Errata ID: 4234

Status: Held for Document Update
Type: Editorial

Reported By: Lionel Morand
Date Reported: 2015-01-16
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-01-16

Section 5.4 says:

In the last sentence of first paragraph odf the section 5.4, it is said:

   When a Diameter node disconnects one of its transport connections,
   its peer cannot know the reason for the disconnect and will most
   likely assume that a connectivity problem occurred or that the peer
   has rebooted.  In these cases, the peer may periodically attempt to
   reconnect, as stated in Section 2.1.  In the event that the
   disconnect was a result of either a shortage of internal resources or
   simply that the node in question has no intentions of forwarding any
   Diameter messages to the peer in the foreseeable future, a periodic
   connection request would not be welcomed.  The Disconnection-Reason
   AVP contains the reason the Diameter node issued the Disconnect-Peer-
   Request message.

It should say:

the sentence should be:


   When a Diameter node disconnects one of its transport connections,
   its peer cannot know the reason for the disconnect and will most
   likely assume that a connectivity problem occurred or that the peer
   has rebooted.  In these cases, the peer may periodically attempt to
   reconnect, as stated in Section 2.1.  In the event that the
   disconnect was a result of either a shortage of internal resources or
   simply that the node in question has no intentions of forwarding any
   Diameter messages to the peer in the foreseeable future, a periodic
   connection request would not be welcomed.  The Disconnect-Cause AVP
   contains the reason the Diameter node issued the Disconnect-Peer-
   Request message.

Notes:

The correct name of the AVP is "Disconnect-Cause AVP" and not "Disconnection-Reason AVP" that does not exist.


Status: Rejected (1)

RFC6733, "Diameter Base Protocol", October 2012

Source of RFC: dime (ops)

Errata ID: 4209

Status: Rejected
Type: Technical

Reported By: Hans Liu
Date Reported: 2014-12-25
Rejected by: Benoit Claise
Date Rejected: 2015-01-23

Section 5.4.3 says:

      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.

It should say:

      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD either 
         connect to an alternate node, or attempt reconnection
         after a time period.

Notes:

In most implementations, the Diameter node will continue to serve its peer after the resources recover and expect reconnection. If the Diameter node won't like reconnection from peer, DO_NOT_WANT_TO_TALK_TO_YOU can be used instead of BUSY.
--VERIFIER NOTES--
The text describing the "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" cases is consistent with the text found in the introduction of the section 5.4.

"In the event that the
disconnect was a result of either a shortage of internal resources or
simply that the node in question has no intentions of forwarding any
Diameter messages to the peer in the foreseeable future, a periodic
connection request would not be welcomed. The Disconnection-Reason
AVP contains the reason the Diameter node issued the Disconnect-Peer-
Request message.

The Disconnect-Peer-Request message is used by a Diameter node to
inform its peer of its intent to disconnect the transport layer and
that the peer shouldn't reconnect unless it has a valid reason to do
so (e.g., message to be forwarded). "

So the main purpose for sending a DPR with the causes "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" is actually to avoid the periodic reconnection attempts governed by the Tc timer.
These exceptions are mentioned in the section 2.1:

"When no transport connection exists with a peer, an attempt to
connect SHOULD be made periodically. This behavior is handled via
the Tc timer (see Section 12 for details), whose recommended value is
30 seconds. There are certain exceptions to this rule, such as when
a peer has terminated the transport connection stating that it does
not wish to communicate."

Now, it is true that there is no clear guideline on how to behave when receiving the cause "BUSY" and this explains why some implementations in the field still attempt to re-open the connection, as after a normal transport failure detection. But it does not mean that the text in the RFC6733 is wrong.

Finally, if it is an attempt to clarify/modify the behavior of the peer receiving DPR with the "BUSY" cause, I don't think that using errata would be the most appropriate way.


Report New Errata