Re: [atlas] Overuse of software probes

[Emile Aben]

Emile Aben, I would be happy to see code for detecting overly similar 
probes. It would save a lot of time spend on data filtering.




These are snapshots of data for probe similarity detection [1] in IPv4 
and IPv6


https://sg-pub.ripe.net/emile/probe-similarity/probe_similarity_ipv4-2022-06-29.csv
https://sg-pub.ripe.net/emile/probe-similarity/probe_similarity_ipv6-2022-06-29.csv

This calculates 3 similarity values between 0 and 1 (the last 3 values 
in the csv). Pick the middle one if you don't care about the details.


There are 54k probe-pairs with similarity values over 0.5,
7.4k with value over 0.95
6.7k with value over 0.99

My gut feeling is that anything over 0.95 is likely very redundant for 
many types of measurements.


There seems to be a cluster of about 400 probes that are very similar to 
each other, and a couple of smaller clusters too.


Happy to work with you and others to see if we can make this into 
something that is operationally valuable.


kind regards,
Emile Aben
RIPE NCC

[1] Holterbach, Thomas, et al. "Measurement vantage point selection 
using a similarity metric." Proceedings of the Applied Networking 
Research Workshop. 2017.

https://trac.ietf.org/trac/irtf/export/478/www/content/anrw/2017/anrw17-final9.pdf


--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Overuse of software probes

[Emile Aben]

Hi Grzegorz,

I've encountered similar problems and have done some research in 
potential solutions. One of them is calculating how similar probes are, 
and then using this in probe selection (ie. use probes that are as 
dissimilar as possible). For your particular use case, the 15 software 
probes in Sao Paolo would likely be 100% similar to each other, which 
can be taken into account with probe selection (or in the data analysis 
if you already took measurements).


I have some prototype code for this laying around, I will see if we can 
produce something useful out of this.


We are currently also collaborating with some talented researchers on 
structurally looking into the bias of measurement infrastructures (see 
https://labs.ripe.net/author/pavlos_sermpezis/bias-in-internet-measurement-infrastructure/ 
). I hope some of the future results of that will also help with 
estimating and dealing with all kinds of measurement biases.


kind regards,
Emile Aben

On 2022-03-31 20:15, Ponikierski, Grzegorz via ripe-atlas wrote:


Hello all!

Software probes is great improvement for Atlas environment and it made 
deployments so much easier and more scalable. One of my probes is also 
software probe on Raspberry Pi. However, me and my team noticed that 
sometimes software probes are overused and make measurements more 
cumbersome to interpret. For example we found that there 4 software 
probes in AWS Johannesburg [1] and 15 software probes in Hostinger Sao 
Paulo [2]. That's total overkill. These 15 probes in Hostinger Sao 
Paulo is 21% of all connected probes in Brazil. All of them delivers 
practically the same results so without additional data filtering 
(which is not easy) they can dramatically skew final results for Brazil.


With this I would like to open discussion how to handle this 
situation. Please share your thoughts about these questions:


  * How can we standardize data filtering for such case?
  * How to proactively and automatically detect overuse of probes?
  * How can we encourage software probes hosts to avoid deployments in
data centers which are already covered by Atlas?
  * How to give incentives to deploy probes in data centers without
existing probes?

[1] 4 software probes inside AWS Johannesburg:

1000707 <https://atlas.ripe.net/frames/probes/1000707/>

1001397 <https://atlas.ripe.net/frames/probes/1001397/>

1002066 <https://atlas.ripe.net/frames/probes/1002066/>

1002632 <https://atlas.ripe.net/frames/probes/1002632/>

[2] 15 software probes inside Hostinger Sao Paulo

1003554 <https://atlas.ripe.net/frames/probes/1003554/>

1003555 <https://atlas.ripe.net/frames/probes/1003555/>

1003556 <https://atlas.ripe.net/frames/probes/1003556/>

1003557 <https://atlas.ripe.net/frames/probes/1003557/>

1003558 <https://atlas.ripe.net/frames/probes/1003558/>

1003559 <https://atlas.ripe.net/frames/probes/1003559/>

1003560 <https://atlas.ripe.net/frames/probes/1003560/>

1003561 <https://atlas.ripe.net/frames/probes/1003561/>

1003562 <https://atlas.ripe.net/frames/probes/1003562/>

1003563 <https://atlas.ripe.net/frames/probes/1003563/>

1003564 <https://atlas.ripe.net/frames/probes/1003564/>

1003565 <https://atlas.ripe.net/frames/probes/1003565/>

1003566 <https://atlas.ripe.net/frames/probes/1003566/>

1003567 <https://atlas.ripe.net/frames/probes/1003567/>

1003568 <https://atlas.ripe.net/frames/probes/1003568/>

Regards,

Grzegorz Ponikierski





--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Facebook in Russia and a diagnostic problem

[Emile Aben]

Op 2022-03-14 om 13:36 schreef Hugo Salgado:

On 10:09 14/03, Stephane Bortzmeyer wrote:

So, I'm a bit lost: what do we observe? It does not look like
censorship but not like a connectivy issue (because of depeering by
Cogent and Lumen) either.


They could be dropping return packets after TLS client hello
negotiation.



If this is purely about observing on how this is done (ie. not about 
what we can measure with Atlas),

I find the things the OONI project does very insightful.

For this particular case:
https://ooni.org/post/2022-russia-blocks-amid-ru-ua-conflict/

They document the different techniques used and their prevalence

hope this helps,
Emile


--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] List of (scientific) publications using RIPE Atlas

[Emile Aben]

Hi Moritz,

Op 2020-11-25 om 08:22 schreef Moritz Muller:

Hi everyone,

A follow up to last week’s Atlas Open House:
One of the speakers mentioned that the Wikipedia page of RIPE Atlas [1] lists a 
number of publications that made use of RIPE Atlas.
This list is incomplete and I was wondering if there’s a page somewhere, maybe 
provided by RIPE NCC, where researchers can submit and list work that used 
Atlas in some way.
This could give beginning researchers and students some inspiration.
You can edit the wikipedia page and add your research yourself. This is 
a pragmatic solution, so we don't have to run a full fledged system like 
some other large data collection platforms do [1], to capture scientific 
output.


If there is enough support for us running such things, this could be put 
on our road map of course.

Maybe this page could also provide links to the measurements themselves for 
transparency.
There are multiple ways to do this. For instance: One could also add a 
specific tag to measurements used in a particular study and then refer 
to that in the publication.


How to capture scientific output from our data collection platforms 
(both Atlas and RIS) and specifically their relevance to network 
operations has my specific attention, if people have good ideas around 
this let me know [2]


I hope this clarifies a bit,
Emile

[1] https://www.caida.org/data/publications/
[2] We are doing a deployathon today, you can still register ( 
https://labs.ripe.net/Members/becha/lets-deploy-together-ripe-atlas-software-probes-deployathon 
), and I'd love to have a chat around this and other topics in the 
spatial.chat that we'll be using :)





-
Moritz

[1] https://en.wikipedia.org/wiki/RIPE_Atlas

Re: [atlas] Network name missing at http://sg-pub.ripe.net/petros/population_coverage/country.html?name=CZ

[Emile Aben]

Hi Jiri,

On 01/08/2019 10:29, r...@brite.cz wrote:
> Hi team,
> RIPE Atlas Population Coverage tool ( 
> http://sg-pub.ripe.net/petros/population_coverage/country.html?name=CZ ) is 
> missing Network Names (column "Network Name") in more than half rows.
> It seems it is the same for multiple/all countries.
> Please have a look.

Thanks for using the population coverage tool.
I've tracked down the issue in this prototype page, but don't have an
easy fix available right now.
As a work-around you can click on the AS number in the table, that will
lead you to a RIPEstat page that has the AS name.

best regards,
Emile Aben
RIPE NCC

Re: [atlas] Communication with probes' owners

[Emile Aben]

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

Re: [atlas] SSL error on OpenIPMap

[Emile Aben]

Hi Anurag,

On 30/09/16 19:54, Anurag Bhatia wrote:
> Hello everyone.
> 
> 
> 
> Is it just me or anyone else getting SSL error on OpenIPMap? I can see that 
> SSL cert of atlas.ripe.net  is valid but when we open 
> OpenIP Map, it calls one specific map image from fastly on HTTP resulting in 
> "mixed content" making Chrome to throw SSL error.
> 
> This is the URL of that image:
> http://stamen-tiles-c.a.ssl.fastly.net/toner-lite/3/5/5.png
> 
> 
> 
> It does seems to be available on https already and so probably someone at 
> RIPE need to update URL to call https in URL and avoid the false positive 
> it's giving.
> 

it did work for me in chrome. i saw warnings in console, but nothing
that would stop the OpenIPMap pages from functioning.

that said, i changed tile loading from http to https , so that shouldn't
be a problem anymore.

Note that OpenIPMap is a prototype, and is scheduled to be replaced by a
production version.

cheers,
emile

Re: [atlas] Rate limits on Atlas

[Emile Aben]

On 08/09/16 14:01, Anant Shah wrote:
> Hi Emile, 
> 
> Roya and I are working on a geolocation paper and want to use the atlas
> probes to ping target IPs. 
> 
> I think I am hitting the rate limit on atlas even with 99 concurrent
> measurements. All my measurements now show Forbidden status. Is there a
> way to increase the limit? 

yes, ask the team at at...@ripe.net (cc-ed).

the folks there can extend limits (not unlimited of course, these limits
are there for a reason :) ), but would need some info from you:
 - what is the experiment you'd like to perform
 - what would you want the new limit to be (and why what you want to do
can't be done with the current limits and/or existing measurements)
 - when does your experiment end (ie. when can we put the limits back to
the default)
 - promise us that you'll acknowledge RIPE Atlas in a paper
 - send us a link/copy of the paper once it's published

(i hope i'm not forgetting things :) )

cheers,
emile

Re: [atlas] Identifying widespread outages using atlas?

[Emile Aben]

On 20/07/16 14:46, rafal.jankow...@thomsonreuters.com wrote:
> Hi I’m wondering if there is any good statistic tool that helps
> identyfing any widespread Internet outages using ripe atlas probes such
> as ISP issues (like todays
> http://www.bbc.co.uk/news/technology-36844712), cable cuts, etc.
> Normally I select probe and look into public measurements but it does
> not seem to be very effective.

yes, this is still an active topic of research.

we've made some inroads into anomaly detection and RIPE Atlas
traceroutes (http://arxiv.org/abs/1605.04784), and there is work in
progress on making data from that available near-realtime.

we do have a live-stream of probe connect/disconnect events (docs at:
https://atlas.ripe.net/docs/result-streaming/ ), and are also working on
detecting outage-type signals from that.

and we do one-off analysis of events, examples:
https://labs.ripe.net/Members/emileaben/internet-access-disruption-in-turkey
https://labs.ripe.net/Members/emileaben/does-the-internet-route-around-damage

that said, we can help investigate particular events, if we expect the
outcome to yield interesting data/insight to our community.

cheers,
Emile Aben

Re: [atlas] What is 'iwantbcp38compliancetesting' user tag?

[Emile Aben]

On 11/01/16 10:39, Daniel Karrenberg wrote:
> 
> 
> On 10.01.16 6:17 , Emile Aben wrote:
>> Hi,
>>
>> As for the origin of the tag: I set this on my probe as an experiment to
>> see if one could do a poll among probe hosts. Apparently the hosts of 21
>> other probes already found the tag without it every being advertised.
>>
>> Now that it is more widely known it would probably be interesting for
>> proponents of BCP38 compliance-testing to set that probe-tag, and for
>> opponents to set the 'idontwantbcp38compliancetesting' probe-tag.
> 
> In general I like creative use of the RIPE Atlas system. I could see the
> use of a "SourceAddressSpoofOK" tag that says it would be OK to spoof
> source addresses when sending traffic from this probe. This kind of
> opt-in statement has meaning. It would also be a constructive way to get
> around the risks associated with source address spoofing from probes of
> unsuspecting hosts.
> 
> However doing a poll by setting probe tags which are meant to convey
> attributes of the probe and not opinions of the host is not really
> useful. This is aggravated by the lack of a clear definition for the
> meaning of this tag.

dismissing this as useless is a bit premature i think. this is an
experiment about how to get community feedback, tied to specific
resources (ripe atlas probes) this community has (ie. one vote per
probe). if the number of people that 'vote' is insignificant the
conclusion is that my attempt of collecting feedback didn't work.

as to meaning of the tag: as you said yourself the tag conveys the
opinion of the probe host.
what may be unclear is if the probe host would be ok with bcp38 tests
from their own probes. my assumption is they are (i probably should have
made the tag 'iwantbcp38compliancetestingonthisprobe', but thought that
rather long).

currently there are 37 probes with 'iwantbcp38compliancetesting' set, so
in case ripe atlas would have 'bcp38-compliance testing' as an opt-in
measurement, this would likely be the lower bound of the probes that
would be opted-in.

emile

ps: i think the definition problem is more with spoofing vs.
bcp38-compliance testing.
spoofing doesn't necessarily involve all involved parties' agreement,
while i think a bcp38-compliance test could (should?).

personally, as a probe host, i would *not* want all spoofing being made
possible from my ripe atlas probe, but i would be ok with
bcp38-compliance testing, especially if all involved parties are ok with
sending bcp38 test packets.
involved parties:
- probe host
- holder/user of src address for a bcp38 test packet
- holder/user of dst address for a bcp38 test packet

and i think we can create circumstances where we can actually make all
these parties agree. having a probe host opt-in (like my tag implies,
but could be more explicit like you suggest) and by having fixed src/dst
address space being used for these tests (or have probe public ip
addresses of hosts that agree being used in tests?).

Re: [atlas] Map-based visualisations for Atlas data

[Emile Aben]

On 08/12/15 09:50, Robert Kisteleki wrote:
> Hi,
> 
> On 2015-12-05 14:43, Baptiste Jonglez wrote:
>> Hi,
>>
>> Is there a way to reuse and adapt the code for the maps available here?
>>
>>   https://atlas.ripe.net/results/maps/
>>
>> It could be interesting to have a generic map-based visualisation, where
>> all probes matching a certain set of conditions would be displayed.
>>
>> Possible applications include:
>>
>> - monitor IPv6 deployment for an AS, by displaying all probes matching
>>   "asn_v6 = XX".  It would probably be useful to also display probes
>>   matching "asn_v4 = XX", as a baseline, using a different color
>>
>> - monitor DNS resolver outage geographically, by matching on system tags
>>   like "resolving A doesn't work".
>>
>> - match on user tags, like "IXP" or "core", to monitor deployment of Atlas
>>   at specific locations/types of networks.
> 
> There's some development needed, but it'd be possible to add a generic map
> that is filterable by probe tags (and other filters present today). What we
> cannot do today is doing this historically, as that'd require keeping track
> of probe tag status for all probes at arbitrary points in time.
> 
>> In all those examples, the "time slider" functionality would be extremely
>> useful, to see the evolution over time.  It could be even nicer if the
>> slider could move automatically, so as to provide nice animations.
> 
> The time travel functionality is available on all maps (unless we forgot
> some :-) where the measurement is/was ongoing.
> 
> We tried doing animations / movies and while it's not impossible, it's
> extremely resource intensive both on the server and the client side (for 9K
> probes...). It's possible to do it as a gimmick, but we don't see it as a
> realistic public service.

Experiments with external platforms like CartoDB do work though:
https://labs.ripe.net/Members/emileaben/visualising-network-outages-with-ripe-atlas

(figures 2)

but just animation without other info is quite hard to follow (at least
for me), so i think adding more information ( like figure 4 ) is very
helpful if you want to make stuff more then a gimmick.

cheers,
Emile