5 ms·

The only universal fix I can think of for this class of attacks is to have routers bound latency to a lower limit (eg. 200ms), with fixed latency buckets (eg. 5

The only universal fix I can think of for this class of attacks is to have routers bound latency to a lower limit (eg. 200ms), with fixed latency buckets (eg. 500ms granularity) when it goes beyond that. That is, no traffic would traverse the router in less than 200ms, and every other flow would be fixed at 700ms, 1200ms, 1700ms, etc amounts of latency. Tweaked correctly that would limit location to continent, unless I'm missing something. It would effectively trade quick responses to/from close networks for some extra amount of privacy (in the case that GeoIP has already been taken care of) The latency would have to be controlled on both ingress and egress to account for internal and external threats. I've got a niggling feeling that an attacker that could control latency of enough geographically diverse networks could find the boundary by manipulating responses to get finer detail, but can't quite work the problem into a solution... Is there a less horrible or more reliable universal mitigation that I'm not thinking of?

andrewstuart2 6y ago
I find that interesting, because you could probably classify physical location revelation attacks with other timing-based attacks for which we've had to resort to constant-time algorithms (e.g. key protection via constant-time cryptographic operations). There's an interesting fundamental tradeoff somewhere between optimization and information. If you make things as efficient as possible, you'll probably leak information.
- jerrysievert 6y ago
  > If you make things as efficient as possible, you'll probably leak information. at which point the threshold could lower ...
skybrian 6y ago
One problem might be with latencies right at the boundary between two buckets. A bit of jitter would let you know you're near the edge with enough sampling. And if you can add a little latency then you can move the boundary where you like. It seems like the only way to avoid that is with one bucket (constant time).
- stagas 6y ago
  Even if it's one bucket, isn't it still vulnerable to the same attack you describe? If you push the latency to the edge, you'd know how much is yours and how much the bucket's. Even if it was randomized you could still figure out the window of the added noise with enough sampling and you're back to where you started. I don't see a way out, other than if someone really wants to avoid these types of attacks, then using a VPN is the best bet here.
jrockway 6y ago
To some extent, this already happens. My cable modem adds about 30ms latency no matter the destination. I think this is a combination of buffer bloat (wait for buffer to fill before talking on the network) and waiting for a transmit time slot (shared access to the physical layer). I haven't looked at it in detail, but it is very surprising to me that I get 60ms RTT to Blizzard's servers in Chicago (a speed of light distance of 4ms one way) and 25-40ms ping to Google (in what they call "lga15", which is somewhere in Manahttan, probably 60 Hudson). I realize that ping is a very poor benchmark as most routers do not handle ping in their fast path, but it's not adding 40ms of latency. So I suspect my modem.
- dannyw 6y ago
  This is extremely unusual to me. Personally I notice it when my ping to local game servers go from 5 to 25. I’d recommended you look into it, and potentially get another modem. If all my requests started taking another 30ms, I’d consider my network degraded.
  - jrockway 6y ago
    Seems like everyone with any cable ISP has this problem. It could be a modem problem, but it's happened with a variety of modems. It could be an ISP problem, but both Comcast and Spectrum users see the same thing in my experience. I'd be interested in hearing counterexamples, but I imagine that people with good experiences are on DSL or Fiber.
    - zrm 6y ago
      I can ping 1.1.1.1 right now at 12-15ms, or Google at around 20ms, via Comcast. Less than 10ms to either one on Optimum. But it's 25-30ms to ping Optimum from Comcast.
  - lxgr 6y ago
    On a congested upstream, DOCSIS unfortunately seems to behave like this due to contention for and the insufficient granularity of upsteam transmission timeslots. This effectively means that even if your share of the total upstream link of a network "collision domain" (shared coaxial medium really) is low (i.e you're using less than 1/n and accordingly should not be experiencing queueing in the modem), you might be seeing latency spikes due to having to compete and wait for transmission timeslots. My local DOCSIS link is experiencing anything between 0 and 60 milliseconds of latency which I suspect is mostly due to this (since it's inversely correlated to upstream bandwith).
cortesoft 6y ago
I am confused... this attack doesn't seem to be doing anything with latency?
- stagas 6y ago
  You are right, it is only pinpointing the DNS server of the client, which usually resides in the same city, so you can find where the victim lives. It is inferred from the conversation here though that one could potentially exploit this even further to perform ping trilateration and get a better accuracy on one's location using the method described in the article. I think this spawned the comment about the timing attacks.

andrewstuart2 6y ago

I find that interesting, because you could probably classify physical location revelation attacks with other timing-based attacks for which we've had to resort to constant-time algorithms (e.g. key protection via constant-time cryptographic operations). There's an interesting fundamental tradeoff somewhere between optimization and information. If you make things as efficient as possible, you'll probably leak information.

jerrysievert 6y ago
> If you make things as efficient as possible, you'll probably leak information. at which point the threshold could lower ...

skybrian 6y ago

One problem might be with latencies right at the boundary between two buckets. A bit of jitter would let you know you're near the edge with enough sampling. And if you can add a little latency then you can move the boundary where you like. It seems like the only way to avoid that is with one bucket (constant time).

stagas 6y ago
Even if it's one bucket, isn't it still vulnerable to the same attack you describe? If you push the latency to the edge, you'd know how much is yours and how much the bucket's. Even if it was randomized you could still figure out the window of the added noise with enough sampling and you're back to where you started. I don't see a way out, other than if someone really wants to avoid these types of attacks, then using a VPN is the best bet here.

jrockway 6y ago

To some extent, this already happens. My cable modem adds about 30ms latency no matter the destination. I think this is a combination of buffer bloat (wait for buffer to fill before talking on the network) and waiting for a transmit time slot (shared access to the physical layer). I haven't looked at it in detail, but it is very surprising to me that I get 60ms RTT to Blizzard's servers in Chicago (a speed of light distance of 4ms one way) and 25-40ms ping to Google (in what they call "lga15", which is somewhere in Manahttan, probably 60 Hudson). I realize that ping is a very poor benchmark as most routers do not handle ping in their fast path, but it's not adding 40ms of latency. So I suspect my modem.

dannyw 6y ago
This is extremely unusual to me. Personally I notice it when my ping to local game servers go from 5 to 25. I’d recommended you look into it, and potentially get another modem. If all my requests started taking another 30ms, I’d consider my network degraded.
- jrockway 6y ago
  Seems like everyone with any cable ISP has this problem. It could be a modem problem, but it's happened with a variety of modems. It could be an ISP problem, but both Comcast and Spectrum users see the same thing in my experience. I'd be interested in hearing counterexamples, but I imagine that people with good experiences are on DSL or Fiber.
  - zrm 6y ago
    I can ping 1.1.1.1 right now at 12-15ms, or Google at around 20ms, via Comcast. Less than 10ms to either one on Optimum. But it's 25-30ms to ping Optimum from Comcast.
- lxgr 6y ago
  On a congested upstream, DOCSIS unfortunately seems to behave like this due to contention for and the insufficient granularity of upsteam transmission timeslots. This effectively means that even if your share of the total upstream link of a network "collision domain" (shared coaxial medium really) is low (i.e you're using less than 1/n and accordingly should not be experiencing queueing in the modem), you might be seeing latency spikes due to having to compete and wait for transmission timeslots. My local DOCSIS link is experiencing anything between 0 and 60 milliseconds of latency which I suspect is mostly due to this (since it's inversely correlated to upstream bandwith).

cortesoft 6y ago

I am confused... this attack doesn't seem to be doing anything with latency?

stagas 6y ago
You are right, it is only pinpointing the DNS server of the client, which usually resides in the same city, so you can find where the victim lives. It is inferred from the conversation here though that one could potentially exploit this even further to perform ping trilateration and get a better accuracy on one's location using the method described in the article. I think this spawned the comment about the timing attacks.