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

[Fernando Gont <[e-mail]>]

Mark,

I can publish such a rev.

Will split the "timestamps generation" into a separate I-D, and will
address in the current draft those points that needed clarification, etc.

Thanks,
Fernando




Mark Allman wrote:
> 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.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

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