[OpenIPMap] Bringing CAIDA's geoloc efforts into the fold

[Emile Aben]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/06/14 12:07, Robert Kisteleki wrote:
> Hi,
> 
> On 2014.06.18. 11:47, Sebastian Pesman wrote:
>> Hello group,
>> 
>> 
>> Just something I runned into a couple days ago.
>> 
>> Level3 has normally very good PTR records and leave little room
>> for mistakes, but it does happen.
>> 
>> PTR for *2001:1900:4:3::2c5* Resolves to
>> *xe-10-1-0.bar1.Madrid.Level3.net 
>> <http://xe-10-1-0.bar1.Madrid.Level3.net>.*
>> 
>> However, this router is located in Miami, not in Madrid.
> 
> Such things happen. The intention here is to geolocate IPs, not
> names, so once we know where that IP is, we're golden. (Assuming it
> does not move.)

Names, RTTs and 'location in traceroute' are all important indicators.

I do have some prototype code that potentially weeds out wrong
crowdsourced/guessed locations for IPs based on the source-location of
a traceroute and the RTT to that IP.
Given 2/3 speed of light in fiber, for every 1ms in an RTT, the signal
can travel at a maximum 100km round-trip.

So in Sebastian's case the traceroute started in Miami, and had < 1ms
RTT to 2001:1900:4:3::2c5 , so 2001:1900:4:3::2c5 is less then 100km
from Miami (and in a Level3 PoP), so certainly not in Madrid.

I know Daniel Karrenberg (also on the list) is also prototyping
RTT-constraint based geolocation, which would be great to also bring
into the fold.

I think the biggest win currently in OpenIPMap would be to carefully
take RTT based constraints into account, which has the potential of
automatically warning users about situations like the situation
Sebastian describes above.

> In this particular case, it'd be really good if you could tag this
> "name" as being wherever it really is. It may be even better to
> have a means of adding a comment (like "DNS name looks like X but
> it's wrong, it's really Y"). I consider that optional.

Having notes (annotations) on resources is currently not implemented.
I'd also love to have these especially on ASNs/domainnames, for
instance where to find a network map, or other sources of info for
this entity. But also for separate hostnames, in case of weirdness
like Sebastian encountered, so the next person who sees this can
follow the rationale behind why something was crowd-sourced the way it
was.

>> Are there any ideas or plans to detect /( like 80% resolved
>> correctly to IATA / ruleset / other mechanism)/ mismatches and to
>> publish lists or send out notifications or other solutions to
>> inform the PTR holders that there is an error? I would think that
>> at a certain level you can conclude that a certain party has the
>> intention to keep correct PTR records and if so, they probably
>> would like to have these correct as possible thus would be open
>> for pointing out incorrect records.
> 
> Interesting idea. I could imagine this as a function, though I'm
> not sure if this would be more effective than just sending them an
> email...

Yup. Data is open, so anybody could write such a notification system
really.

cheers,
Emile

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlOhfGcACgkQj05ACITZaqopswD/UwYsyjbWGookf2BCjfE10YY6
d1W6l5OKlRuEPDzoqxMA/A7vWF/hFQ7yVoOtrKUnErYmpNUl5xZAuauEY9Pek8Me
=j3Ch
-----END PGP SIGNATURE-----