Hacker News Reader

Comment by ihlar | Hacker News Reader

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

View on HN

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.

An active measurement example: https://www.microsoft.com/en-us/research/wp-content/uploads/...

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

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.

The issue is being set in stone with the spin bit, bufferbloat or not. It's an always on path signature.

>An endpoint that wants to obfuscate its location...

could just not ever set the spin bit.

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

Indeed. But it will still expose its initial handshake RTT.

Reply on news.ycombinator.com