IP Geolocation with ICMP (ECHO-location)

TL;DR

Network latency is a measure of time, but also a proxy for distance. Using this property, it’s possible to geolocate a server by measuring the round-trip-time (rtt) of packets sent from multiple locations. This post explores that idea, using the AWS public cloud.

As an illustration, mouseover one of the datacenters in the above figure to see how far it’s requests may have travelled to reach www.washington.edu (whose servers are presumably in Seattle, or nearby).

Introduction

I became intested in this topic after reading the the apocryphal case of the 500-mile email,1 which concerns a Sendmail administrator, in Durham, North Carolina, whose users complain that they cannot send email farther than 500 miles. A preposterous limitation.

He determines that Sendmail is aborting connections that take longer than 3 milliseconds to establish. Recalling that the speed of light is 2.998e+8 m/s, 3 ms equates to roughly 560 miles. Roughly the distance cited in the users’ reports!

I’ve always liked this story; I suspect because computer networks are often very abstract, and layer 1 can feel a long way down. Revisiting it recently, I began thinking about other uses of the same principle, and geolocation in particular.

A First Experiment

I am writing this from a desk in Seattle, but what if I didn’t know that? Could I establish my own location if I were amnesiac and unwilling to ask? What if I only had Ping and a map of the world?

To get started I borrowed a list of public IP addresses associated with various AWS regions from the EC2 Reachability Test2, and plotted the distance suggested by the least measured rtt from my desk to each one.3

This experiment places me within 921 miles of AWS’ us-west-2 region. An answer that’s neither wrong, precise, nor all that bad.

Around The World In 6.912e+9 Milliseconds

The global presence of cloud services like AWS, GCP, and Azure makes it both inexpensive and convenient to test latency from various points around the world.

The map below presents a sample of datacenters from AWS and Google Cloud Platform with the caveat that they may be slightly misplaced, because their precise locations aren’t always known. (Or, aren’t known to me.)

What’s needed, now, is a mechanism for launching vm instances in a selection of these datacenters. Terraform4 provides this, serving as a kind of Make for cloud infrastructure; and one that supports multiple vendors.

In a follow-up post, I’ll pursue this idea, using Terraform to manage instances in multiple public clouds at once, to measure latency from various points around the world. Stay tuned…

Comment and Suggestion to patrick.mcmurchie@gmail.com

  1. https://www.ibiblio.org/harris/500milemail.html ↩︎

  2. http://ec2-reachability.amazonaws.com ↩︎

  3. I am using the speed of light in a vacuum (c) multiplied by 2/3 to correct for its slower passage through fiber optic media. ↩︎

  4. I’ve written about Terraform in two previous posts: part one, part two, part three. The project that resulted from these posts is called Blast Radius, and is available on GitHub. ↩︎