RFC Errata
Found 5 records.
Status: Verified (1)
RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021
Source of RFC: quic (wit)
Errata ID: 6811
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Martin Thomson
Date Reported: 2022-01-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2022-02-18
Section 5.1.1 says:
The sequence number of the
initial connection ID is 0. If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID
is 1.
Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (Section 19.15). The sequence number on
each newly issued connection ID MUST increase by 1.
It should say:
The sequence number of the
initial connection ID is 0. If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID
is 1. The sequence number for NEW_CONNECTION_ID frames starts at 2
when the preferred_address transport parameter is sent and 1
otherwise.
Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (Section 19.15). The sequence number on
each newly issued connection ID MUST increase by 1.
Notes:
It is not sufficiently clear that the (implied) sequence number for the preferred_address transport parameter is taken from the sequence only when the transport parameter is present.
The original text might be read to imply that the first NEW_CONNECTION_ID frame always starts with 2, though maybe only at a server. The proposed addition is much more explicit.
Status: Reported (2)
RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021
Source of RFC: quic (wit)
Errata ID: 7861
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mike Bishop
Date Reported: 2024-03-20
Section 8.1.2 says:
If a server receives a client Initial that contains an invalid Retry token but is otherwise valid...
It should say:
If a server receives a client Initial containing a valid Retry token that does not authenticate the peer address...
Notes:
Valid tokens MUST be a) integrity-protected (Section 8.1.4) and distinguishable as to purpose (Section 8.1.1), i.e. tokens from a Retry packet vs. tokens from NEW_TOKEN frames. To satisfy address validation, they should enable the server to verify the client's transport address. This text does not specify which form of invalidity is being discussed -- failure of integrity protection or a mismatch between the contents of the token and the client's address.
Applying this text to all "invalid" tokens which appear to be Retry tokens does not allow for the scenario where the token was generated by another server / another QUIC implementation and is in fact unreadable. Such tokens, even if they appear to be Retry tokens, are supposed to be handled by the requirements in 8.1.3, i.e. ignore the token and handle the packet as if no token were present.
This section should be scoped only to tokens which are correctly formatted and readable by the server, but whose contents are not sufficient to prove the client's transport address is valid. Otherwise, the determination that the token is a Retry token cannot be trusted.
(This discrepancy appears in a multi-CDN context, where tokens generated by one CDN will sometimes be received by a different CDN; if these tokens appear to be "invalid Retry tokens", the connection is closed when the token should simply be ignored.)
Errata ID: 7365
Status: Reported
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: yongboy
Date Reported: 2023-02-23
Edited by: Zaheduzzaman Sarker
Date Edited: 2023-03-06
Section 12.4. says:
| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | |
It should say:
| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | ___1 | |
Notes:
Based on the context and section 12.5 ending says:
Note that it is not possible to send the following frames in 0-RTT
packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
of these frames in 0-RTT packets as a connection error of type
PROTOCOL_VIOLATION.
So, I think the RETIRE_CONNECTION_ID frame should not appear in the 0-RTT packet, only contained in the 1-RTT package.
Status: Held for Document Update (2)
RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021
Source of RFC: quic (wit)
Errata ID: 7578
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Marten Seemann
Date Reported: 2023-07-30
Held for Document Update by: Zaheduzzaman Sarker
Date Held: 2024-01-29
Section 17.2.1 says:
Where QUIC
might be multiplexed with other protocols (see [RFC7983]), servers
SHOULD set the most significant bit of this field (0x40) to 1 so that
Version Negotiation packets appear to have the Fixed Bit field.
It should say:
Unless the
server has out-of-band knowledge that clients are not
demultiplexing QUIC with other protocols (see [RFC7983]), it
SHOULD set the most significant bit of this field (0x40) to 1 so that
Version Negotiation packets appear to have the Fixed Bit field.
Notes:
Unless operating in a tightly controlled environment, the server has no way of knowing what other protocols the client might be demultiplexing on the same UDP socket. According to the demultiplexing logic defined in RFC 9443, Version Negotiation packets with 0x40 set to 0 would be misclassified as RTP/RTCP.
Looking at the discussion in https://mailarchive.ietf.org/arch/msg/quic/oR4kxGKY6mjtPC1CZegY1ED4beg/ and IETF118 QUIC working group meeting minutes. This needs more discussion to reach a conclusion on the potential solution.
Errata ID: 7374
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Bob Briscoe
Date Reported: 2023-02-27
Held for Document Update by: Zaheduzzaman Sarker
Date Held: 2023-05-29
Section 13.4.1 says:
If an
endpoint does not implement ECN support or does not have access to
received ECN fields, it does not report ECN counts for packets it
receives.
Even if an endpoint does not set an ECT field in packets it sends,
the endpoint MUST provide feedback about ECN markings it receives, if
these are accessible.
It should say:
If an
endpoint does not have access to
received ECN fields, it does not report ECN counts for packets it
receives.
Even if an endpoint does not set an ECT field in packets it sends,
the endpoint MUST provide feedback about ECN markings it receives, if
these are accessible.
Notes:
In the second sentence, the only allowed exception to "MUST provide feedback about received ECN markings" is inaccessibility. The first sentence contradicts this by allowing two exceptions: inaccessibility and just "not implementing ECN support".
If "not implementing ECN support" was really intended to be an allowed exception, the capitalized "MUST" would have been pointless.
Therefore it is proposed that the words "does not implement ECN support or " are deleted from the first paragraph.
NOTE : Based on discussion in https://mailarchive.ietf.org/arch/msg/quic/lsz4X-cZql71Ba56uQhNQz4NzGc/ , the error type is changed from technical to editorial.