RFC Errata
Found 10 records.
Status: Verified (8)
RFC 6733, "Diameter Base Protocol", October 2012
Note: This RFC has been updated by RFC 7075, RFC 8553
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 (2)
RFC 6733, "Diameter Base Protocol", October 2012
Note: This RFC has been updated by RFC 7075, RFC 8553
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"?
Errata ID: 6832
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kshitij Dutt
Date Reported: 2022-02-03
Section 7.1.4 says:
DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the accounting request but was unable to
commit it to stable storage due to a temporary lack of space.
It should say:
DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the request but was unable to
commit it to stable storage due to a temporary lack of space.
Notes:
Original text signifies accounting application explicitly. It can be any of Accounting or Authorization.