Re: [tcpm] Please review RFC 1323bis

Hi David,

thank you for your comment.

As far as I can see, receivers modifying the timestamps as their usage is defined in RFC1323(bis) can really only affect their RTO; either decrease the effective RTO time - leading to increased spurious retransmission timeouts, thus a performance penalty to themselves, or increase the effective RTO time - leading to less timely retransmissions for last resort recovery, again leading to a performance penalty to themselves (assuming the RTTM / RTO mechanism is not severely broken in the sender).

>From what I learned, the linux code switched to internal bookkeeping when CUBIC was developed, because TS got repurposed to provide the Cubic epoch time; by modifying the TSecr values, the receiver could modify the epoch time, which in turn resulted in a much faster ramp-up of the senders cwnd than intended. Thus a receiver could actually gain from that modification.

However, RFC1323(bis) defines timestamps only for two purposes (PAWS, RTTM for RTO). 

So, I agree that there exists an attack vector to the RTTM part of RFC1323, but the outcome will be detrimential to the attacker. 

We do have other drafts in the WG, that deal with timestamps and additional mechanisms using those (draft-scheffenegger-tcpm-timestamp-negotiation and draft-trammell-tcpm-timestamp-interval). I think your concerns are valid, and are discussed in those documents, specifically when timestamps are to be used for mechanisms outside RFC1323 (such as Cubic; Chirp, Ledbat,...).

But perhaps some of the text in those drafts should become part of 1323bis at this time?

Any opinions?

Richard Scheffenegger

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> David Malone
> Sent: Donnerstag, 18. Oktober 2012 17:36
> To: Pasi Sarolahti
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] Please review RFC 1323bis
> 
> I wonder if the text in Section 4.3 needs modification:
> 
>    It is vitally important to use the RTTM mechanism with big windows;
>    otherwise, the door is opened to some dangerous instabilities due to
>    aliasing.  Furthermore, the option is probably useful for all TCP's,
>    since it simplifies the sender.
> 
> I believe that Linux hasn't used the echoed timestamp to calculate RTTs
> for some years (though I haven't looked at the code recently, Matt Mathis
> could probably say). I believe the book-keeping is just done internally,
> as much as possible.
> 
> I also wonder if it is worth mentioning the issue of a reciever who echos
> modified timestamps? If the timestamps are used without sanity checking,
> then the timeout can be controlled by the reciever (without changing the
> actual RTT).
> 
> The security section has some comments on middle boxes that remove
> timestamp options. I don't know if we need to offer any advice on
> scrubbing timestamp options? I haven't heard any problems being caused by
> this, so maybe there is nothing to be said.
> 
> 	David.
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm