Re: [tcpm] Quick review: scheffenegger-tcpm-timestamp-negotiation

[Bob Briscoe <[e-mail]>]

Richard,

[I've added tcpm to distr - I omitted accidentally first time round.]

At 01:45 26/03/2011, Scheffenegger, Richard wrote:

>Hi Bob,
>
>thank you for your review! It is always 
>beneficial to get a native speaker input on 
>wording - especially if he is as knowledgeable in the topic as you are :)
>
>The first remark I already changed locally to this:
>" A compliant TCP receiver will then XOR the received
>      TSval with the local timestamp options, 
> when responding with the SYN+ACK."

What does "local" mean? May-be I didn't assume 
correctly what you are trying to do in this para at the start of S.4.

Firstly the TCP client must detect whether the 
server has implemented your draft. So it needs to 
see some difference between what an RFC1323 
server would echo and what an updated server would echo.

Secondly, you need to say that you are allowing 
for future extension of the capabilities so you 
are trying to do capability negotiation, to find 
the lowest common denominator capability that the 
two ends support (I think that's what you are doing, anyway).

Lastly, you need to unambiguously say that the 
server puts the result of the XOR in the TSecr of the SYN-ACK.

In fact, this leads to a more more general point: 
the draft needs to start with a more general 
explanation of what the protocol is trying to 
achieve. At the moment one has to reverse 
engineer the intent from the protocol specification.

It would be worth following the layout of RFC4101 
"Writing Protocol Models". This gives guidance on 
how to write a clear protocol description.


>(Although I may need a different referent to 
>"timestamp options" (the extended fields 
>indicating the capabilies; hmm.. perhaps 
>"timestamp capabilities" is be good generic 
>reference to the sum total of all suggested 
>fields in the SYNs (currently I have timestamp 
>option referencing the TCP TS option 
>(TSval/TSecr), and timestamp options referencing 
>to only the new fields; a single character is 
>definitely not enough hamming distance for a casual reader :) ).

Yes, you need a term. I can't suggest one while 
I'm not sure any more what the protocol is trying to do.

How about a terminology section first?

> > Have you tested whether any existing implementations actually check
> > whether the TSecr field is zero in a SYN? I doubt it, but we ought to
> > check.
>
>No; there were some legacy implementations which 
>wouldn't properly clear the TCPCB and the TSecr 
>on the initial SYN would therefore not be zero 
>(I can not find the reference, but it was deemed 
>a potential data leak). But most implementations 
>seem to simply ignore anything in TSecr when 
>receiving a SYN,  and nowadays properly clear TSecr when sending...
>
>The more interesting finding I had is that it 
>appears that even though RFC1323 is quite clear 
>about the use of the TS value during 
>loss/reordering (so the sender should ignore 
>TSecr if a SACK option is present too - as that 
>is a definitive indication of some 
>reordering/loss happening, even though there may 
>not have been any earlier indication to the 
>sender (lost/delayed ACKs), TS processing is 
>completely independent from anything else.
>
>Therefore, a full backwards-compatible 
>implementation is required (ie only enable 
>"opaque, non-monotonic LSBs" and direct 
>mirroring when both ends negotiate this new 
>capability. If they don't, a sender (and 
>receiver) have to revert to RFC1323 behavior. 
>However, as there are a number of reserved bits, 
>the behavior at the presence of an unknown 
>future capabilities field needs to be specified. 
>I would think that at the very least, the direct 
>reflection of the TS value when SACK is present 
>too, should happen always, even if such future 
>capabilities render the TSval completely opaque 
>to a receiver that doesn't understand those.
>
>
>One more question: As these TS capabilities 
>provide additional values / bit fields, is this 
>something that IANA needs to govern? Or is this 
>merely an extension of RFC1323 which does not 
>define any IANA action (as currently mentioned)? 
>(I guess what I'm asking is, when does IANA need to be involved in an RFC?).

Indeed - good point. You are creating a space for 
people to populate in future, so you need to 
register this with IANA to avoid two people 
populating the same part of the space with different things.

Given I now understand you are allowing future 
extension, you need to say what would be a valid 
extension and what not. For instance, are forks 
allowed, or must each extension build on the last?

Cheers


Bob


>And lastly, I think the option is probably 
>incompatible (as is) with TCPCT, if TSecr is 
>used there with the previous sessions last 
>timestamp (I'm not 100% clear on this though, 
>even though it would probably be beneficial also 
>for these 64 / 128 bit timestamps...)
>
>
>Thanks again for your feedback!
>
>Richard Scheffenegger
>
>NetApp
>[e-mail]
>[phone] Office (2143 3146 - internal)
>[phone] Mobile
>www.netapp.com
>
>EURO PLAZA
>Gebäude G, Stiege 7, 3.OG
>Am Euro Platz 2
>A-1120 Wien
>
>
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[e-mail]]
> > Sent: Freitag, 25. März 2011 21:10
> > To: Scheffenegger, Richard; Mirja KUEHLEWIND
> > Subject: Quick review: scheffenegger-tcpm-timestamp-negotiation
> >
> > Richard, Mirja,
> >
> > Nice draft.
> >
> > Have you tested whether any existing implementations actually check
> > whether the TSecr field is zero in a SYN? I doubt it, but we ought to
> > check.
> >
> > Some editorial comments:
> >
> > 4. "A compliant TCP receiver will XOR the flags with the received
> > TSval"
> >
> > I worked it out what you mean, but it's not unambiguous what "the
> > flags" are at this stage (they haven't been called "the flags" yet).
> > I initially thought you meant the control bits in the TCP header (!).
> > And later you call them "the flags and the fields", so do you mean we
> > should XOR with only the 1-bit flags and not the fields?" I assume not.
> >
> > Also, to be unambiguous, you need to be much clearer about which
> > field in which direction you are talking about here, because the
> > names of the fields switch round.
> >
> > p7
> > s/Note that the use of this option as implications/
> >   /Note that the use of this option has implications/
> > s/wraped/
> >   /wrapped/
> >
> > p9
> > s/vulerabilities/
> >   /vulnerabilities/
> >
> >
> > Bob
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design