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

[Joe Touch <[e-mail]>]

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

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