[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
- [tcpm] [Technical Errata Reported] RFC5925 (8884) RFC Errata System
- [tcpm] Re: [Technical Errata Reported] RFC5925 (8… touch@strayalpha.com
- [tcpm] Re: [Technical Errata Reported] RFC5925 (8… Bonica, Ron