RFC Errata
Found 9 records.
Status: Verified (3)
RFC 7413, "TCP Fast Open", December 2014
Source of RFC: tcpm (wit)
Errata ID: 4238
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Luckie
Date Reported: 2015-01-22
Verifier Name: Martin Stiemerling
Date Verified: 2015-11-02
Section 4.1.1 says:
Kind 1 byte: value = 34
Length 1 byte: range 6 to 18 (bytes); limited by
remaining space in the options field.
The number MUST be even.
Cookie 0, or 4 to 16 bytes (Length - 2)
It should say:
Kind 1 byte: value = 34
Length 1 byte: range 2 to 18 (bytes); limited by
remaining space in the options field.
The number MUST be even.
Cookie 0, or 4 to 16 bytes in length (Length - 2)
Notes:
A Nil cookie is a fast open option with no cookie value. A length range of 6 to 18 bytes excludes a Nil cookie.
Errata ID: 4239
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Luckie
Date Reported: 2015-01-22
Verifier Name: Martin Stiemerling
Date Verified: 2015-10-31
Section 4.2.1 says:
1. The client sends a SYN packet with a Fast Open option with a
Length field of 0 (empty cookie field).
It should say:
1. The client sends a SYN packet with a Fast Open option with a
Length field of 2 (empty cookie field).
Notes:
A Nil fast-open option has an option length of 2. A length field of zero would mean an invalid TCP option.
Errata ID: 5373
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vladimir Nicolici
Date Reported: 2018-05-31
Verifier Name: Mirja Kühlewind
Date Verified: 2018-06-14
Section 4.1.3.1. says:
For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and ports) at least temporarily.
It should say:
For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and the destination port) at least temporarily.
Notes:
The original language seems to imply that the cached negative response should only affect connections if they are initiated from the same source port and source IP.
Since the client source port can change for subsequent TCP connections, and it's unlikely that just changing the source port would result in a successful TCP FO connection when a previous connection from a different source port failed, associating the cached negative response with the source port is probably not very useful, and could actually be detrimental to performance and reliability, depending on the implementation.
If the implementation would decide to check the source port when matching negative cached responses to a new connection, it would negatively impact performance when the source port changes, because the implementation wouldn't find a matching negative response in the cache.
Furthermore, if each connection retry is made from a different source port, checking the source port when matching the cached negative responses would make the client unable to connect to the server, until all possible source ports are included in cached negative responses.
This means it's much better not recommending to associate the source port to the cached negative responses, to prevent any confusion and possible implementation issues.
Either that, or add additional clarification, describing exactly how a negative cached response should be matched to a subsequent connection attempt.
Status: Reported (5)
RFC 7413, "TCP Fast Open", December 2014
Source of RFC: tcpm (wit)
Errata ID: 8014
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Bart Overkamp
Date Reported: 2024-07-02
Section 4.2.1 says:
<...> We
RECOMMEND both the client and the server to retransmit SYN and SYN-
ACK packets without the cookie options on timeouts. This ensures the
connections of cookie requests will go through and lowers the latency
penalty (of dropped SYN/SYN-ACK packets).
It should say:
<...> We
RECOMMEND both the client and the server to retransmit SYN and SYN-
ACK packets without the cookie options on timeouts. This ensures the
connection requests will go through.
Notes:
With a retransmitted SYN or SYN-ACK packet without cookie options it does not follow that 'cookie requests' will go through, however 'normal' TCP connection flow does continue. This comes with a latency penalty.
Errata ID: 8015
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Bart Overkamp
Date Reported: 2024-07-02
Section 4.2.2 says:
b. Otherwise, include the Fast Open option with the cookie of the
server. Include any data up to the cached server MSS or
default 536 bytes.
It should say:
b. Otherwise, include the Fast Open option with the cookie of the
server. Include any data up to the cached server MSS or
default: 536 bytes for IPv4 or 1220 bytes for IPv6.
Notes:
default MSS is IP protocol-version-specific
Errata ID: 8016
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Bart Overkamp
Date Reported: 2024-07-02
Section 6.3.3 says:
<...> In fact, power has become such a prominent issue in
modern Long Term Evolution (LTE) devices that mobile browsers close
HTTP connections within seconds or even immediately [SOUDERS11].
It should say:
<...> In fact, power has become such a prominent issue in
3G mobile devices that mobile browsers close HTTP connections
within seconds or even immediately [SOUDERS11].
Notes:
Reading the reference: It mentions 3G exclusively.
3G data networks are circuit-switched so energy consumption on idle connections is an issue.
4G/5G (LTE) networks are packet-switched, and radio energy consumption (active carrier?) might not be an issue. 4G and 5G are not mentioned in the reference.
Errata ID: 8017
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Bart Overkamp
Date Reported: 2024-07-02
Section 3. says:
Performing TCP Fast Open in connection 2: TCP A (Client) TCP B (Server) ______________ ______________ CLOSED LISTEN #1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD #2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD #3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD #4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED #5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
It should say:
Performing TCP Fast Open in connection 2:
TCP A (Client) TCP B (Server)
______________ ______________
CLOSED LISTEN
#1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD
#2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD
#3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD
#4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED
#5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
OR
#2 ESTABLISHED <- <SYN=y,ACK=x+len(DATA_A)+1,DATA_B>- SYN-RCVD
#3 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
Notes:
To include illustration of the flow resulting from step 5 in
section 4.2.2. § Server: Receiving SYN and responding with SYN-ACK
..."The server MAY include data in the SYN-ACK packet
if the response data is readily available. Some applications may
favor delaying the SYN-ACK, allowing the application to process
the request in order to produce a response, but this is left up to
the implementation."
Errata ID: 8013
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bart Overkamp
Date Reported: 2024-07-02
Section 4.2 says:
PendingFastOpenRequests: tracks the number of TFO connections in SYN-
RCVD state. If this variable goes over a preset system limit, the
server MUST disable TFO for all new connection requests until
PendingFastOpenRequests drops below the system limit. This
variable is used for defending some vulnerabilities discussed in
the "Security Considerations" section (Section 5).
It should say:
PendingFastOpenRequests: tracks the number of TFO connections in SYN-
RCVD state. If this variable goes over a preset system limit, the
server MUST disable TFO for all new connection requests until
PendingFastOpenRequests drops below the system limit. This
variable is used for defending against some vulnerabilities
discussed in the "Security Considerations" section (Section 5).
Notes:
The original text seems to suggest defending (the existence of) some vulnerabilities
Status: Rejected (1)
RFC 7413, "TCP Fast Open", December 2014
Source of RFC: tcpm (wit)
Errata ID: 6239
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Simon khng ren hao
Date Reported: 2020-07-27
Rejected by: Martin Duke
Date Rejected: 2020-07-27
Section 5.2 says:
produces responses earlier before the handshake completes
It should say:
produces responses after the handshake completes
Notes:
Located on last paragraph last line of section on page 16. First line states 'not to respond with data until the handshake finishes' which contradicts the last line.
--VERIFIER NOTES--
This erratum does not correctly interpret the paragraph.
The sentence is:
"But the potential latency saving from TFO may diminish if the server application
produces responses earlier before the handshake completes."
The text refers to when the server response is available, not when it is sent. If the server data isn't yet available, then there is no message to withhold and therefore no performance penalty in waiting for the handshake to complete.