On 24/04/2019 19:20, Ponikierski, Grzegorz wrote: > Thanks everybody for comments and interest :) > > > > When it comes to security and spammers I think that you can approach to > it like to any PM feature available on any message board. I think it's > natural for any community to be able to communicate with each other. > After all RIPE Atlas is a community of networking geeks/nerds/engineers > who like to measure the Internet and share resources with others. > Sometimes we just need to exchange some info to get help and mailing > lists is not always the best way to do it. I don't think it's a serious > security threat but I also find comments from Martin Boissonneault quite > helpful to build something as much secure as possible without excessive > complexity. > > > > When it comes to location of probes, Steve Gibbard probably described > the real problem more precisely than me. The goal is to get reliable > data about probes location and this is for sure important for all RIPE > Atlas users. One way is to poke people manually and it's OK if you have
As someone who uses RIPE Atlas at scale, i fully agree. Probe location accuracy is an important data quality issue in RIPE Atlas. Wrongly located probes are a big source of weirdness in things like ixp-country-jedi ( https://www.ripe.net/analyse/internet-measurements/ixp-country-jedi ). > to do it once per few months but it would be better to get more > automated detection mechanism for that. Steve uses IP geolocation which > has its limitations (I know probes with IPs from country X but they are > properly deployed and described in country Y on different continent). I > personally visualize distance from probe to target and compare it with > RTT and hops but it's still not fully automated and still can be tricky > and requires additional checks. I've also seen the limitations of (Maxmind) geolocation. and i would say it's very hard to find good guidelines on when Maxmind geolocation is better or worse then what probe hosts provide. > So open question is: How to reliably verify location of probes OR How to > motivate RIPE Atlas users to provide valid locations and keep it up-to-date? What i've seen for many cases of incorrectly geolocated probes is that this was caused by probes being physically moved (because the person hosting the probe moved to a different city, possibly country). One thing i've briefly looked into is if we can use a change of ASN that we see the probe in as an indicator that the probe host should be sent a reminder to check if the probes geolocation is still correct. This turned out messier then i thought (too many probes seem to cycle through two or more ASNs), but we can revisit this idea and see if we can make this work as part of a process to counter wrongly geolocated probes. Another thing i looked into is using similarity between probes as an indicator of wrong geolocation. Intuition is that if 2 probes see the same IP path to a destination, they are probably topologically close to each other, which typically means they are physically close (but not always, eg. tunnels). So if we see 2 probes that are topologically close, but physically very distant, that probably means either a wrong geolocation or an 'interesting' setup of one of the probes. See table 1 (and text below) of https://archive.psg.com/170602.anrw17-paper9.pdf hope this helps, Emile
