RFC Errata
Found 4 records.
Status: Verified (3)
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
Status: Reported (1)
RFC 5925, "The TCP Authentication Option", June 2010
Source of RFC: tcpm (wit)
Errata ID: 7899
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jean-Michel COMBES
Date Reported: 2024-04-17
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: cut-and-paste error, IMHO, from the previous paragraph