5 ms·

Even without the spin bit it is possible to obtain at least one RTT sample per observed connection, simply by observing the initial handshake, the spin bit does

by ihlar 7y ago

Even without the spin bit it is possible to obtain at least one RTT sample per observed connection, simply by observing the initial handshake, the spin bit doesn't add any meaningful information from a location perspective. An endpoint that wants to obfuscate its location could simply add a bit of artificial jitter. Here's a paper by Brian Trammell where he investigates how well RTT information can be used for geolocation: https://github.com/britram/trilateration/blob/master/paper.ipynb https://github.com/britram/trilateration/blob/master/paper.i...

irl_ 7y ago
I worked with Brian Trammell when he wrote this, and I maintain that it missed something. The assumption is that you have no idea about the path that the data has traveled, but if you actually did know the topology of the larger transit routes and of the end-user's ISP, the "distance" that you're using for your calculations is different. It's no longer just the distance on the map, but the path along fibers and cables. I believe that by combining the topology information with the RTT data you can get a far more precise location. I also maintain that you can get all the information you need from active measurement, and that adding leaks to live traffic just so you can save that active measurement overhead is irresponsible.
- irl_ 7y ago
  An active measurement example: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/pingmesh_sigcomm2015.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
jakeogh 7y ago
It adds samples, increasing resolution. There wont be a jitter option for most people. It's way more than a bit of information that's getting added. https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-is-bufferbloat-a-privacy-issue-brian-trammell-00 https://datatracker.ietf.org/meeting/102/materials/slides-10...
- ihlar 7y ago
  Sure, the spin bit allows for buffer bloat detection, just like icmp ping does when used actively. Just like stated in the material you share, the best way to mitigate this issue is to remove bufferbloat in the network. There are great easy to configure AQMs nowadays, and servers can do their part by using congestion control algorithms that are less prone to cause excessive buffering e.g Googles BBR.
  - jakeogh 7y ago
    The issue is being set in stone with the spin bit, bufferbloat or not. It's an always on path signature.
londons_explore 7y ago
>An endpoint that wants to obfuscate its location... could just not ever set the spin bit.
- cesarb 7y ago
  > could just not ever set the spin bit. That works until middleboxes start requiring that the spin bit is set. As I commented in the earlier discussion linked above: "You do know that someone somewhere is going to make a middlebox that just drops a packet unless that bit flipped in the precise sequence that the middlebox developer believed was the correct one, right? Then someone proposes an enhancement to QUIC which happens to change the sequence of the flips (perhaps some multipath thing, or an enhancement in the way it treats reordered packets), and it breaks... "
- ihlar 7y ago
  Indeed. But it will still expose its initial handshake RTT.

by ihlar 7y ago

irl_ 7y ago

I worked with Brian Trammell when he wrote this, and I maintain that it missed something. The assumption is that you have no idea about the path that the data has traveled, but if you actually did know the topology of the larger transit routes and of the end-user's ISP, the "distance" that you're using for your calculations is different. It's no longer just the distance on the map, but the path along fibers and cables. I believe that by combining the topology information with the RTT data you can get a far more precise location. I also maintain that you can get all the information you need from active measurement, and that adding leaks to live traffic just so you can save that active measurement overhead is irresponsible.

irl_ 7y ago
An active measurement example: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/pingmesh_sigcomm2015.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...

jakeogh 7y ago

It adds samples, increasing resolution. There wont be a jitter option for most people. It's way more than a bit of information that's getting added. https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-is-bufferbloat-a-privacy-issue-brian-trammell-00 https://datatracker.ietf.org/meeting/102/materials/slides-10...

ihlar 7y ago
Sure, the spin bit allows for buffer bloat detection, just like icmp ping does when used actively. Just like stated in the material you share, the best way to mitigate this issue is to remove bufferbloat in the network. There are great easy to configure AQMs nowadays, and servers can do their part by using congestion control algorithms that are less prone to cause excessive buffering e.g Googles BBR.
- jakeogh 7y ago
  The issue is being set in stone with the spin bit, bufferbloat or not. It's an always on path signature.

londons_explore 7y ago

>An endpoint that wants to obfuscate its location... could just not ever set the spin bit.

cesarb 7y ago
> could just not ever set the spin bit. That works until middleboxes start requiring that the spin bit is set. As I commented in the earlier discussion linked above: "You do know that someone somewhere is going to make a middlebox that just drops a packet unless that bit flipped in the precise sequence that the middlebox developer believed was the correct one, right? Then someone proposes an enhancement to QUIC which happens to change the sequence of the flips (perhaps some multipath thing, or an enhancement in the way it treats reordered packets), and it breaks... "
ihlar 7y ago
Indeed. But it will still expose its initial handshake RTT.