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