We have ipinfo at home or how to geolocate IPs in your CLI using latency

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.

[1]: https://old.reddit.com/r/networking/comments/1hkm4g/lets_tal...

[2]: https://news.ycombinator.com/item?id=5319419

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.

https://ping.sx is also a nice comparison tool

> Latency variability is huge ...

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.

What is your path towards 'resolving' these issues?

I've done some mapping while comparing turn servers my org hosted on cloud vms vs a commercial offering, and it's pretty easy to find very different routing from point A to point B, but sometimes it's pretty clearly that not every transit network has access to every submarine cable, so traffic from say Brazil to South Africa might go from Brazil directly to Africa, or it might go to Florida, then Europe, then Africa. It'd be nice to take a more direct route, but maybe the Brazil -> Africa hop doesn't transit all the way, so BGP prefers the scenic route as it has a shorter AS path.

I didn't have any leverage to motivate routing changes though, so other than saying hmm, that's interesting, there wasn't much to do about it.