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

[Fernando Gont <[e-mail]>]

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?



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



>>>> 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?
> 
> You need to cite RFC1948, and indicate how it affects (or doesn't) your
> solution. It's insufficient to ignore it (i.e., just capture this email
> thread's discussion in text).

Ok, good. Will do.


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

Thanks!

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