RFC Errata
Found 8 records.
Status: Verified (4)
RFC 5925, "The TCP Authentication Option", June 2010
Source of RFC: tcpm (wit)
Errata ID: 4365
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2015-05-12
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16
Section 7.6 says:
TCP's 4-bit data offset requires that the options end 60 bytes (15 32-bit words) after the header begins, including the 20-byte header. This leaves 40 bytes for options, of which 15 are expected in current implementations (listed below), leaving at most 25 for other uses. TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options (depending on implementation dependant alignment padding, which could consume another 2 bytes at most). o SACK permitted (2 bytes) [RFC2018][RFC3517] o Timestamps (10 bytes) [RFC1323] o Window scale (3 bytes) [RFC1323]
It should say:
TCP's 4-bit data offset requires that the options end 60 bytes (15 32-bit words) after the header begins, including the 20-byte header. This leaves 40 bytes for options, of which 19 are expected in current implementations (listed below), leaving at most 21 for other uses. TCP-AO consumes 16 bytes, leaving 5 bytes for additional SYN options (depending on implementation dependent alignment padding, which could consume another 2 bytes at most). o SACK permitted (2 bytes) [RFC2018][RFC3517] o Timestamps (10 bytes) [RFC1323] o Window scale (3 bytes) [RFC1323] o Maximum Segment Size (4 bytes) [RFC793]
Notes:
MSS was missing in the original text. New text includes MSS and updates numbers accordingly.
Also corrects a spelling error (dependant -> dependent), which is non-technical but included in the revised text.
Errata ID: 5672
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2019-03-24
Verifier Name: Mirja Kühlewind
Date Verified: 2020-03-04
Section 6.2 says:
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1;
}
/* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value
} else {
SNE = RCV.SNE; # use the current value
}
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.SNE_FLAG = 0;
}
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;
It should say:
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) {
RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1;
}
/* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fffffff)) {
SNE = RCV.SNE - 1; # use the pre-increment value
} else {
SNE = RCV.SNE; # use the current value
}
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) {
RCV.SNE_FLAG = 0;
}
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;
Notes:
The SNE values are 32 bits; the current pseudocode used 16-bit masks (0x7fff) instead of their 32-bit equivalent (0x7fffffff).
This error was first noted by Tero Kivinen <kivinen@iki.fi>.
Errata ID: 5961
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ron Bonica
Date Reported: 2020-01-22
Verifier Name: Mirja Kühlewind
Date Verified: 2020-01-22
Section 7.4 says:
d. Determine the RNextKeyID as indicated by the rnext_key pointer, and insert it in the TCP-AO RNextKeyID field (using the rnext_key MKT’s RecvID as the TCP-AO KeyID)
It should say:
d. Determine the RNextKeyID as indicated by the rnext_key pointer, and insert it in the TCP-AO RNextKeyID field (using the rnext_key MKT’s RecvID as the TCP-AO RNextKeyID)
Notes:
This was a cut-and-paste error
Errata ID: 7899
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean-Michel COMBES
Date Reported: 2024-04-17
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-05-15
Section 5.2 says:
o Receive_SYN_traffic_key - the traffic key used to authenticate
incoming SYNs. The source ISN is known (the TCP connection's
remote ISN), and the destination (remote) ISN is unknown (and so
the value 0 is used).
It should say:
o Receive_SYN_traffic_key - the traffic key used to authenticate
incoming SYNs. The source ISN is known (the TCP connection's
remote ISN), and the destination (local) ISN is unknown (and so
the value 0 is used).
Notes:
"remote side" is referenced twice: potential cut-and-paste error from the previous paragraph. Errata verified based on the discussion in tcpm mailing list : https://mailarchive.ietf.org/arch/msg/tcpm/wauBdtHFEqtltJUxTo7kdF8msIU/
Status: Reported (1)
RFC 5925, "The TCP Authentication Option", June 2010
Source of RFC: tcpm (wit)
Errata ID: 8884
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ron Bonica
Date Reported: 2026-04-17
Section 6.2 says:
The implementation of SNEs is not specified in this document, but one
possible way is described here that can be used for either RCV.SNE,
SND.SNE, or both.
Consider an implementation with two SNEs as required (SND.SNE, RCV.
SNE), and additional variables as listed below, all initialized to
zero, as well as a current TCP segment field (SEG.SEQ):
o SND.PREV_SEQ, needed to detect rollover of SND.SEQ
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o SND.SNE_FLAG, which indicates when to increment the SND.SNE
o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE
When a segment is received, the following algorithm (in C-like
pseudocode) computes the SNE used in the MAC; this is the "RCV" side,
and an equivalent algorithm can be applied to the "SND" side:
Touch, et al. Standards Track [Page 25]
RFC 5925 The TCP Authentication Option June 2010
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1;
}
/* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value
} else {
SNE = RCV.SNE; # use the current value
}
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.SNE_FLAG = 0;
}
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;
In the above code, the first time the sequence number rolls over,
i.e., when the new number is low (in the bottom half of the number
space) and the old number is high (in the top half of the number
space), the SNE is incremented and a flag is set.
If the flag is set and a high number is seen, it must be a reordered
segment, so use the pre-increment SNE; otherwise, use the current
SNE.
The flag will be cleared by the time the number rolls all the way
around.
The flag prevents the SNE from being incremented again until the flag
is reset, which happens in the middle of the window (when the old
number is in the bottom half and the new is in the top half).
Because the receive window is never larger than half of the number
space, it is impossible to both set and reset the flag at the same
time -- outstanding segments, regardless of reordering, cannot
straddle both regions simultaneously.
It should say:
The implementation of SNEs is specified in RFC 9817.
Notes:
The deleted text includes a buggy version of the SNE algorithm. RFC 9817 specifies a better SNE algorithm.
Implementation that use the RFC 9817 SNE algorithm will be mostly, but not 100% backwards compatible with implementations that implement the deleted RFC 5925 version.
Thanks to Pig Chen for raising this issue.
Status: Held for Document Update (1)
RFC 5925, "The TCP Authentication Option", June 2010
Source of RFC: tcpm (wit)
Errata ID: 6406
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ananth Rajadurai
Date Reported: 2021-01-22
Held for Document Update by: Martin Duke
Date Held: 2021-01-25
Section Section 5.1 says:
In Section 5.1, Figure 6 - TCP IPv6 Pseudoheader +--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Upper-Layer Payload Length | +--------+--------+--------+--------+ | Zero | Next Header | +--------+--------+--------+--------+
It should say:
+--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Upper-Layer Payload Length | +--------+--------+--------+--------+ | Zero |Next Hdr| +--------+--------+--------+--------+
Notes:
In IPv6 pseudoheader, Zero field should be 3 bytes and Next header should be 1 byte.
But in RFC 5925, figure 6, it misleads into Zero field 2 bytes and Next header 2 bytes.
Status: Rejected (2)
RFC 5925, "The TCP Authentication Option", June 2010
Source of RFC: tcpm (wit)
Errata ID: 7135
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Venkatesh Natarajan
Date Reported: 2022-09-16
Rejected by: Martin Duke
Date Rejected: 2022-10-06
Section 7.3 says:
>> A TCP-AO implementation MUST allow for configuration of the behavior of segments with TCP-AO but that do not match an MKT. The initial default of this configuration SHOULD be to silently accept such connections. If this is not the desired case, an MKT can be included to match such connections, or the connection can indicate that TCP-AO is required. Alternately, the configuration can be changed to discard segments with the AO option not matching an MKT.
It should say:
>> A TCP-AO implementation MUST allow for configuration of the behavior of segments with TCP-AO but that do not match any MKT or no MKT is available. The initial default of this configuration SHOULD be to silently accept such connections. In this mode of operation, both the endpoints will not perform TCP-AO validation. If this is not the desired case, an MKT can be included to match such connections, or the connection can indicate that TCP-AO is required. Alternately, the configuration can be changed to discard segments with the AO option not matching an MKT.
Notes:
The RFC does not clearly draw out the distinction between treatment of segments with TCP-AO and without TCP-AO option.
Note that in the case of MKT mismatch as per existing RFC text, if either endpoint does TCP-AO validation, the session would not get established.
--VERIFIER NOTES--
As noted in the email below, when both sides do not have common configuration, the handshake will fail.
Please see https://mailarchive.ietf.org/arch/msg/tcpm/0zG2aP5tGBvbRJxuNOIPFYDK9Jg/
Errata ID: 5347
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ignacio Goyret
Date Reported: 2018-05-03
Rejected by: Mirja Kühlewind
Date Rejected: 2020-03-04
Section 5.1 says:
3. The TCP header, by default including options, and where the TCP checksum and TCP-AO MAC fields are set to zero, all in network- byte order. The TCP option flag of the MKT indicates whether the TCP options are included in the MAC. When included, only the TCP-AO MAC field is zeroed. When TCP options are not included, all TCP options except for TCP- AO are omitted from MAC processing. Again, the TCP-AO MAC field is zeroed for the MAC processing.
It should say:
3. The TCP header and TCP options, where the TCP checksum and TCP-AO MAC fields are always set to zero, all in network-byte order. The TCP option flag of the MKT indicates which TCP options are included in the MAC. When TCP options are not included, only the TCP option for TCP-AO (as described in Section 2.2) is included in the MAC. Otherwise, all the TCP options are included in the MAC.
Notes:
Rewording for clarity and simplification.
The original text could lead to confusion re '...When included, only the TCP-AO MAC field is zeroed.'
--VERIFIER NOTES--
Rejected as the proposed text does not seem fundamentally clearer.