Subject: Re: [tcpm] Questions on draft-scheffenegger-tcpm-timestamp-negotiation-04

From: Brian Trammell <[email-masked]>
Date: Thu, 26 Jul 2012 11:14:00 +0200

greetings, Michael, all,

I've commented on the draft off-list. To continue this discussion though, I wanted to respond on further thought to a few of these points.. (oh, and by way of introduction: Hi! I've lurked in TCPM for a little while; my primary interest in this draft specifically and on the work here in general is in the passive/hybrid measurability of TCP parameters for performance profiling, troubleshooting, and connectivity/bandwidth/latency issue cause analysis.)

On Jul 23, 2012, at 7:23 PM, Scharf, Michael (Michael) wrote:

> * Is there really a need to announce the clock speed in the SYN? We need the SYN for atomic negotiation of features. I could imagine that for the clock speed a post-SYN option could be used as well. Thoughts?
> 
> * I also wonder whether there is some data on how much better explicit signaling of the clock speed is than learning from heuristics (sorry if I should have missed that data).
> 
> * Some thought on security considerations: Can a host mess up a delay measurement by announcing a wrong clock frequency? What would be the implications?

Indeed, I think all of these questions touch on the same issue: if (1) both implementations use a constant-rate TCP timestamp clock (which, the draft seems to assume anyway, many do), (2) both implementations know the rate of their timestamp clock and (3) the error between the desired rate and actual rate is low for some value of "low", then a small number of measurements and not-very-complicated mathematics serves to allow each peer to infer the TS clock rate of each of the other peers it's talking to.

I'm also not aware of published experiments on how well this rate inference would work, but suspect if it exists it's lurking in the references of the pile of papers on my desk I haven't read yet. I've done somewhat related work in recovering precision in truncated timestamp data from NetFlow exports, and that works reasonably well, so i wouldn't expect too many surprises (heh, famous last words).

From a security standpoint, a malicious remote implementation exposing an incorrect TS clock rate would seem to be equivalent to one which erroneously negotiates nonsensical TS clock rate values as in section 5.3 in the current draft -- it can disadvantage the flow from the attacker (kind of a silly attack) or, depending on how the implementation stores rate information, all flows from the attacker's host (a less silly attack -- although, come to think of it, caching clock rates by remote address is a bad idea in a world full of NATs). An implementation that wished to defend against this would have to do rate inference for verification anyway.

All of this falls apart when the rate is explicitly irregular or dynamic, of course. So rate inference would need to have heuristics for detecting when a constant rate wasn't, adding complexity. To _expose_ dynamic TS clock rates, a separate post-SYN option would seem to be necessary.

The other question this raises: while an implementation could certainly use rate inference to enable some of the use cases outlined in Appendix B of the current draft, an implementation that did lost retransmission detection as in B.4, or otherwise corrected RTTM based on inferred remote clock rate wouldn't be RFC1323-compliant, would it? 

> * The draft is a "one-in-a-box" proposal for one-way delay measurement and improved SACK processing. I wonder whether it could make sense to allow separate enablement of those features. For instance, would it make have some benefit if a host just announces its clock frequency but leaves the TS echoing semantics unchanged?

I personally believe splitting the draft into "improved SACK processing (+ extended negotiation mechanism for future use)" and "timestamp rate exposure/inference" makes sense -- if rate inference works, clock rate exposure alone without SACK improvements would seem to be a minimal win, while SACK improvements on their own are more clearly useful. And while we're at it, if that's specified in such a way that conserves bits in the TS SYN option for potential future use, so much the better.

Best regards,

Brian 

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Scheffenegger, Richard
>> Sent: Monday, July 16, 2012 10:53 AM
>> To: tcpm ([email-masked])
>> Subject: [tcpm] FW: New Version Notification for 
>> draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Montag, 16. Juli 2012 10:43
>> To: Scheffenegger, Richard
>> Cc: [email-masked]
>> Subject: New Version Notification for 
>> draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
>> 
>> 
>> A new version of I-D, 
>> draft-scheffenegger-tcpm-timestamp-negotiation-04.txt
>> has been successfully submitted by Richard Scheffenegger and 
>> posted to the
>> IETF repository.
>> 
>> Filename:	 draft-scheffenegger-tcpm-timestamp-negotiation
>> Revision:	 04
>> Title:		 Additional negotiation in the TCP 
>> Timestamp Option field during the TCP handshake
>> Creation date:	 2012-07-16
>> WG ID:		 Individual Submission
>> Number of pages: 34
>> URL:             
>> http://www.ietf.org/internet-drafts/draft-scheffenegger-tcpm-t
>> imestamp-negotiation-04.txt
>> Status:          
>> http://datatracker.ietf.org/doc/draft-scheffenegger-tcpm-times
>> tamp-negotiation
>> Htmlized:        
>> http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-
>> negotiation-04
>> Diff:            
>> http://tools.ietf.org/rfcdiff?url2=draft-scheffenegger-tcpm-ti
>> mestamp-negotiation-04
>> 
>> Abstract:
>>  A number of TCP enhancements in so diverse fields as congestion
>>  control, loss recovery or side-band signaling could be improved by
>>  allowing both ends of a TCP session to interpret the value 
>> carried in
>>  the Timestamp option.  Further enhancements are enabled by changing
>>  the receiver side processing of timestamps in the presence of
>>  Selective Acknowledgements.
>> 
>>  This documents updates RFC1323 and specifies a backwards compatible
>>  way of negotiating for Timestamp capabilities, and lists a 
>> number of
>>  benefits and drawbacks of this approach.
>> 
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 26 Jul 2012 15:25:52 +0000

Hi Brian, Michael,

> >From a security standpoint, a malicious remote implementation exposing an
> incorrect TS clock rate would seem to be equivalent to one which
> erroneously negotiates nonsensical TS clock rate values as in section 5.3
> in the current draft -- it can disadvantage the flow from the attacker
> (kind of a silly attack) or, depending on how the implementation stores
> rate information, all flows from the attacker's host (a less silly attack
> -- although, come to think of it, caching clock rates by remote address is
> a bad idea in a world full of NATs). 

Well, if a sender wishes to have one-way delay variation as input signal, and the receiver tells the sender that its timestamp clock interval runs at 1ms, when in fact it runs at 100ms (or a variable rate), the receiver may be able to tweak the senders congestion control mechanism into sending more data than it would otherwise... 

I think this is a bit different; a nonsensical TS clock rate is clearly an error (and would have the sender revert to RFC1323 mode, not using received TSval for timing purposes - at least it shouldn't use it for that purpose).

The proposed MASK field would allow a sender to protect the integrity of the TSvals - but that (modifying the TSval when inserting it into TSecr) is a different attack than what Michael brings up...

> An implementation that wished to
> defend against this would have to do rate inference for verification
> anyway.

This appears to be the only prudent protection; a slight deviation (e.g. 10ms signaled, but a few samples indicate a "true" timestamp clock of 11ms) needs to be addressed by mechanisms making use of this input signal...

Note that the problems of rate inference (basically assuming that the network conditions don't change during the measurement interval) still have to be addressed...

> All of this falls apart when the rate is explicitly irregular or dynamic,
> of course. So rate inference would need to have heuristics for detecting
> when a constant rate wasn't, adding complexity. To _expose_ dynamic TS
> clock rates, a separate post-SYN option would seem to be necessary.

RFC1323 allows the timestamp to serve as simple packet counter (TSval still monotonic increasing, roughly related to wall time - but with variable intervals). A rate inference algorithm will probably measure RTT during the initial phase of the session as timestamp clock interval...

The other issue with rate inference is that a good probing requires exactly timed sending of packets, and multiple measurements - thus only for longer running sessions a good value can be expected. An explicit (trusted) signal would alleviate this delay...
       
> I personally believe splitting the draft into "improved SACK processing (+
> extended negotiation mechanism for future use)" and "timestamp rate
> exposure/inference" makes sense -- if rate inference works, clock rate
> exposure alone without SACK improvements would seem to be a minimal win,
> while SACK improvements on their own are more clearly useful. And while
> we're at it, if that's specified in such a way that conserves bits in the
> TS SYN option for potential future use, so much the better.

Sounds like a case for a new TS permitted option, plus an optional, reliable, late handshake mechanism?

Best regards,

Richard Scheffenegger

NetApp
[email-masked]
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com  

EURO PLAZA
Gebäude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Trammell
> Sent: Donnerstag, 26. Juli 2012 11:14
> To: [email-masked]
> Subject: Re: [tcpm] Questions on draft-scheffenegger-tcpm-timestamp-
> negotiation-04
> 
> greetings, Michael, all,
> 
> I've commented on the draft off-list. To continue this discussion though,
> I wanted to respond on further thought to a few of these points.. (oh, and
> by way of introduction: Hi! I've lurked in TCPM for a little while; my
> primary interest in this draft specifically and on the work here in
> general is in the passive/hybrid measurability of TCP parameters for
> performance profiling, troubleshooting, and connectivity/bandwidth/latency
> issue cause analysis.)
> 
> > * Is there really a need to announce the clock speed in the SYN? We need
> the SYN for atomic negotiation of features. I could imagine that for the
> clock speed a post-SYN option could be used as well. Thoughts?
> >
> > * I also wonder whether there is some data on how much better explicit
> signaling of the clock speed is than learning from heuristics (sorry if I
> should have missed that data).
> >
> > * Some thought on security considerations: Can a host mess up a delay
> measurement by announcing a wrong clock frequency? What would be the
> implications?
> 
> Indeed, I think all of these questions touch on the same issue: if (1)
> both implementations use a constant-rate TCP timestamp clock (which, the
> draft seems to assume anyway, many do), (2) both implementations know the
> rate of their timestamp clock and (3) the error between the desired rate
> and actual rate is low for some value of "low", then a small number of
> measurements and not-very-complicated mathematics serves to allow each
> peer to infer the TS clock rate of each of the other peers it's talking
> to.
> 
> I'm also not aware of published experiments on how well this rate
> inference would work, but suspect if it exists it's lurking in the
> references of the pile of papers on my desk I haven't read yet. I've done
> somewhat related work in recovering precision in truncated timestamp data
> from NetFlow exports, and that works reasonably well, so i wouldn't expect
> too many surprises (heh, famous last words).
> 
> >From a security standpoint, a malicious remote implementation exposing an
> incorrect TS clock rate would seem to be equivalent to one which
> erroneously negotiates nonsensical TS clock rate values as in section 5.3
> in the current draft -- it can disadvantage the flow from the attacker
> (kind of a silly attack) or, depending on how the implementation stores
> rate information, all flows from the attacker's host (a less silly attack
> -- although, come to think of it, caching clock rates by remote address is
> a bad idea in a world full of NATs). An implementation that wished to
> defend against this would have to do rate inference for verification
> anyway.
> 
> All of this falls apart when the rate is explicitly irregular or dynamic,
> of course. So rate inference would need to have heuristics for detecting
> when a constant rate wasn't, adding complexity. To _expose_ dynamic TS
> clock rates, a separate post-SYN option would seem to be necessary.
> 
> The other question this raises: while an implementation could certainly
> use rate inference to enable some of the use cases outlined in Appendix B
> of the current draft, an implementation that did lost retransmission
> detection as in B.4, or otherwise corrected RTTM based on inferred remote
> clock rate wouldn't be RFC1323-compliant, would it?
> 
> > * The draft is a "one-in-a-box" proposal for one-way delay measurement
> and improved SACK processing. I wonder whether it could make sense to
> allow separate enablement of those features. For instance, would it make
> have some benefit if a host just announces its clock frequency but leaves
> the TS echoing semantics unchanged?
> 
> I personally believe splitting the draft into "improved SACK processing (+
> extended negotiation mechanism for future use)" and "timestamp rate
> exposure/inference" makes sense -- if rate inference works, clock rate
> exposure alone without SACK improvements would seem to be a minimal win,
> while SACK improvements on their own are more clearly useful. And while
> we're at it, if that's specified in such a way that conserves bits in the
> TS SYN option for potential future use, so much the better.
> 
> Best regards,
> 
> Brian
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Scheffenegger, Richard
> >> has been successfully submitted by Richard Scheffenegger and posted
> >> to the IETF repository.
> >>
> >> allowing both ends of a TCP session to interpret the value carried in
> >> way of negotiating for Timestamp capabilities, and lists a number of