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

[Fernando Gont <[e-mail]>]

Joe,

> The 03 draft focused on creating an algorithm that prevented guess-based
> attacks.

No. Version -03 focuses on creating an algorithm such that timestamps
are monotonically-increasing. Another property of the algorithm is that
timestamps are hard to guess. Finally, the doc proposes an algorithm for
improved handling of SYN segments.

See the abstract. It's not a "protecting TCP against blid attacks via
tcp timestamps" at all.



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

Peripheral? Please compare the length of Section 2 and Section 3. Most
of the I-D is about processing SYN segments, rather than about
generating timestamps.



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

I disagree. But won't continue arguing on this one. You have apposed to
this I-D since the thread was started. Hopefully the chairs have noted
that. But hey have also noted the rest of the people, that did support it.



> Other points need to be addressed, notably:
> 
> 	- are TS values already sufficiently monotonic, or is
> 	an alg needed?

What's "sufficiently monotonic"? There's no requirement for
monotonically-increasing timestamps across connections.



> 	- is per-socketpair state needed to support monotonicity?

Obviously not. It *is* useful for the algorithm currently proposed in
the I-D.



> 	- interaction with SYN cookies

Note sure what you mean. Obviously, if timestamps are "on", you can take
advantage of this. If not, no.



> 	- corner cases (when not monotonic, whether that can be
> 	known, when it's supported on only one side, etc.)

This has all been clarified.



> 	- whether this depends on knowing which end will close the
> 	connection first at SYN time

I have already clarified this. It doesn't matter who ends-up closing the
connection.



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

Joe, you have been opposed to this I-D, are opposed to this I-D, and
will be opposed to this I-D. Point taken.

Can the rest of us, if we agree, get some work done?

P.S.: Again, nobody is shipping the I-D for publication as an RFC. So
don't expect the I-D to be perfect at this point.

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