Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03

[Fernando Gont <[e-mail]>]

Mark Allman wrote:

> This document really has two parts: (1) a mechanism that provides a
> random starting point for timestamps based on a hash of the 4-tuple and
> some secret sauce and (2) a mechanism for TIME-WAIT truncation based on
> observed timestamps on subsequent connections involving the same
> 4-tuple.  However, these two items are really not related at all---other
> than that they both involve timestamps.

The relationship is that (2) needs timestamps that are
monotonically-increasing across connections. (1) provides a scheme that
complies with such requirement and that also has the good property that
it makes it hard for an off-path attacker to guess the timestamps in use
by victim connections.



> It seems from our on- and off-list discussion that both of us find (2)
> useful.  But, it doesn't depend on (1) at all.  Further, I believe we
> both find (1) to be dubious (there seems to be not much security benefit
> and there are concerns about storage & computation (more Joe's than
> mine, but)).

32 bits of additional state for each connection is such a big deal?



> So, a compromise proposal could be to take (2) as a work item and
> jettison (1).  I personally would support a (2)-not-(1) document more
> strongly than the current version.
> 
> Or, at least perhaps we could see more motivation for (1) that would
> sway us to understanding the tangible benefit it offers.

Using unpredictable values is acting pro-actively. If we, say, propose
to have a global counter for generating the timestamps, at some point
we'll be re-hashing the same type of discussion we've had for "in
window" attacks, but for TCP timestamps.

Actually, at least part of this discussion has already taken place:
there's a CERT advisory on predictable timestamps (I think I referenced
it in the I-D), and some implementations have chosen to trivially
randomize the timestamps (i.e., "just call "random()"), which does not
allow (2) to work - most likely because they didn't want predictable
timestamps, but didin't have any other option at hand.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1