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

Benjamin Kaduk <> Wed, 23 March 2022 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 526D43A171E; Wed, 23 Mar 2022 06:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j9RW7pikvVp7; Wed, 23 Mar 2022 06:47:43 -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 6E2B23A157B; Wed, 23 Mar 2022 06:47:27 -0700 (PDT)
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 22NDlJUG007444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Mar 2022 09:47:24 -0400
Date: Wed, 23 Mar 2022 06:47:18 -0700
From: Benjamin Kaduk <>
To: Joe Touch <>
Cc: Wesley Eddy <>,,, The IESG <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
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: Wed, 23 Mar 2022 13:47:49 -0000

On Tue, Mar 22, 2022 at 06:28:03AM -0700, Joe Touch wrote:
> > On Mar 22, 2022, at 3:58 AM, Benjamin Kaduk <> 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.

RFC 3552 is pretty clear that we should design for a threat model where the
attacker controls the communication channel.  That's obviously game over
for plain TCP as it stands, but even in a limited threat model as 3552 also
considers, we can imagine an attacker that can easily read everywhere but
only write to packets in select locations.  So an attacker that knows the
location of the traffic seems in scope to me.

> 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.

Could you clarify which parts of my proposed text you see to be

> 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’.

Similarly, could you clarify which parts of my proposal you see as
"complicat[ing] TCP everywhere"?

> 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.

I'm happy to advocate requiring true security, but not as part of a "bis"
of the core TCP specification at the Internet Standard maturity level.
Such a revision of the core specification has stringent requirements
for backwards compatibility that are clearly not met for TCP-AO at the
present time.  If we come back in a decade, maybe the situation will be
different, but it's clearly not feasible right now.

I'd appreciate hearing any concrete comments you have on my specific
proposed text.