I have a file that I generate a few times a day with the MaxMind locations of all the probe addresses.

It would be pretty trivial to run that against the official probe locations and generate a list of suspicious locations, but I don’t generally bother as I’m not sure what I would do with the data.

When I’ve spot checked differences, Maxmind has seemed more frequently correct than the Atlas data (at least for eyeball networks), but both are far from perfect.

I suspect you’d find the latency method below to be pretty inaccurate as well.  If latency from a known-location probe were low, that would tell you something definitive, but if it were high it might just be telling you that the local ISPs in a region don’t talk to each other locally.  Maxmind et al. have hopefully already done a bunch of that work.

-Steve
Global Traceroute

> On Mar 25, 2021, at 6:02 AM, Massimo Candela <massimo@us.ntt.net> wrote:
>
> [possibly OT]
>
> In 2018 we found 18 probes which were located so far from reality that the collected RTT towards targets of known locations was faster than the speed of light (I remember we did something about those). I suspect there are some cases more, just below speed of light. But not so many, I believe the vast majority of the probes are all set properly.
>
> With software probes there is also the problem of less users reporting a location at all (I don't have numbers, based on an observation in a past experiment. It may no longer be the case).
>
> I don't remember if there is something similar already in place, but I would suggest a process like:
> - if a probe doesn't have a location, set a location calculated by latency measurements AND ask the user to review the result at is first convenience;
> - for all the probes currently having a location, use latency measurements to mark the one possibly wrong and ask the user for update.
> - overall, use latency measurements to periodically review the probe's location. RTTs can be used to mark obviously wrong locations, without being too restrictive.
>
> For RTTs above a certain amount (the usual 10ms?), deactivate the RTT validation so users are still able to place probes in exotic locations.
>
> I don't think there is a use case for obfuscating probes more than at the city level. And if there is, these probes should be tagged as such.
>
> Ciao,
> Massimo
>
> On 25/03/2021 13:00, Ponikierski, Grzegorz via ripe-atlas wrote:
>> I would add to it additional problem that some hosts obfuscate probe location even more. For example you can find probes which in reality are located in US but are marked as CN or probes which are in reality in Wisconsin but are marked in California. Of course these are extreme cases. I guess most hosts just put a pin with probe location just somewhere around where it's locate as long it's in the same city. I don't remember, as a host of 3 probes, to get any precise recommendations how to mark probe location. Personally I just put a pin in city district where probe is locate.
>> Regards,
>> Grzegorz
>