Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 06 September 2021 07:13 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 1DAB03A2484 for <tcpm@ietfa.amsl.com>; Mon, 6 Sep 2021 00:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 i0TbwjNu-3pd for <tcpm@ietfa.amsl.com>; Mon, 6 Sep 2021 00:13:30 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id CE0C63A2483 for <tcpm@ietf.org>; Mon, 6 Sep 2021 00:13:29 -0700 (PDT)
Received: from [192.168.1.70] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4FA191B0022D; Mon, 6 Sep 2021 08:12:33 +0100 (BST)
Content-Type: multipart/alternative; boundary=Apple-Mail-19DD49AB-89C4-48D7-B433-2EEC4BAB9A41
Content-Transfer-Encoding: 7bit
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Mime-Version: 1.0 (1.0)
Date: Mon, 6 Sep 2021 08:12:29 +0100
Message-Id: <D00D6D29-226C-4C2D-85D2-D133FAF5E27A@erg.abdn.ac.uk>
References: <CAJU8_nXi5=6MD9cvGkd3E3xvF3o=JeR4xw4+x5NphTQxstYGbw@mail.gmail.com>
Cc: Wesley Eddy <wes@mti-systems.com>, tcpm IETF list <tcpm@ietf.org>
In-Reply-To: <CAJU8_nXi5=6MD9cvGkd3E3xvF3o=JeR4xw4+x5NphTQxstYGbw@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
X-Mailer: iPad Mail (17E262)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/z5awC8IpqMAwbrE4ycwDDyVbVe0>
Subject: Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24
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, 06 Sep 2021 07:13:36 -0000


> On 5 Sep 2021, at 18:34, Kyle Rose <krose@krose.org> wrote:
> 
> 
>> On Sun, Sep 5, 2021 at 12:51 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>> To me, this has a much more complicated history, and I think TCP has been extended many times - albeit not sucessfully in the ways mentioned above, but in other watys. It seems like a discussion of whether ossification has been good or bad. I'd also really quite concerned to see words like "often" used without clarifying further -  there are legitimate cases where filtering can be useful for managing the security of TCP connections: A firewall in one context might do many things, and that might actually be a good security model; in another context that might be different. 
>> 
> I'm not in favor of making a value judgment or discussing the wisdom of approaches to addressing ossification in this document, but I do think, given the rare opportunity of publishing a 793bis, that it's worth putting the implications of TCP ossification in writing so we don't have to relitigate these issues or explain in detail why such-and-such won't work whenever they come up in future attempts to extend TCP. I guess I'm arguing that we shouldn't need Joe Touch to explain multiple times to multiple groups why a given proposal won't work when we can explain it once and mic-drop a one-line reference to that.
> 
>> I'd also question the importance of https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it, in relation to the core TCP spec, even though the message is clear for MPTCP.
>  
> This is why I put it in a parenthetical. It's not directly relevant to TCP, but it does indicate to the interested reader an approach that newer protocol designs have taken to avoid one of the causes of ossification. I agree it's not essential.
> 
> Kyle
> 
Thanks for the reply. Seems like you and Wes converged on something slimmer. You could cite RFC 9065, if you wanted another ref. 

Best wishes,
Gorry