Re: [tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions

Joe Touch <> Sun, 01 September 2019 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E63831200B6 for <>; Sun, 1 Sep 2019 11:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8oJpT2a0Acm5 for <>; Sun, 1 Sep 2019 11:16:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E7B812007C for <>; Sun, 1 Sep 2019 11:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=hS2eFVYO3wVl9ms9/000QPgRks5OVZ+sdwDlpPqs/0M=; b=3aYVRNzWcGpQhcZIcSvmQph+J vgKN0mWzqumP3FRqyIj9gMGaFe678j7m83ir/M0oJ59U0t3BSnrTYCiGgQqj9LgNTlv6tMtcYwtXA 2QfMYEHk2LJh4nCwAXHe8IdR6rGt3/w2qUX7m47PXaOhnydityw53EJ8RUwkyLra3/qhC8hOGNRVF csyhKqOr3KIAhrg9KD4bzsApitx3LEoc+05umiDVlmQkHr3Wchb6GLzUlWwyRZ81L2VfHs8Dz0aAJ fS1rScgMIQJOP/2covuUY6sm7gJb5IDJNDHyOW/HYgzOazyAhPPyEajm0A7whfcgKTIKjr/0y/t0i Mb/ZQBTDg==;
Received: from ([]:57062 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1i4UOf-000wcx-OU; Sun, 01 Sep 2019 14:16:22 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sun, 1 Sep 2019 11:16:12 -0700
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
X-Mailer: Apple Mail (2.3445.9.1)
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions
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: Sun, 01 Sep 2019 18:16:25 -0000

Some comments below...

> On Aug 28, 2019, at 8:39 AM, Gorry Fairhurst <> wrote:
> ...
> ---
> Section 3 - OLD:
>     Reserved for future use.  Must be zero in generated segments and
>     must be ignored in received segments, if corresponding future
>     features are unimplemented by the sending or receiving host.
> - why is this not an RFC2119 requirement to set and check the reserve fields, this
> would seem much more normal and the receiver behaviour at least is required?
> ---
> Section 3 - OLD:
>     If a
>     segment contains an odd number of header and text octets to be
>     checksummed, the last octet is padded on the right with zeros to
>     form a 16 bit word for checksum purposes.
> - why is this not an RFC2119 requirement to insert the padding, this
> seems required for correctness?

Because padding is only one way to compute the checksum; another is to simply take the final byte and left-shift it. That can be computed without actually inserting a pad.

> ---
> OLD:
>       This option code may be used between options, for example, to
>        align the beginning of a subsequent option on a word boundary.
> - this seems like a RFC2119 "MAY", since it specifies permission to include this.

That code can appear anywhere anyway. It might be useful to reword as “One use this option code is to align subsequent options”
 to a word boundary.”

> ---
> OLD:
>        There is no guarantee that senders will use this option, so
>        receivers must be prepared to process options even if they do
>        not begin on a word boundary.
> -  this seems like a RFC2119 "MUSR", since it specifies requirement to process this.

It would be better to just say up front that “options need not be aligned.” You don’t need to describe all the cases for which receivers MUST succeed. In general “Receivers MUST process any well-formed header”, but that’s already a given (if they didn’t, what’s the point of the whole spec?).

> ...
> ---
> OLD, Section: "   Initial Sequence Number Selection"
> - This I think needs to refer to "Defending against Sequence Number Attacks" in RFC 6528, which formally updated RFC793. I question - if the RFC793 text is safe and correct.

Yes, but as a SHOULD, not a MUST. It’s worth noting that if this is cited.

> - In reviewing this, please also fix "cryptographic has of the concatenation"
> ---
> OLD, Section: "   The TCP Quiet Time Concept"
> - Found this section quite amusing. Is this concept widely implemented in stacks?

This section should be more normative than amusing. It basically helps protect against the same issues as TIME-WAIT when old connections are not known due to a crash.
> ---
> OLD:
>   We assume that the TCP will signal a user,
>   even if no RECEIVEs are outstanding, that the other side has closed,
>   so the user can terminate his side gracefully.

AFAICT, “TCP MUST” make this signal available to the user (but it need not be initiated by TCP), but that’s already covered by the API, which already requires that the user be able to detect this or any other state of TCP anyway (STATUS).