RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Verified (8)

RFC 6733, "Diameter Base Protocol", October 2012

Source of RFC: dime (ops)

Errata ID: 3805
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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.

Errata ID: 4615
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Lionel Morand
Date Reported: 2016-02-05
Verifier Name: Benoit Claise
Date Verified: 2016-05-17

Section 7.1.5 says:

   DIAMETER_AVP_UNSUPPORTED 5001

      The peer received a message that contained an AVP that is not
      recognized or supported and was marked with the 'M' (Mandatory)
      bit.  A Diameter message with this error MUST contain one or more
      Failed-AVP AVPs containing the AVPs that caused the failure.

It should say:

   DIAMETER_AVP_UNSUPPORTED 5001

      The peer received a message that contained an AVP that is not
      recognized or supported and was marked with the 'M' (Mandatory)
      bit.  A Diameter message with this error MUST contain one 
      Failed-AVP AVP containing the AVPs that caused the failure.

Notes:

The RFC6733 has clarified that only one instance of Failed-AVP AVP can be present in the command answer. One Failed-AVP AVP is enough because this AVP is defined as Grouped AVP that can contain multiple AVPs. In the present case, each of the nested AVPs in the Failed-AVP AVP are the AVPs that caused the failure.

Errata ID: 4808
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Zbigniew Rapnicki
Date Reported: 2016-09-22
Verifier Name: Benoit Claise
Date Verified: 2017-01-04

Section 1.1.3 says:

This document obsoletes RFC 3588 but is fully backward compatible
   with that document.

It should say:

This document obsoletes RFC 3588.

Notes:

When comparing the BNF for the answer messages CEA, DPA, DWA, RAA, STA and ASA it can be seen that FAILED-AVP avp is no longer marked with the * which means it can be present only once in the diameter message.
Previous specification (rfc3588) defines multiple FAILED-AVP avp usage in a single diameter message.
Similar case is for Vendor-Specific-Application-Id AVP definition.
Previous specification allows multiple usage of Vendor-Id avp in a single message while the new specification defines it as a single mandatory AVP:
rfc3588:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }

rfc6733:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
{ Vendor-Id }
[ Auth-Application-Id ]
[ Acct-Application-Id ]

How this facts applies to the sentence about fully backward compatibility in the section 1.1.3?

Errata ID: 4887
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Mikhail Zaytsev
Date Reported: 2016-12-13
Verifier Name: Benoit Claise
Date Verified: 2017-01-03

Section 6.2 says:

 When a request is locally processed, the following procedures MUST be
   applied to create the associated answer, in addition to any
   additional procedures that MAY be discussed in the Diameter
   application defining the command:

   o  The same Hop-by-Hop Identifier in the request is used in the
      answer.

   o  The local host's identity is encoded in the Origin-Host AVP.

   o  The Destination-Host and Destination-Realm AVPs MUST NOT be
      present in the answer message.

It should say:

 When a request is locally processed, the following procedures MUST be
   applied to create the associated answer, in addition to any
   additional procedures that MAY be discussed in the Diameter
   application defining the command:

   o  The same Hop-by-Hop Identifier in the request is used in the
      answer.

   o  The local host's identity is encoded in the Origin-Host AVP.

   o  The local realm's identity is encoded in the Origin-Realm AVP.

   o  The Destination-Host and Destination-Realm AVPs MUST NOT be
      present in the answer message.

Notes:

Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP MUST be encoded in the associated answer. While both these AVPs MUST be present in all Diameter messages according to their descriptions.

Errata ID: 4803
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Holger Freyther
Date Reported: 2016-09-13
Verifier Name: Benoit Claise
Date Verified: 2017-07-27

Section 3.2 says:

In section 3.2

      header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"


In section 3.4

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

It should say:

In section 3.2

      header           = "<Diameter Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

In section 3.4

         header           = "<" "AVP Header:" avpcode [vendor] ">"

Notes:

Background:
There was an initial errata (kept for background information at the bottom of this note). After some discussion with the dime WG, this errata was modified.

This errata report is correct on the inconsistency regarding the definition of the command header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.



For commands, the header is defined as follow:



header = "<Diameter-Header:" command-id

[r-bit] [p-bit] [e-bit] [application-id]">"



whereas "<Diameter Header:" is used when defining commands.



Same for Grouped AVP. It is defined as follow:



header = "<" "AVP-Header:" avpcode [vendor] ">"



whereas "<AVP Header:" is used when defining Grouped AVPs.



Considering that most (if not all) the ABNF descriptions have been copied from the commands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definition of the headers, i.e.



--> In section 3.2. Command Code Format Specification



OLD:



header = "<Diameter-Header:" command-id

[r-bit] [p-bit] [e-bit] [application-id]">"



NEW:



header = "<Diameter Header:" command-id

[r-bit] [p-bit] [e-bit] [application-id]">"





--> And in section 4.4



OLD:



header = "<" "AVP-Header:" avpcode [vendor] ">"



NEW:



header = "<" "AVP Header:" avpcode [vendor] ">"

=============================================================================

This initial errata is below:
Original text:
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]

Corrected text:
<Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]

I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF.

header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"

But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".


command-def = "<" command-name ">" "::=" diameter-message

but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.

Status: Reported (1)

RFC 6733, "Diameter Base Protocol", October 2012

Source of RFC: dime (ops)

Errata ID: 6171
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Valentin Micic
Date Reported: 2020-05-13

Section 6.1.3 says:

A relay or proxy agent MUST check for forwarding loops when receiving
requests.  A loop is detected if the server finds its own identity in
a Route-Record AVP.  When such an event occurs, the agent MUST answer
with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

It should say:

A relay or proxy agent MUST check for forwarding loops when receiving
requests. A loop is detected if a relay or proxy agent finds its own
identity in a Route-Record AVP.  When such an event occurs, the agent
MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

Notes:

The term "server" used to identify party which is to detect its own identity as a part of Route-Record AVP is semantically too close to the term Diameter Server. If "relay or proxy agent MUST check", the question is what would be the consequence of such action if the (Diameter) "server" is to do the "detecting"?

Report New Errata