Re: [tcpm] WG Last call for draft-ietf-tcpm-tcp-timestamps-00.txt

[Fernando Gont <[e-mail]>]

Hi, Joe,

>> That was probably my fault while splitting the I-D. The discussion had
>> been over non-predictability of timestamps rather than over
>> monotonicity. Do you think it would be okay to add a SHOULD for
>> monotonicity?
> 
> I don't think this document should make recommendations like that. IMO,
> it's more appropriate to consider the impact of non-monotonicity on the
> other recommendations (which should be minor, as you note - they would
> just make the mechanism fail the way it would if not used at all).

Why not? For instance, this was adopted by rfc1323bis....



>>> Further, this doc notes that this is not current practice, so the BCP
>>> track doesn't seem appropriate. It might be more useful to consider this
>>> Informational.
>>
>> It is. Linux does this, for example. And IIRC FreeBSD does this, too.
>> IIRC, only OpenBSD does TCP timestamps randomization in such a way that
>> monotonicity is not guaranteed.
> 
> Then the discussion needs to be updated accordingly, 

Will do.


> and those OS's that
> include this should be noted (as well as those that don't and why).

The reason is probably the same for "why do stacks do predictable ISNs?"


> Also, it'd be useful to explain why some OSs randomize the timestamps
> (if that's for security, 

Yes, the reason is security.

> does it suggest that this mechanism would be
> less useful in the future?)

No, it doesn't. As noted in draft-gont-timestamps-generation, trivial
randomization is probably not the most wise approach to unpredictability.

And OpenBSD also does trivial ISN randomization rather than RFC1948...
not the best possible approach, either.


>>> The doc claims that RFC793 uses ISN generation is based on incrementing.
>>> RFC1948 suggests otherwise, and should be discussed in this context (and
>>> cited).
>>
>> Well, even RFC1948 is based on incrementing... although not in a way
>> that makes ISN predictable for an off-path attacker.
> 
> That needs to be discussed.

What (specifically) do you expect the I-D to discuss? -- Just not that
RFC1948 produces incremental ISNs, or what?



>>> Sec 4.1 has a major heading (4.) that implies there are multiple corner
>>> cases, but only one is described.
>>
>> Yeah, the title is a "mis-title". It tries to address "all corner
>> cases", but this is the only one that has been identified. -- which
>> actually isn't, as noted in the I-D.
>>
>>> This should be cleaned up, or other
>>> corner cases should be added (e.g., as per Alfred's note back in 2009 on
>>> the -00 individual submission)
>>
>> Do you mean I should remove the section? Rename it? Move it to an
>> appendix? Please suggest a way forward....
> 
> I think there are other corner cases from Alfred's 2009 note that could
> be included, and the toplevel heading (4.) could introduce the list,
> which would make the plural still applicable.

I cannot find those corner cases. Could you point out the corner cases
you're referring to?

Thanks!

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