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

Joe Touch <touch@strayalpha.com> Tue, 22 March 2022 13:30 UTC

Return-Path: <touch@strayalpha.com>
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 8E0EB3A1371; Tue, 22 Mar 2022 06:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.328
X-Spam-Level:
X-Spam-Status: No, score=-1.328 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, 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 AiFxuIMTC8Jd; Tue, 22 Mar 2022 06:29:59 -0700 (PDT)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.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 450F03A1501; Tue, 22 Mar 2022 06:28:10 -0700 (PDT)
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-Transfer-Encoding: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=u3igBOO7ytWAuQIOXtHlYcLTxIKpyIVMbF3UXbYtHxU=; b=w/iw4Y8p/stwBQvvvaBl//0rO/ v1z6Dex4/qW8qgfpenlOzQDvfiVJDQq0cx7YCM22iaJxb7ITJm/KyKcpX6eECWd3BKfBvTRAwf2YN OVnhBz33cczpMj2x9zHNJY5Zll8aFibUMsTUfYSW0lIL304wpelLbf17xLDu0sfvW5hC///M9oG2i GEKrBXw7oyHuNgzezsRqd58ZyMIPX2REO247sBJ8L6U8LMv4yptZi/kFU8G1Y83dvikHwnSQXNtdR 8tSazNIWzKD6XYiXb7odzTAY0r3pi1zqnr6OcT/242ap9aHbNn1l+ROCsWjLSkNHsyiXg97K69a7b 3YqPxxoA==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:51786 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 <touch@strayalpha.com>) id 1nWeYP-008DhC-1V; Tue, 22 Mar 2022 09:28:09 -0400
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <20220322105731.GB13021@mit.edu>
Date: Tue, 22 Mar 2022 06:28:03 -0700
Cc: Wesley Eddy <wes@mti-systems.com>, draft-ietf-tcpm-rfc793bis@ietf.org, tcpm@ietf.org, The IESG <iesg@ietf.org>, tcpm-chairs@ietf.org
Message-Id: <86138A85-CA18-44FA-BEA7-50C5BD0341B4@strayalpha.com>
References: <20220322105731.GB13021@mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: iPad Mail (19E241)
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: <https://mailarchive.ietf.org/arch/msg/tcpm/zVWNiIWpWsPQo9AKuF_jPYzcIxg>
Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)
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: Tue, 22 Mar 2022 13:30:04 -0000


> On Mar 22, 2022, at 3:58 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
>>>> On 2/25/2022 4:00 PM, Benjamin Kaduk wrote:
>>>> 
>>> In essence, I think that we require a fairly strong justification to
>>> publish an Internet Standard in 2022 that says it's okay to adopt a data
>>> model where a host has a global piece of state that it freely sends to
>>> anyone who asks, where that piece of state can be used to attack/disrupt
>>> all new connections that host makes, as opposed to just connections on the
>>> 5-tuple that asked.
>> 
>> I agree with Joe's explanation on the applicability of the concern being 
>> a bit more nuanced, since it's important for some things (like BGP 
>> sessions, which 5961 was written in response to), but less so for 
>> shorter-lived connections, hosts that aren't servers, etc.
> 
> I'll quote and reply to Joe (and Michael) later, and while I agree that
> there is more nuance than "randomized ISN MUST be used, always", I don't
> think that we want to be in the habit of making IETF protocols provide
> weaker security properties based on the type of traffic we think they'll be
> conveying.  (Experience has shown that we typically guess wrong, or at
> least incompletely,  when we guess what types of traffic we'll convey.)

It’s not the traffic alone, but the location of the traffic too.

Unless you run a server with connections whose interruption is useful, this is not an attack worth over engineering protection for.  Even for BGP, the primary case of concern, the vulnerability isn’t just from interrupting the connection, but from the incorrect assumption that dropped connections should cause dropped routes. That errant assumption has already been corrected.

A security problem is a combination of a the existence of vulnerability, how easy it is to exploit, how likely it is to occur, and the impact if it does occur. Those four converge in only a very few places, whose operators SHOULD use protection.  But this is not the only protection and we don’t need to complicate TCP everywhere in the name of ‘security’.

If we did, why are you not advocating to require true security (TCP-AO) rather than this halfway measure?   I’m guessing cost and complexity vs benefit. The same argument applies to needing clocks though.

Joe