From nobody Mon Dec 27 09:52:04 2021 Return-Path: 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 ; 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 ; 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 ; 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 ) 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" In-Reply-To: Date: Mon, 27 Dec 2021 09:51:45 -0800 Cc: Carsten Bormann , rs@netapp.com, tcpm@ietf.org, braden@isi.edu, t petch , Van Jacobson , david.borman@quantum.com, RFC Errata System 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> <6DDBA952-F80F-4A40-B387-7CB975FA0AC2@tzi.org> To: Yaakov Stein 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2021 17:52:02 -0000 --Apple-Mail=_3BE869EF-F63A-455E-85CB-F1456E3271BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 They are interoperability issues as follows: > The Timestamps option may appear in any data or 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=E2=80=99t appear =E2=80=9Cclose=E2=80=9D = 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 =E2=80=94 Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 26, 2021, at 11:34 PM, Yaakov Stein = wrote: >=20 > None of the three cases I called out will cause interop problems, but = they open potential security or privacy issues. >=20 > But the lack of interop concerns did not dictate capitalization in = other cases, such as=20 > A TSecr value received in a segment MAY be used to update > the averaged RTT measurement=20 > which is a purely local matter. >=20 > Y(J)S >=20 > On Mon, Dec 27, 2021 at 8:08 AM Carsten Bormann > wrote: > > On 2021-12-27, at 06:16, Yaakov Stein > wrote: > >=20 > > In any case, the same RFC uses the normative "MAY" in several other = places,=20 > > so these are probably mistakes. > >=20 > > For example,=20 > > The three-byte Window Scale option MAY be sent in a segment = by a TCP. > > and > > This option MAY be sent in an initial segment. > > =20 > > So why=20 > > 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? >=20 > Is this an interoperability =E2=80=9CMAY=E2=80=9D, i.e., does the peer = need to be prepared for this behavior? The other two clearly are, while = this seems like local matter. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_3BE869EF-F63A-455E-85CB-F1456E3271BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80= =99t appear =E2=80=9Cclose=E2=80=9D 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

=E2=80=94
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> = wrote:
> On 2021-12-27, at 06:16, Yaakov = Stein <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 =E2=80=9CMAY=E2=80=9D, i.e., does the peer = need to be prepared for this behavior?  The other two clearly are, = while this seems like local matter.

Gr=C3=BC=C3=9Fe, Carsten


_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_3BE869EF-F63A-455E-85CB-F1456E3271BB--