Bit surprised this works. Latency variability is huge and sometimes quite disconnected from geo location. I recall talking to someone in NL and realised I've got better latency to NL content from the UK than he did. Presumably better peering etc.
Yup. For example from my city to one of my dedicated server whose location is fully well-know (in France), I know there's 250 kilometers as the crow flies. Yet if I ping that server and draw a circle around my place (considering ping travels as fast as light in a vaccuum, which we know ain't happening but, hey, it's something) I get a radius of 2000 kilometers. About 8x the distance. I can prove that my IP ain't in the US but that's still not very precise.
And indeed many servers in the UK, which is 2x the distance than my server is, gives me constantly a lower ping.
TFA's approach, especially with the traceroute instead of Ping, is nice.
I work for IPinfo. We are launching a collaborative project with IXPs and major internet organizations to share raw measurement for routing and peering data for this purpose.
Latency variability is a huge issue. We run both traceroute and ping data, and we observe that there are entire countries that peer with IXP thousands of miles away in a different continent.
We bought a server from the oldest telecom company in the country and recently activated it. Currently, there is a 20 ms latency when traffic is directed towards the second oldest telecom. The packets have to travel outside the country before coming back in. This is a common phenomenon that occurs frequently. So, we usually have multiple servers in major cities since various ASNs have different peering policies.
For us we can map those behaviors and have algorithms and other data sources, make measurement-based geolocation perform well.
We are hoping to support IXPs, internet governance agencies, and major telcoms in identifying these issues and resolving them.
How feasible would it be for the host under measurement to introduce additional artificial latency to ping responses, varying based on source IP, in order to spoof its measured location?
Traceroutes are already notoriously hard to interpret correctly[1] and yes, they can be trivially spoofed. Remember the stunt[2] pulled by tpb to move to North Korea? If you are an AS you can also prepend fake AS to your BGP announcements and make the spoofed traceroute even more legitimate.
I wonder if this thing will start a cat and mouse game with VPNs.
Tried with an IP allocated to a major wireless network operator. It was far off but also ran out of credits when trying with higher limits on subsequent attempts.
Seems tool is relying on ICMP results from various probes. So wouldn't this project become useless if target device disables ICMP?
I wonder if you can "fake" results by having your gateway/device respond with fake ICMP requests.
> Globalping is an open-source, community-powered project that allows users to self-host container-based probes. These probes then become part of our public network, which allows anyone to use them to run network testing tools such as ping and traceroute.
If I understood the post the author just takes the location of smallest ping as the winner. This seems like a very rudimentary approach. Why not do triangulation? If you take each ping time as a measurement of distance between two points, you should be able to ping from a random selection of IPs and from there calculate the location.
It'd be clever to integrate this into the TCP stack so it tells you immediately what the lowest bound is on the distance to the counterparty based on the time between data sent and the corresponding acknowledgements. I can see some immediate applications for that.
You can extend this by looking at the IP route for the reverse path, I've found it's usually accurate to the state at least on the last hop before destination - added benefit that there's usually an airport or city code on the fqdn of that hop.
Nice work! I presented similar research at DEFCON 31 - 'You Can't Cheat Time: Finding foes and yourself with latency trilateration'
https://youtu.be/_iAffzWxexA
though with some key differences that address the limitations mentioned in the thread.
The main issue with pure ping-based geolocation is that:
IPs are already geolocated in databases (as you note)
Routing asymmetries break the distance model
Anycast/CDNs make single IPs appear in multiple locations
ICMP can be blocked or deprioritized
My approach used HTTP(S) latency measurements (not ping) with an ML model (SVR) trained on ~39k datapoints to handle internet routing non-linearity, then performed trilateration via optimization. Accuracy was ~600km for targets behind CloudFront - not precise, but enough to narrow attribution from "anywhere" to "probably Europe" for C2 servers.
The real value isn't precision but rather:
Detecting sandboxes via physically impossible latency patterns
Enabling geo-fenced malware
Providing any location signal when traditional IP geolocation fails
Talk: https://youtu.be/_iAffzWxexA"
Great post and a great little tool. Some of my experience using these techniques in production:
1. Trilateration mostly doesn't work with internet routing, unlike GPS. Other commenters have covered this in more detail. So the approach described here - to take the closest single measurement - is often the best you can do without prior data. This means you need a crazy high distribution of nodes across cities to get useful data at scale. We run our own servers and also sponsor Globalping and use RIPE Atlas for some measurements (I work for a geo data provider), yet even with thousands of available probes, we can only accurately infer latency-based location for IPs very close to those probes.
2. As such, latency/traceroute measurements are most useful for verifying existing location data. That means for the vast majority of IP space, we rely on having something to compare against.
3. Traceroute hops are good; the caveat being that you're geolocating a router. RIPE IPmap already locates most public routers with good precision.
4. Overall these techniques work quite well for infrastructure and server IP addresses but less so for eyeball networks.
22 comments
[ 4.2 ms ] story [ 36.3 ms ] threadI had fun making it but please note that the current implementation is just a demo and far from a proper production tool.
If you really want to use it then for best possible results you need at least 500 probes per phase.
It could be optimized fairly easily but not without going over the anon user limit which I tried to avoid
Yup. For example from my city to one of my dedicated server whose location is fully well-know (in France), I know there's 250 kilometers as the crow flies. Yet if I ping that server and draw a circle around my place (considering ping travels as fast as light in a vaccuum, which we know ain't happening but, hey, it's something) I get a radius of 2000 kilometers. About 8x the distance. I can prove that my IP ain't in the US but that's still not very precise.
And indeed many servers in the UK, which is 2x the distance than my server is, gives me constantly a lower ping.
TFA's approach, especially with the traceroute instead of Ping, is nice.
Latency variability is a huge issue. We run both traceroute and ping data, and we observe that there are entire countries that peer with IXP thousands of miles away in a different continent.
We bought a server from the oldest telecom company in the country and recently activated it. Currently, there is a 20 ms latency when traffic is directed towards the second oldest telecom. The packets have to travel outside the country before coming back in. This is a common phenomenon that occurs frequently. So, we usually have multiple servers in major cities since various ASNs have different peering policies.
For us we can map those behaviors and have algorithms and other data sources, make measurement-based geolocation perform well.
We are hoping to support IXPs, internet governance agencies, and major telcoms in identifying these issues and resolving them.
I wonder if this thing will start a cat and mouse game with VPNs.
[1]: https://old.reddit.com/r/networking/comments/1hkm4g/lets_tal...
[2]: https://news.ycombinator.com/item?id=5319419
Seems tool is relying on ICMP results from various probes. So wouldn't this project become useless if target device disables ICMP?
I wonder if you can "fake" results by having your gateway/device respond with fake ICMP requests.
IEEE 802.11mc > Wi-Fi Round Trip Time (RTT) https://en.wikipedia.org/wiki/IEEE_802.11mc#Wi-Fi_Round_Trip...
/? fine time measurement FTM: https://www.google.com/search?q=fine+time+measurement+FTM
How's this different from RIPE ATLAS?
Sometimes residential ISPs (that hosts the probe) may have a bad routing due to many factors, how does the algorithm take that into account?
though with some key differences that address the limitations mentioned in the thread. The main issue with pure ping-based geolocation is that: IPs are already geolocated in databases (as you note) Routing asymmetries break the distance model Anycast/CDNs make single IPs appear in multiple locations ICMP can be blocked or deprioritized My approach used HTTP(S) latency measurements (not ping) with an ML model (SVR) trained on ~39k datapoints to handle internet routing non-linearity, then performed trilateration via optimization. Accuracy was ~600km for targets behind CloudFront - not precise, but enough to narrow attribution from "anywhere" to "probably Europe" for C2 servers. The real value isn't precision but rather: Detecting sandboxes via physically impossible latency patterns Enabling geo-fenced malware Providing any location signal when traditional IP geolocation fails Talk: https://youtu.be/_iAffzWxexA"
1. Trilateration mostly doesn't work with internet routing, unlike GPS. Other commenters have covered this in more detail. So the approach described here - to take the closest single measurement - is often the best you can do without prior data. This means you need a crazy high distribution of nodes across cities to get useful data at scale. We run our own servers and also sponsor Globalping and use RIPE Atlas for some measurements (I work for a geo data provider), yet even with thousands of available probes, we can only accurately infer latency-based location for IPs very close to those probes.
2. As such, latency/traceroute measurements are most useful for verifying existing location data. That means for the vast majority of IP space, we rely on having something to compare against.
3. Traceroute hops are good; the caveat being that you're geolocating a router. RIPE IPmap already locates most public routers with good precision.
4. Overall these techniques work quite well for infrastructure and server IP addresses but less so for eyeball networks.
https://ping.sx is also a nice comparison tool
---
Our research scientist, Calvin, will be giving a talk at NANOG96 on Monday that delves into active measurement-based IP geolocation.
https://nanog.org/events/nanog-96/content/5678/