Re: [tcpm] [Editorial Errata Reported] RFC7323 (6798)

"touch@strayalpha.com" <touch@strayalpha.com> Mon, 27 December 2021 17:52 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FF53A0FC1 for <tcpm@ietfa.amsl.com>; Mon, 27 Dec 2021 09:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqHStBx6tula for <tcpm@ietfa.amsl.com>; Mon, 27 Dec 2021 09:51:58 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173B13A0FC4 for <tcpm@ietf.org>; Mon, 27 Dec 2021 09:51:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mfqFJb0WJAec/GD7iUJhfmEBevsBy6vKvsqx0xJPlsY=; b=ZSC/B35vVLYGR/ZOoWrPFKKuEi S3ULqpfj8MHqYq1kNtMtaLVqCo/JDG63rkNueWF2aURtxPk3AGUe9raXUWbf3fsRaq7zeMIyRhqdp XolvZWihMT5gah6IK714TnZYGQGIhfuKG2GljKjvwEeyQoFk/f+5LyoDPbBZ8Vu3e9SlvozXWLrHi U4tB2vyRkPHxzNNfvpyiwoDEkyUfEe58KhrCC313rEUrN7hFWKtOFKCc8/WKKIo1LLPuku/DVMOca L5AvryH5W0sciejUCxJoiivJ7JtEmqozCAO0J1sR2ZsD+cKJEB7rE+YBfJ4yaha2seckbsIK+7lkI vb/nUOCA==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:55988 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1n1uA3-00HFhg-Sj; Mon, 27 Dec 2021 12:51:56 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_3BE869EF-F63A-455E-85CB-F1456E3271BB"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <CAE8H3+A7eFxHD5E2on2Cf=U78so8Bb-V7ayBoDo-zuUKXuVdbA@mail.gmail.com>
Date: Mon, 27 Dec 2021 09:51:45 -0800
Cc: Carsten Bormann <cabo@tzi.org>, rs@netapp.com, tcpm@ietf.org, braden@isi.edu, t petch <ietfa@btconnect.com>, Van Jacobson <vanj@google.com>, david.borman@quantum.com, RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <0C73598B-89FA-4350-9286-64474BF1AE47@strayalpha.com>
References: <20211226085938.97471F0F1F@rfc-editor.org> <61C84CAD.8040300@btconnect.com> <5152DC2D-1E40-4011-94D7-EE7CBB851C6E@tzi.org> <CAE8H3+C20vdT0ei4SU2zWtYunvi_TgzGwx97Q9QnrkzoT5hUqw@mail.gmail.com> <6DDBA952-F80F-4A40-B387-7CB975FA0AC2@tzi.org> <CAE8H3+A7eFxHD5E2on2Cf=U78so8Bb-V7ayBoDo-zuUKXuVdbA@mail.gmail.com>
To: Yaakov Stein <yaakovjstein@gmail.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/PATP8t6AKycQNM6X-7A60QFDtIY>
Subject: Re: [tcpm] [Editorial Errata Reported] RFC7323 (6798)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Dec 2021 17:52:02 -0000

They are interoperability issues as follows:

> The Timestamps option may appear in any data or <ACK> segment, adding

This implies that receivers MUST NOT treat segments with missing or present timestamps as an error.

> The timestamp clock may be derived from a system clock that is

This implies that receivers MUST NOT treat timestamps that look like the current time as an error, e.g., they MUST NOT assume the timestamp starts at a random offset.

> A random offset may be added to the timestamp clock on a per-

This implies the converse of the previous, i.e., that the receiver MUST NOT treat timestamps that don’t appear “close” to their current value as an error.

This is why RFCs MUST (IMO) indicate a rationale whenever keywords are used - especially for wiggle-words (MAY, SHOULD and their converses), noting particularly where exceptions are known appropriate.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 26, 2021, at 11:34 PM, Yaakov Stein <yaakovjstein@gmail.com> wrote:
> 
> None of the three cases I called out will cause interop problems, but they open potential security or privacy issues.
> 
> But the lack of interop concerns did not dictate capitalization in other cases, such as 
>   A TSecr value received in a segment MAY be used to update
>   the averaged RTT measurement 
> which is a purely local matter.
> 
> Y(J)S
> 
> On Mon, Dec 27, 2021 at 8:08 AM Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
> > On 2021-12-27, at 06:16, Yaakov Stein <yaakovjstein@gmail.com <mailto:yaakovjstein@gmail.com>> wrote:
> > 
> > In any case, the same RFC uses the normative "MAY" in several other places, 
> > so these are probably mistakes.
> > 
> > For example, 
> >   The three-byte Window Scale option MAY be sent in a <SYN> segment by a TCP.
> > and
> >   This option MAY be sent in an initial <SYN> segment.
> >  
> > So why 
> >   A random offset may be added to the timestamp clock on a per-connection basis.
> > ?
> > Is this may to be considered weaker than the other two?
> 
> Is this an interoperability “MAY”, i.e., does the peer need to be prepared for this behavior?  The other two clearly are, while this seems like local matter.
> 
> Grüße, Carsten
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm