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

["[e-mail]" <[e-mail]>]

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 23, 2022, at 6:47 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Tue, Mar 22, 2022 at 06:28:03AM -0700, Joe Touch wrote:
>> ...
>> It’s not the traffic alone, but the location of the traffic too.
> 
> RFC 3552 is pretty clear that we should design for

That document describes how to write *security considerations*. It is not a protocol design recommendation.

Note also that. 3552 also overlooks key issues in threat assessment (more later below).

> a threat model where the
> attacker controls the communication channel.  

I think that underscores the issue. You seem to think we are designing a security protocol.

I do not.

>> 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"?

You gave a very long update but didn’t highlight or explain the specific changes. 

Of the text you gave:

  To avoid confusion we must prevent segments from one incarnation of a
  connection from being used while the same sequence numbers may still
  be present in the network from an earlier incarnation.  However, the
  design of the TIME-WAIT state means that actual information about
  previously used sequence numbers will be discarded, and a robust
  system will provide some protection against processing segments from
  a previous incarnation of the connection even when such
  sequence-number state has been discarded or lost (e.g., due to restart).
  The procedure for selecting an initial sequence number (ISN) for an
  instance of a connection needs to be designed so as to minimize the
  likelihood of sequence number reuse for that connection.  This
  procedure also needs to account for the security issues that result
  if an off-path attacker is able to predict or guess ISN values [43],
>> break inserted to show change
  as a special case of the attacks possible by guessing in-window
  sequence number values at any point in a connection's lifecycle.
>> That last sentence is incorrect. Here’s a fix:

  which can enable an off-path attacker to attack a connection
  by predicting in-window sequence numbers shortly after the connection starts,
  if the attacker knows the connection socket pair.

>> knowing the ISN does no good after the window moves on.
>> and knowing the socket pair is also required

  The logical independence of sequence numbers across connections,
  combined with the ease with which an attacker can probe the ISN
  generation algorithm on an individual connection and data
  minimization best practices, implies that ISN generation should
>> add
also
>>
  produce unrelated values for different connections at any given point
  in time.

  Within a given connection, the likelihood of sequence number reuse is
  minimized by ensuring that the full space 
>> majority of the space, not the full space
  of potential ISN values is
  exhausted before reusing any individual ISN value.  In keeping with
  RFC 793, this specification achieves that behavior using a number
  sequence that monotonically increases until it wraps, known loosely
  as a "clock".  This clock is a 32-bit counter that typically
  increments at least once every roughly 4 microseconds, although it is
  neither assumed to be realtime nor precise, and need not persist
  across reboots.  The clock component is intended to ensure that within
  a Maximum Segment Lifetime (MSL), generated ISNs will be unique,
  since it cycles approximately every 4.55 hours, which is much longer
  than the MSL.

  The combined properties of connection independence and clock
  dependence of ISNs can be achieved with only a small amount of
  per-implementation state by combining a global clock with a
  pseudorandom function of the connection identifiers and a secret key;
  the following procedure from [43] SHOULD be used for ISN selection:

  ISN = M + F(secretkey, localip, localport, remoteip, remoteport)

  where M is the 4 microsecond timer, and F() is a pseudorandom
  function (PRF) of the connection's identifying parameters ("localip,
  localport, remoteip, remoteport") and a secret key ("secretkey")
  (SHLD-1).  F() MUST NOT be computable from the outside (MUST-9), or
  an attacker could still guess at sequence numbers from the ISN used
  for some other connection.  The PRF could be implemented as a
  cryptographic hash of the concatenation of the TCP connection
  parameters and some secret data.  For discussion of the selection of
  a specific hash algorithm and management of the secret key data,
  please see Section 3 of [43].

>> the following section goes overboard:
  In cases where the above procedure is not used, the selection of
  initial sequence numbers for a connection still MUST incorporate a
  clock-driven update as described above into its generation of initial
  sequence numbers (MUST-8).
>> The above effectively changes the SHOULD to a MUST.

>> ——

RFC 3552 talks about threat assessment, but does not even mention the probability of an attack. 

For ISNs, this all boils down to the probability that an attacker
	- knows IP addresses 
	- knows port pair
	- but is off-path

An on-path attacker can just read the ISN as it flies by.

Off path attacks aren’t typically aimed at arbitrary endpoints; they are targeted to well-known services, esp. between known pairs. BGP is the typical case, and there are not really a lot of others.

And BGP needs to be protected with TCP-AO or IPsec, IMO.

So all of this is “security theater” that has no impact on most users, except to complicate implementations.

>> 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 was trying to use hyperbole to prove a point. I am not advocating true security for the core of TCP either.

Joe