[atlas] Probe location obfuscation
- Previous message (by thread): [atlas] Probe location obfuscation
- Next message (by thread): [atlas] Probe location obfuscation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Micha Bailey
michabailey at gmail.com
Fri Mar 26 09:50:49 CET 2021
At least where I’m located, MaxMind (and other IP-to-location databases, if there are other ones in the game) don’t get any closer than the country. Regarding the Atlas-set location, I just checked and it turns out that the location pin is right down the street, but I know for a while in the past I had it about a 15 minute drive away for political reasons - the wrong flag was appearing on the info page. On Fri, Mar 26, 2021 at 1:52 AM Steve Gibbard <scg at gibbard.org> wrote: > 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 at 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 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20210326/79822f5a/attachment.html>
- Previous message (by thread): [atlas] Probe location obfuscation
- Next message (by thread): [atlas] Probe location obfuscation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]