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

[Benjamin Kaduk <[e-mail]>]

On Tue, Mar 22, 2022 at 06:28:03AM -0700, Joe Touch wrote:
> 
> 
> > On Mar 22, 2022, at 3:58 AM, Benjamin Kaduk <[e-mail]> 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
"over-engineering"?

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

Thanks,

Ben