RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (3)

RFC 5925, "The TCP Authentication Option", June 2010

Source of RFC: tcpm (tsv)

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 (tsv)

Errata ID: 6406
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ananth Rajadurai
Date Reported: 2021-01-22

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 (1)

RFC 5925, "The TCP Authentication Option", June 2010

Source of RFC: tcpm (tsv)

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