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

[Mark Allman <[e-mail]>]

Catching up, I will chime in with three things ...

  - It still seems to me like we have pretty well converged that the
    draft's value is in terms of the TIME_WAIT truncation scheme.

  - My own opinion is that the draft can simply say "this scheme works
    best with monotonically increasing timestamps" and leave it at
    that.

    I.e., it isn't a strict requirement because the fall-back is just
    what we have without timestamps and if it were a strict requirement
    we'd have to think about flags and such.

    I.e., TCP implementers are smart folks who don't need RFC pages to
    define for them how to generate a monotonic sequence of timestamps
    and so my view is that doing so is useless detail.

  - I agree with Joe's note below that this discussion has led to an
    evolved understanding of the issues and what will be in the draft
    and it'd be nice to see either (a) a new draft from Fernando that we
    can adopt or at least (b) an outline from the chairs that sketches
    a WG document and its major components that can then be filled in by
    some editor.

allman




> The 03 draft focused on creating an algorithm that prevented guess-based
> attacks.
> 
> The discussion, as far as I can tell, has focused on the most peripheral
> part of 03 - the use of TS to cut TIME_WAIT.
> 
> IMO, that's a sufficient change that we're no longer considering a mere
> evolution of 03. The title, abstract, and most of the discussion will
> change.
> 
> Other points need to be addressed, notably:
> 
> 	- are TS values already sufficiently monotonic, or is
> 	an alg needed?
> 
> 	- is per-socketpair state needed to support monotonicity?
> 
> 	- interaction with SYN cookies
> 
> 	- corner cases (when not monotonic, whether that can be
> 	known, when it's supported on only one side, etc.)
> 
> 	- whether this depends on knowing which end will close the
> 	connection first at SYN time
> 
> I don't feel discussion on the mailing list is sufficient to consider
> the entirety of this proposal, and not just whether it's possible, but
> whether it's necessary.