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

[Joe Touch <[e-mail]>]

On 9/17/2010 12:28 PM, Fernando Gont wrote:
> 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....

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.

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

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

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

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

See attached.

Joe

--- Begin Message ---

Folks,

I have reviewed the I-D, draft-gont-tcpm-tcp-timestamps-00,
which has been submitted to the WG for consideration.

The basic idea in the draft seems to be so logical and such
an immediate step forward in the spirit of RFC 1122 that,
if the TCP timestamps option already had been defined during
the development of RFC 1122, I suspect that it readily would
have been incorporated and recommended therein!

Besides a small couple of textual flaws and improvement requests
I already have communicated off-list to the author, there seems
to be a double oversight in the second part of the algorithm in
section 3:

a)  There's no "Otherwise, ..." clause.

    Fix: Copy the sibling clause literally from the end of the
    first part of the algorithm to the end of the second part!

b)  The following (potentially rare) corner case, in which it
    would have been possible according to the rules in RFC 1122
    to establish a new connection notwithstanding a previous
    incarnation in the TIME-WAIT state, has not been considered:

    -  old connection didn't use TSO,
    -  new SYN segment with TSO,
    -  local policy / socket options would lead to SYN-ACK without TSO,
    -  new incoming Sequence Number > last corresponding old SN

    Including this case into the second alternative of the second
    part of the algorithm would therefore further improve the benefit
    of the algorithm.

    It might be preferable to make the answer to the question
        'would the new connection be using timestamps?'
    the primary criterion for distinguishing between the first
    and the second alternative in the second part of the algorithm.
    Doing so would allow to simplify the text otherwise necessary
    to describe the preconditions in the second alternative.

    I have submitted ot the author some possible text variants to
    accommodate these considerations and discussed their mutual
    benefit.  For the sake of brevity, I have omitted the details
    here, shortly ahead of a promised update to the draft.

Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm

--- End Message ---