Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

"" <> Thu, 23 September 2021 03:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 443E53A1C35; Wed, 22 Sep 2021 20:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FFYm39jH-2OF; Wed, 22 Sep 2021 20:51:30 -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 88B273A1C43; Wed, 22 Sep 2021 20:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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=zdYqlWJhm4pkS1481ukVy/67Tszc7qL8nzUCK8SrEFw=; b=jlNyHwA0z6IgpxFpO/ETqE5FUQ w51CJad7BAUsDKVtlyJWqwkPvTl4HvyzD6sGmG8bwiL6o02npC0mjQJjE3lVi9Vu6OKinSFHew62j 83DPYOXlxvghGFo8CQ/VGNC203MUuhGQOTlOiCnFzuPU+4ux7T4DT7h1vUsQ/ce5P8qmtxvFpgKah Lxqk5yn+q9TfaLfKyiVrLtx82uXxOsHngTLeQPSGiJAInKWG2DF0SBA5yHTsdbqYmCvuUVcylggTs oiYoFW34/0ezS9UG5iDfYK8/qrrwsM4eHYP3PaWz+Tq3ZEn1d5YvPVvO9ckNpH6zr62FIjog4m0Wo ahuXCEKA==;
Received: from ([]:62178 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1mTFlZ-001GWo-Uu; Wed, 22 Sep 2021 23:51:28 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_C631C7AA-ADD2-4981-B737-CC0253D5B42B"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: "" <>
In-Reply-To: <>
Date: Wed, 22 Sep 2021 20:51:15 -0700
Cc: The IESG <>,, " Extensions" <>,
Message-Id: <>
References: <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3654.
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] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)
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: Thu, 23 Sep 2021 03:51:36 -0000

Some comments below...
Joe Touch, temporal epistemologist

> On Sep 22, 2021, at 8:34 PM, Benjamin Kaduk via Datatracker <> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-tcpm-rfc793bis-25: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Many thanks for taking on the task of producing a roll-up update for the
> core TCP specification!  I am sure it was a lot of work, but I am happy
> to see it done.
> That said, I do have a few points that I would like to have a bit more
> discussion on before the document is published; I'm happy to see that
> Warren already linked to
> on the topic
> of what a DISCUSS position can (and cannot) mean.
> (1) We incorporate some long-standing enhancements that improve the
> security and robustness of TCP (in particular, random ISN and protection
> against off-path in-window attacks come to mind), but only at SHOULD or
> MAY requirements level.
> For example, we currently say:
>   A TCP implementation MUST use the above type of "clock" for clock-
>   driven selection of initial sequence numbers (MUST-8), and SHOULD
>   generate its Initial Sequence Numbers with the expression:
>   ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
> and:
>         +  RFC 5961 [37] section 5 describes a potential blind data
>            injection attack, and mitigation that implementations MAY
>            choose to include (MAY-12).  TCP stacks that implement
>            RFC 5961 MUST add an input check that the ACK value is
>            [...]
> What prevents us from making a MUST-level requirement for randomized
> ISNs?  Is it just the fact that it was only a SHOULD in RFC 6528 and a
> perception that promoting to a MUST would be incompatible with retaining
> Internet Standard status?

I’ll take a stab at this issue...

This update does not attempt to change existing IETF consensus. 

In this particular case, AFAIR it allows implementations to not need random number generators, notably for IoT support and legacy hardware. However, in every case, there are long threads in the archives for the RFCs that were ‘rolled in’ here that explain the reason why those recommendations became consensus. That consensus was not re-adjucated during this process.

> Likewise, what prevents using stronger normative language (e.g., MUST)
> for the RFC 5961 protections?

Because those are not always relevant to all implementations either; this is already noted in that RFC as well.

Again, same overall reason - this RFC does not attempt to re-adjudicate existing IETF consensus.