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

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 17 April 2026 12:06 UTC

Return-Path: <wwwrun@rfcpa.rfc-editor.org>
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@mail2.ietf.org
Received: from rfcpa.rfc-editor.org (unknown [167.172.21.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D8F5FDE387B2; Fri, 17 Apr 2026 05:06:28 -0700 (PDT)
Received: by rfcpa.rfc-editor.org (Postfix, from userid 461) id BD93AC0004D7; Fri, 17 Apr 2026 05:06:28 -0700 (PDT)
To: touch@isi.edu, mankin@psg.com, rbonica@juniper.net, tcpm-ads@ietf.org, nsd.ietf@gmail.com, tuexen@fh-muenster.de
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20260417120628.BD93AC0004D7@rfcpa.rfc-editor.org>
Date: Fri, 17 Apr 2026 05:06:28 -0700
Message-ID-Hash: CZX4DQIMIUIWKOKJJVPW6GNO6UMXNOEV
X-Message-ID-Hash: CZX4DQIMIUIWKOKJJVPW6GNO6UMXNOEV
X-MailFrom: wwwrun@rfcpa.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tcpm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ronald.bonica@hpe.com, tcpm@ietf.org, rfc-editor@rfc-editor.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [tcpm] [Technical Errata Reported] RFC5925 (8884)
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/bqLKgUfYmPk-IVnb1HH5lDEmM4g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Owner: <mailto:tcpm-owner@ietf.org>
List-Post: <mailto:tcpm@ietf.org>
List-Subscribe: <mailto:tcpm-join@ietf.org>
List-Unsubscribe: <mailto:tcpm-leave@ietf.org>

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

--------------------------------------
Type: Technical
Reported by: Ron Bonica <ronald.bonica@hpe.com>

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