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

[Joe Touch <[e-mail]>]

Hi, Fernando,

On 9/18/2010 11:11 AM, Fernando Gont wrote:
> On 17/09/2010 07:42 p.m., Joe Touch wrote:
>
>>>> 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....
>>
>> I don't see this document as significant motivation on its own for a
>> SHOULD. If you want to remind readers that this is/will be a SHOULD in
>> rfc1323bis, that's fine, but for the reasons cited there.
>
> I don't follow. Why the same requirement would not be appropriate here,
> but *would* in another document?

I'm asking you to answer that question. Is that SHOULD necessary here? 
My concern is that you basically need the majority of clients to change 
their behavior to benefit, and it only benefits some servers (in 
particular, ones with high connection rates to specific hosts).

If you want to say that rfc1323bis recommends it, and this mechanism 
also benefits from it, that's easier to justify.

>>>> 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.
>>
>> My point is that if OS's are doing randomization for security (and since
>> security concerns are increasing, that behavior may be more common),
>> doesn't this undermine your use of the timestamps because you're
>> expecting monotonicity?
>
> No, it doesn't. Just pick a good randomization scheme. Randomization
> does not necessarily mean issuing a random() call. For instance, the
> algorithm that was included in previous versions of this I-D did
> randomization, while still producing a monotonically-increasing sequence
> (a la RFC1948)

So here's the questions again:

- are you expecting randomization for security reasons to be more widely 
deployed?

AFAICT, you didn't answer that.

- does randomization interfere with your mechanism?

Yes, if it isn't also monotonic. I wouldn't characterize it as trivial 
or not; monotonicity is a specific property that has nothing to do with 
randomness directly.

So you might need to say that:

	IF randomization is applied, then this mechanism
	benefits ONLY IF that randomization is also monotonic.

If you want to include an example of such a mechanism in an appendix, 
that would be useful. (but this doc wouldn't be recommending it as a 
SHOULD, just to be clear).

...
>>>>> 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?
>>
>> See attached.
>
> The single point that Alfred raised could probably be included in the
> processing rules already present. -- although it's a very unlikely case,
> so one could consider that as a corner case. -- any preference for any
> particular approach?

Nope.

Thanks,

Joe