[tcpm] Re: [Technical Errata Reported] RFC5925 (8884)

["Bonica, Ron" <[e-mail]>]

Fine by me
________________________________
From: [e-mail] <[e-mail]>
Sent: Friday, April 17, 2026 11:50 AM
To: RFC Errata System <[e-mail]>
Cc: Dr. Joe Touch <[e-mail]>; Allison Mankin <[e-mail]>; Ron Bonica <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Bonica, Ron <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (8884)

I believe better corrected text would be:

  The implementation of SNEs is not specified in this document, but one
  possible way is described in RFC 9817.

I don’t think the doc should mandate code.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com<https://urldefense.com/v3/__http://www.strayalpha.com__;!!NpxR!iWiz84sPSymM7ZjqtZQjDCn2D-HQN6wsa_LqTwVH7UqKqffgArpQz0qsOsyrUR-bLQc2YPmNsMumUGtndg$>

On Apr 17, 2026, at 5:06 AM, RFC Errata System <[e-mail]> wrote:

The following errata report has been submitted for RFC5925,
"The TCP Authentication Option".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8884<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8884__;!!NpxR!iWiz84sPSymM7ZjqtZQjDCn2D-HQN6wsa_LqTwVH7UqKqffgArpQz0qsOsyrUR-bLQc2YPmNsMuUETHO7w$>

--------------------------------------
Type: Technical
Reported by: Ron Bonica <[e-mail]>

Section: 6.2

Original Text
-------------
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.

Corrected Text
--------------
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.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11)
--------------------------------------
Title               : The TCP Authentication Option
Publication Date    : June 2010
Author(s)           : J. Touch, A. Mankin, R. Bonica
Category            : PROPOSED STANDARD
Source              : TCP Maintenance and Minor Extensions
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
tcpm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]