RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 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: 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.

Report New Errata



Advanced Search