October 2022 - ripe-atlas - mailman.ripe.net

Requesting Credits for Research
by Alex Gamero-Garrido 29 Jul '23

29 Jul '23

Hi folks, My name is Alexander Gamero-Garrido and I'm a 5th year PhD student at CAIDA, UC San Diego. We're soon launching a large traceroute campaign for research and could use your generous donation of credits. We'll need about 150 million credits, but any partial amount that gets us closer to that goal is welcome and greatly appreciated. My account is agamerog at eng.ucsd.edu Thank you, Alex -- *Alex Gamero-Garrido* *PhD Student, Computer Science* Web: cseweb.ucsd.edu/~agamerog Center for Applied Internet Data Analysis (CAIDA) San Diego Supercomputer Center UC San Diego Pronouns: He/Him/His <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> I'm using Inbox When Ready <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> to protect my focus.

13 15

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

RIPE Atlas SMTP Measurement
by ripe.net＠toppas.net 11 Nov '22

11 Nov '22

Hello, i'd like to start a discussion about having a RIPE Atlas SMTP measurements. First of all: yes, i know there's a big obstacle for such a measurement type. A lot of probes are deployed using enduser internet-connections like dsl, cable, etc. with dynamic/eyeball IP addresses. Those IP spaces are usually blocked by SMTP servers as approach to reduce spam mails. For Example: by using blocklists like Spamhaus PBL. So a proper SMTP measurement wouldn't work. BUT we could have an easy way for RIPE Atlas probe hosters to signalize, that their probe is eligible for SMTP measurements: Step 1: enable "Simple DNS Entry" Step 2: create a matching reverse DNS record for the probes IP address Everybody who is able so configure a reverse DNS record for his probes IP address, is most likely using a non-dynamic/non-home ip address space e.g. a datacenter or office network. If an ISP provides the option for his customers to configure a reverse DNS record, it's most likely a "business-customer" subnet which can be used to run mailservers. After Step 1+2 are done, the RIPE Atlas platform would easily be able to verify if forward-confirmed reverse DNS is successful, and if so, automatically enable that probe for SMTP measurements. Alternatively: probe hosters choose their own Forward-confirmed reverse DNS name and submit it on the RIPE Atlas website. Also: if we would have STMP measurements, forward-confirmed reverse DNS should be mandatory for anchors, or is it already? Why should we have SMTP measurements? Besides general reachability checks, we could also evaluate SMTP response codes. But the most important thing for me is this: the SMTP protocol is old. Very old. From a security point of view, it's absolutely outdated. Most security features have been added years after the initial RfC. Thus, those security features are optional. Mandatory SMTP encryption is not provided by the SMTP RfC. So both sides have to signalize, that they are capable of encryption using the STARTTLS command. An attacker (man-in-the-middle) can perform a downgrade attack by suppressing the STARTTLS command. So both sides are forced to fallback and communicate unencrypted. RIPE Atlas would be a really good tool to identify such attacks, by monitor/measure the (enhanced) status codes of a target. But there's more! I see a two-sided model here. Either use the RIPE Atlas SMTP measurements to monitor/measure your own mailserver by alot of other RIPE probes out there, OR probe hosters could run SMTP measurements originating from their own probe to find out, if their own IP address is currently blocked by other mailservers. What do you think? BR, Simon

5 26

placing a probe into wireless networks (not terrestrial)
by Kurt Kayser 11 Nov '22

11 Nov '22

Dear Atlas-ml-followers, this a summary of a brief discussion I had with Michel Stam during RIPE85. We believe there might be a great value putting up a public Internet monitoring probe (vantage point) into low earth orbit satellite systems, such as Starlink. Monitoring from terrestrial end-points delivers high variances, due to frequent sat-changes. If we could put up an ATLAS-probe (be it SW - which is probably easier than HW) into a specific plane, we could add interesting tests and try to interpret the values depending on position over specific areas, atmospheric influences, solar influences as well as other effects that would change signal patterns. I would be offering support to try to establish such a probe and help to setup a project defition. Any thoughts or feedback to this idea? Best regards Kurt Kayser

3 3

V5 probes
by Ernst J. Oud 10 Nov '22

10 Nov '22

L.S. Is there a sneak preview of the V5 probes available somewhere? Regards, Ernst J. Oud

8 14

Breaking API change?
by Ray Bellis 26 Oct '22

26 Oct '22

ISC's Root System Atlas visualiser used to use this API call to access the built-in root system measurements: <${apiUrl}/measurements/${m}/latest/?fields=responses.0.response_time,responses.0.abuf.answers.0.data.0&freshness=1800> where ${m} is the measurement number. It used to return this object: { probe_id1: [ [ latency, site1 ], ... ] probe_id2: [ [ latency, site1 ], ... ] ... } It now returns this array instead: [ [probe_id1, latency, site], ... [probe_id1, latency, site], [probe_id2, latency, site], ... ] and I had to explicitly request the probe_id field in order to get it. Was this change intentional, a regression, or did I not use the API right in the first place? cheers, Ray

2 3

V4 probe looses connection
by Szabolcs Sipos 22 Oct '22

22 Oct '22

Hi, I have a probe (#53985, V4, fw: 5070) that goes offline after 1-2 days of uptime and does not recover unless rebooted. The probe responds to ping (even from a different subnet). Packet capture reveals that it renews its DHCP lease normally, but does not initiate any higher level connection. I will try to keep the probe online for a few days so that you can run some tests if you wish. Regards, Szabolcs

1 0

Shared probes not shown anymore in "my atlas"
by Dave 20 Oct '22

20 Oct '22

Hi, In the past the probes that had shared management were shown below the owned probes. This is not the case anymore. Is this intentional? Can it be restored? Thanks, Dave

2 1

ATLAS page broken because of Cloudflare
by Max Grobecker 16 Oct '22

16 Oct '22

Hi, on my network, the RIPE ATLAS page is not working because mandatory resources (i.e. Javascript) can't be loaded, because appearently ripe.net is now running behind Cloudflare and is blocking requests to static resources - see attached network console screenshot of my browser. There should be made a rule to exclude static assets or trusted origins from this type of filtering. This is maybe also affecting other pages, which include resources directly from www.ripe.net. I'm accessing this over a mobile network via IPv6 (Telefonica Germany), so it's not a "other bad person behind same CGNAT" problem but a seemingly static rule to always challenge the client. Greetings, Max

1 0

Re: [atlas] Apply for Quantum Internet Hackathon: 1-2 December, 6 locations & online
by Gery Escalier 15 Oct '22

15 Oct '22

Fantastic Vesna! thank you so much for sharing it on the list! Gery

1 0