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

Wesley Eddy <> Thu, 23 September 2021 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 074AD3A0B58 for <>; Thu, 23 Sep 2021 08:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y9Ucqz5rygJM for <>; Thu, 23 Sep 2021 08:16:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9AE193A0B57 for <>; Thu, 23 Sep 2021 08:16:23 -0700 (PDT)
Received: by with SMTP id m7so6357996qke.8 for <>; Thu, 23 Sep 2021 08:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xgJPBujMyxognzzXkAdHdPVSvfxGCC2bag7ES7GaL8E=; b=3gvdYu+pwBRgxg0a24ENE+TJD+/ekQPr2LTeYQmnbDmLzLc8MuRaB5lub0M8f0FjDB F2zCj5NSgwDzUimJAKdkxkfxlQG9AXE64cA0cNyS9tIPhLwWus3JDAAmGDegIWGv2ugw OpwpF1QoD3uk07qYt+BYdNnJUzfZmm6P+9h0hyNy9lmcVuNdUzOgjqiItOl6iSr8Z+sy HKHoGpDj6L4xolJlOqNhvkC2gvNNnKmExdrvT1z/3Am3iRtT55qpLpISWOePe/7mCss7 kCbn/KcRtzHrCK16srWg+QLnaBsBMDHPZaP6+yr+n43tjQI5FxhQKXGfEJndzZ216F44 Wtjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xgJPBujMyxognzzXkAdHdPVSvfxGCC2bag7ES7GaL8E=; b=HM3IMObjT7Gmjp60V6qDCzOXl/78AksRL+IE3iRWOZwEuwpNdynekLd/vpwS+/HVNb FCcC1oDRgninLWqLxEmksH0PdNCJ6sKY1OV170kYoqK24yCV7Q+qIcuE6oUdw+ZOGRCH VddPUHBw8x70XkaT87JaIYD+uDfASdQaTA99wS/oXA92DUAwTchq9SRahRTy8o6GKdQl WcdZRFMihMeNcX5hDLN3fya4wgNDyaqIQYfLUEJ3POkHD4H73T5/DGJj6d+cGmlj5xc9 sJdgbgcGrQCa+pGHalvuhTKaRTEiXb/zqUdlRicUka3bW60l/eUKSCH04SPBzZ6hyZAm Fnhg==
X-Gm-Message-State: AOAM5328wNqApWCPPHkE28A38eFPZQSACFJ7oFiI7huqJHsbcYzfGFox H/a1F/4sk2YvvDD6O/8dNTXF3A==
X-Google-Smtp-Source: ABdhPJwREKptOHNaChxufQFX4cM0J2To5+s5RtZJXtKGtr09mVgBE7IwNqPyqECBzD8yv1VubObTpw==
X-Received: by 2002:ae9:ed58:: with SMTP id c85mr5399943qkg.440.1632410182235; Thu, 23 Sep 2021 08:16:22 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u9sm4273578qke.91.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Sep 2021 08:16:21 -0700 (PDT)
To: Benjamin Kaduk <>, The IESG <>
Cc:,,, Michael Scharf <>
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Thu, 23 Sep 2021 11:16:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------E382642F9B930CAED1F5A58E"
Content-Language: en-US
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 15:16:27 -0000

On 9/22/2021 11:34 PM, Benjamin Kaduk via Datatracker wrote:
> (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 don't think a MUST for the specific expression used to generate a 
random ISN is necessary since there could be other expressions that 
suffice, and there is no interoperability concern as this is totally 
local to the host.

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

At the time 5961 was published there were both concerns with the IPR as 
well as alternative approaches to achieving the needed robustness, and 
the working group explicitly decided on the requirements language after 
a lot of discussion.

> (2) I think this is just a process question to ensure that the IESG
> knows what we are approving at Internet Standard maturity, though it
> is certainly possible that I misunderstand the situation.
> In Section 3.7.3 we see the normative statement (SHLD-6) that "when the
> when the effective MTU of an interface varies packet-to- packet, TCP
> implementations SHOULD use the smallest effective MTU of the interface
> to calculate the value to advertise in the MSS option".  This seems to
> originate in RFC 6691 (being obsoleted by this document), but RFC 6691
> is only an Informational document and has not had an opportunity to
> "accumulate experience at Proposed Standard before progressing", to
> paraphrase RFC 6410.

In this case, I believe what 6691 says is in accordance with what widely 
deployed code has done for a long time.

I would not make too much of the fact that it's Informational, as it 
wasn't changing the protocol at all, simply providing clarifications and 
correction to mis-statements in older RFCs.

> Similarly, Section 3.9.2 has (SHLD-23) "Generally, an application SHOULD
> NOT change the DiffServ field value during the course of a connection
> (SHLD-23)."  This is a bit harder to track down, as the DiffServ field
> was not always known by that name.  I actually failed to find a directly
> analogous previous statement of this guidance (presumably my error), and
> thus don't know if it had any experience at the PS level or not.

Actually this is prior advice that was widely discussed in the IETF and 
went into RFC 7657 (and the sections referenced in the clip below 
explain why in greater detail):

    o  Should use a single DSCP for all packets within a reliable
       transport protocol session (e.g., TCP connection, SCTP
       association) or DCCP connection (see Sections5.1  <>  and5.3  <>).

> (3) This is also a process point for explicit consideration by the IESG.
> Appendix A.2 appears to discuss a few (rare) scenarios in which the
> technical mechanisms of this document fail catastrophically (e.g.,
> getting stuck in a SYN|ACK loop and failing to complete the handshake).
> Does this meet the "resolved known design choices" and "no known
> technical omission" bar required by RFC 2026 even for *proposed*
> standard?

The TCPM WG has discussed these issues in the past, the referenced I-D 
explains the effect in the real-world and how it's been mitigated in 
different OSes.  There hasn't been consensus that anything needed to be 

> (4) Another point mostly just to get explicit IESG acknowledgment
> (elevating one of Lars' comments to DISCUSS level, essentially).
> As the changelog (and gen-art reviewer!) notes:
>     Early in the process of updating RFC 793, Scott Brim mentioned that
>     this should include a PERPASS/privacy review.  This may be something
>     for the chairs or AD to request during WGLC or IETF LC.
> I don't see any evidence to suggest that such a review actually
> occurred.  Do we want to seek out such a targeted review before
> progressing?

I don't think it occurred.  It was a suggestion at the time when it 
seemed like the IETF wanted to do this for all or most documents, but it 
doesn't seem like that has continued, and in this case, I'm not 
personally clear that there is a lot of value, since this is not a new 
protocol and we haven't added any new mechanisms, options, etc. in this 
particular document that would really motivate specific review.