HTTP/3 spin bit [pdf] | Hacker News Reader

HTTP/3 spin bit [pdf]

github.com

55 pointsangrygoat19 comments

Some context: https://blog.apnic.net/2018/03/28/just-one-quic-bit/ (discussed on HN at https://news.ycombinator.com/item?id=16695816).

Another fingerprint vector, with location leak.

"generally lacks required precision" well, generally, you combine measurement vectors to obtain required precision.

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

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.

But each packet is numbered, why can't one use the ACK of the numbered packet instead?

I was thinking the same thing, though maybe QUIC doesn't send acknowledgements on every packet?

I think you get this information for free as part of TCP.

That's the answer, almost all of QUIC is encrypted for privacy and protection against meddling middleboxes and protocol evolution. ACKs can be done in many ways which should enough reason for them to be protected so middleboxes doesn't stop protocol evolution.

You understand this is an encrypted protocol right?

A router or other node in the network that's just moving these packets can't decrypt them, so it can't tell the "ACK of the numbered packet". The spin bit lets such a node estimate the round trip time anyway because it will "spin" between set and unset on each round trip.

Why does an intermediate node (ie. not the endpoint) need to know the RTT?

Troubleshooting seems to be an especially popular reason to want this, but I understand some traffic management strategies want to measure RTT also under normal use.

Has anyone tested this out on a real network?

I imagine that it won't work at all when you combine something like 3G (with random periods of hundreds of milliseconds of no packets delivered and them all queueing up), with a little packet reordering.

The 'spin' will end up measuring half, 1/3, or 1/4 the original RTT. The issue won't resolve until the connection ends up idle for at least 1 RTT.

Page 6 talks about this.

On the upside it probably doesn't need to work on 3G anyways. The reason being if your spins are out of order and coming in 300ms chunks you probably aren't worried about troubleshooting the latency anymore, you've been made aware the connection is never going to be high quality, that the delay is low-300ms depending on chunking interval, and that you have packet reordering.

Reply on news.ycombinator.com