From robert at ripe.net Thu Apr 4 15:51:32 2019 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 4 Apr 2019 15:51:32 +0200 Subject: [atlas] Responsive Probe Fluctuations In-Reply-To: References: Message-ID: Hi, On 2019-03-30 13:52, Marcel Flores wrote: > Hi All, > > Noticed a funny little swing in probe responsiveness. It seems to have > returned to normal, but was curious if anyone else had seen it. We do > one-off measurement where we select all probes, usually the > responsiveness rates look something like: Prelude: the reports on number of participating probes are populated by counting how many different probes we actually receiv4ed data from. If everything goes as expected, this should eventually consistent with the actual measurements results collected, with some delay. > 12743 Requested / 10147 Actually Participated (Taken from 18 March) > > But on 19 March we started seeing rates more like: > > 12914 Requested / 7852 Actually Participated Due to an internal issue, result delivery was delayed around 18-19 March: results were buffered in the infrastructure and only made it to storage later than usual. I strongly suspect this is the reason for the numbers you saw. It's likely that if you sum up all the results you actually got by now, you'll see a much higher rate of "actually participated". (This assumes that these numbers come from the UI, not from your own counting in the first place.) > Which continued until about 28 March, when it returned to about the > previous levels: > > 12916 Requested / 9943 Actually Participated > > Something funny happen with the dispatching? Did anybody else see? Due to the nature of the beast, real-time data delivery is hard and delays as above can occur. These are relatively rare, and even less frequently are noticeable by users. I hope these fluctuations don't cause real harm to you. Regards, Robert > -- > *Marcel Flores, PhD* |?Sr.?Research Scientist > research.verizondigitalmedia.com > ?| AS15133 > > p: +1 310.593.6880e: marcel.flores at verizondigitalmedia.com > ?? > 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094 From robert at ripe.net Fri Apr 5 13:38:31 2019 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 5 Apr 2019 13:38:31 +0200 Subject: [atlas] Responsive Probe Fluctuations In-Reply-To: References: Message-ID: Hello, > Due to an internal issue, result delivery was delayed around 18-19 > March: results were buffered in the infrastructure and only made it to > storage later than usual. I strongly suspect this is the reason for the > numbers you saw. We're having similar issue at the moment, meaning current results are not delivered in real-time. We apologise for the inconvenience this may cause. Regards, Robert Kisteleki From bortzmeyer at nic.fr Fri Apr 5 14:02:26 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 5 Apr 2019 14:02:26 +0200 Subject: [atlas] DNS measurements broken today? Message-ID: <20190405120226.a3ogigpiqrhanq3n@nic.fr> It seems all DNS measurements (not just mine, checked on return only an empty array today... % curl -s https://atlas.ripe.net/api/v2/measurements/20566896/results/ []% From petr.spacek at nic.cz Mon Apr 8 16:36:37 2019 From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=) Date: Mon, 8 Apr 2019 16:36:37 +0200 Subject: [atlas] DNS-over-TLS and DNS-over-HTTPS measurement Message-ID: <6fec2cf1-dc92-8fa3-98f9-5108a6485149@nic.cz> Hello, could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements? I had impression that DNS-over-TLS is already supported but now I cannot find it in the UI so I'm probably wrong. Thank you for information! -- Petr ?pa?ek @ CZ.NIC From bortzmeyer at nic.fr Mon Apr 8 16:47:24 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 8 Apr 2019 16:47:24 +0200 Subject: [atlas] DNS-over-TLS and DNS-over-HTTPS measurement In-Reply-To: <6fec2cf1-dc92-8fa3-98f9-5108a6485149@nic.cz> References: <6fec2cf1-dc92-8fa3-98f9-5108a6485149@nic.cz> Message-ID: <20190408144724.gnhqe4lky5s4e37c@nic.fr> On Mon, Apr 08, 2019 at 04:36:37PM +0200, Petr ?pa?ek wrote a message of 11 lines which said: > could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements? > > I had impression that DNS-over-TLS is already supported but now I cannot > find it in the UI so I'm probably wrong. DNS-over-TLS works for me: % blaeu-resolve --verbose --nameserver 9.9.9.9 --tls nic.cz Blaeu version 1.1.4 {'is_oneoff': True, 'definitions': [{'description': 'DNS resolution of nic.cz/AAAA via nameserver 9.9.9.9', 'af': 4, 'type': 'dns', 'query_argument': 'nic.cz', 'query_class': 'IN', 'query_type': 'AAAA', 'set_rd_bit': True, 'tls': True, 'protocol': 'TCP', 'use_probe_resolver': False, 'target': '9.9.9.9'}], 'probes': [{'requested': 5, 'type': 'area', 'value': 'WW', 'tags': {'include': ['system-ipv4-works']}}]} Measurement #20617896 for nic.cz/AAAA uses 5 probes Nameserver 9.9.9.9 [2001:1488:0:3::2] : 5 occurrences Test #20617896 done at 2019-04-08T14:45:31Z (Note the 'tls': True in the JSON) From petr.spacek at nic.cz Mon Apr 8 17:04:38 2019 From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=) Date: Mon, 8 Apr 2019 17:04:38 +0200 Subject: [atlas] DNS-over-TLS and DNS-over-HTTPS measurement In-Reply-To: <20190408144724.gnhqe4lky5s4e37c@nic.fr> References: <6fec2cf1-dc92-8fa3-98f9-5108a6485149@nic.cz> <20190408144724.gnhqe4lky5s4e37c@nic.fr> Message-ID: <8435194b-e282-71fc-9f12-9db56016178e@nic.cz> Thank you, I will have a look. I must have missed DoT in the UI and API docs. Anyway, are there plans for supporting DNS-over-HTTPS? Petr ?pa?ek @ CZ.NIC On 08. 04. 19 16:47, Stephane Bortzmeyer wrote: > On Mon, Apr 08, 2019 at 04:36:37PM +0200, > Petr ?pa?ek wrote > a message of 11 lines which said: > >> could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements? >> >> I had impression that DNS-over-TLS is already supported but now I cannot >> find it in the UI so I'm probably wrong. > > DNS-over-TLS works for me: > > % blaeu-resolve --verbose --nameserver 9.9.9.9 --tls nic.cz > Blaeu version 1.1.4 > {'is_oneoff': True, 'definitions': [{'description': 'DNS resolution of nic.cz/AAAA via nameserver 9.9.9.9', 'af': 4, 'type': 'dns', 'query_argument': 'nic.cz', 'query_class': 'IN', 'query_type': 'AAAA', 'set_rd_bit': True, 'tls': True, 'protocol': 'TCP', 'use_probe_resolver': False, 'target': '9.9.9.9'}], 'probes': [{'requested': 5, 'type': 'area', 'value': 'WW', 'tags': {'include': ['system-ipv4-works']}}]} > Measurement #20617896 for nic.cz/AAAA uses 5 probes > Nameserver 9.9.9.9 > [2001:1488:0:3::2] : 5 occurrences > Test #20617896 done at 2019-04-08T14:45:31Z > > (Note the 'tls': True in the JSON) From camin at ripe.net Tue Apr 9 15:38:15 2019 From: camin at ripe.net (Chris Amin) Date: Tue, 9 Apr 2019 15:38:15 +0200 Subject: [atlas] Scheduled RIPE Atlas maintenance 2019-04-10 09:00 UTC Message-ID: <44a0a52a-1a21-8622-e3f8-a7b7ceab1571@ripe.net> Dear RIPE Atlas users, We are planning on making a behind-the-scenes change to the RIPE Atlas database tomorrow in order to make the system more robust. Measurements scheduled during this time may be either rejected or delayed. Probes will continue to carry out measurements as usual so there won't be a gap in scheduled measurement results. The window for the maintenance is 2019-04-10 09:00 UTC until 12:00 UTC. We hope that it will be quicker than this and will keep you updated. Kind regards, Chris Amin RIPE NCC From camin at ripe.net Wed Apr 10 10:08:58 2019 From: camin at ripe.net (Chris Amin) Date: Wed, 10 Apr 2019 10:08:58 +0200 Subject: [atlas] Scheduled RIPE Atlas maintenance 2019-04-10 09:00 UTC In-Reply-To: <44a0a52a-1a21-8622-e3f8-a7b7ceab1571@ripe.net> References: <44a0a52a-1a21-8622-e3f8-a7b7ceab1571@ripe.net> Message-ID: <10a0b55e-c359-09a1-6738-5331fba81230@ripe.net> Hi all, We are beginning this work now. Regards, Chris On 09/04/2019 15:38, Chris Amin wrote: > Dear RIPE Atlas users, > > We are planning on making a behind-the-scenes change to the RIPE Atlas > database tomorrow in order to make the system more robust. Measurements > scheduled during this time may be either rejected or delayed. Probes > will continue to carry out measurements as usual so there won't be a gap > in scheduled measurement results. > > The window for the maintenance is 2019-04-10 09:00 UTC until 12:00 UTC. > We hope that it will be quicker than this and will keep you updated. > > Kind regards, > Chris Amin > RIPE NCC > From philip.homburg at ripe.net Wed Apr 10 13:43:57 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 10 Apr 2019 13:43:57 +0200 Subject: [atlas] DNS-over-TLS and DNS-over-HTTPS measurement In-Reply-To: <8435194b-e282-71fc-9f12-9db56016178e@nic.cz> References: <6fec2cf1-dc92-8fa3-98f9-5108a6485149@nic.cz> <20190408144724.gnhqe4lky5s4e37c@nic.fr> <8435194b-e282-71fc-9f12-9db56016178e@nic.cz> Message-ID: On 2019/04/08 17:04 , Petr ?pa?ek wrote: > Anyway, are there plans for supporting DNS-over-HTTPS? Hi Petr, A couple of years ago we created a policy regarding HTTP measurements on RIPE Atlas. The concern was that probe hosts located in certain countries could get into trouble should their probes try to reach certain HTTP targets. So it was decided at the time that since these measurements do not add much to the goal of RIPE Atlas, which is to measure the Internet as a network and not the higher level protocols that run on top of it, we restricted HTTP measurements such that they are only able to target RIPE Atlas anchors. Obviously there are benefits in measuring DNS-over-HTTPS. However, the risk for probe hosts in certain countries remains the same. For this reason, although we would be open to the creation of a new policy should there be sufficient interest from the community, there are no plans to support DNS-over-HTTPS until such a policy is in place. Philip From sebastian.wiesinger at noris.net Wed Apr 17 08:52:22 2019 From: sebastian.wiesinger at noris.net (Sebastian Wiesinger) Date: Wed, 17 Apr 2019 08:52:22 +0200 Subject: [atlas] All our atlas probes have reverted to DHCP Message-ID: <20190417065222.q2l3xlj6ectihzth@sol.office.noris.de> Hi, all of our four atlas probes have reverted from their fixed network configuration to DHCP which is a shame because there is no DHCP at their present locations. Also this not the first time it happend. Can someone explain why this happens and how to prevent this? This wastes a lot of time and effort every time it happens. Regards Sebastian From gponikie at akamai.com Wed Apr 17 19:13:37 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Wed, 17 Apr 2019 17:13:37 +0000 Subject: [atlas] Communication with probes' owners Message-ID: Hi all! From time to time I find probes which has incorrect country in their description. For example #10333 supposed to be in US but from my measurements it looks like it is somewhere nearby Amsterdam. If something has 10ms RTT to target in Amsterdam, has hops with `nl-ams14a-ri1-ae8-0.aorta.net` description and has ASN for LibertyGlobal then this probe is rather in Europe. It takes some time to resolve such issue via RIPE team so maybe we can get a form to send direct and short message to probe owner to let him/her know that something is wrong with his/her probe and we ask for verification. What do you think about that? Regards, Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Apr 18 14:56:51 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 18 Apr 2019 14:56:51 +0200 Subject: [atlas] Measurement result issues for some RIPE Atlas anchors Message-ID: In April, we started investigating a strange traceroute result reported by one of the RIPE Atlas anchors. The conclusion of our investigation is that the probe upgrade process for the v3 anchor firmware has been leaving old measurement daemons running as well as starting new ones. This means that a gradually increasing number of measurements from the affected anchors have been performed multiple times more or less simultaneously. Because those processes were writing to the same file, this resulted in a lot of garbled results. Purely by chance, the weird result that triggered the investigation had the first part of one result and the last part of another result in a way that generated syntactically correct JSON. The net result is that for the last few months, measurements done by anchors may have resulted in multiple results at roughly the same time or no results because the results were rejected as invalid. For those who wish to check whether results for specific measurements were affected, the following links will direct you to lists of probe IDs for the affected anchors: https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-virtual&fields=id (VM anchors) https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-v3-pc-engines&fields=id (v3 hardware anchors) We are working to resolve the issue and will keep you updated as and when we have more to report. We apologise for any inconvenience this might cause. Philip From paolo.pozzan at telemar.it Fri Apr 19 12:26:24 2019 From: paolo.pozzan at telemar.it (Paolo Pozzan) Date: Fri, 19 Apr 2019 12:26:24 +0200 (CEST) Subject: [atlas] Communication with probes' owners In-Reply-To: References: Message-ID: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> It seems a good idea. I don't think this will be abused and in case it would be easy to point out the spammers. Would this be useful also for other kind of messages? Paolo ----- Messaggio originale ----- > Da: "Grzegorz Ponikierski" > A: ripe-atlas at ripe.net > Inviato: Mercoled?, 17 aprile 2019 19:13:37 > Oggetto: [atlas] Communication with probes' owners > Hi all! > From time to time I find probes which has incorrect country in their > description. For example #10333 supposed to be in US but from my > measurements it looks like it is somewhere nearby Amsterdam. If > something has 10ms RTT to target in Amsterdam, has hops with ` > nl-ams14a-ri1-ae8-0.aorta.net ` description and has ASN for > LibertyGlobal then this probe is rather in Europe. It takes some > time to resolve such issue via RIPE team so maybe we can get a form > to send direct and short message to probe owner to let him/her know > that something is wrong with his/her probe and we ask for > verification. What do you think about that? > Regards, > Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten at schiefner.de Sat Apr 20 10:38:44 2019 From: carsten at schiefner.de (Carsten Schiefner) Date: Sat, 20 Apr 2019 10:38:44 +0200 Subject: [atlas] Communication with probes' owners In-Reply-To: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> Message-ID: <4c58e1f3-348d-890d-9c58-0415ce300e59@schiefner.de> Grzegorz, Paolo, all - On 19.04.2019 12:26, Paolo Pozzan wrote: > It seems a good idea. +1. > I don't think this will be abused Quite the opposite IMHO, understanding that the anticipated means of communication will be email and that the email address of a probe's host will be generic, eg. , redirecting all incoming emails to a final address. The redirection would be configured via the portal then. > and in case it would be easy to point out the spammers. Maybe the NCC could and would operate a purpose specific spam catcher for the 3rd level domain 'atlas'. But after all I wouldn't really care as I am already running anti-spam measures anyway. YMMV though... > Would this be useful also for other kind of messages? Like what? Best, -C. > ------------------------------------------------------------------------ > > *Da: *"Grzegorz Ponikierski" > *A: *ripe-atlas at ripe.net > *Inviato: *Mercoled?, 17 aprile 2019 19:13:37 > *Oggetto: *[atlas] Communication with probes' owners > > Hi all! > > ? > > From time to time I find probes which has incorrect country in their > description. For example #10333 supposed to be in US but from my > measurements it looks like it is somewhere nearby Amsterdam. If > something has 10ms RTT to target in Amsterdam, has hops with > `nl-ams14a-ri1-ae8-0.aorta.net > ` description > and has ASN for LibertyGlobal then this probe is rather in Europe. > It takes some time to resolve such issue via RIPE team so maybe we > can get a form to send direct and short message to probe owner to > let him/her know that something is wrong with his/her probe and we > ask for verification. What do you think about that? > > ? > > Regards, > > Grzegorz From GeertJan.deGroot at xs4all.nl Sat Apr 20 13:49:06 2019 From: GeertJan.deGroot at xs4all.nl (Geert Jan de Groot) Date: Sat, 20 Apr 2019 13:49:06 +0200 Subject: [atlas] contacing probe owner. In-Reply-To: References: Message-ID: <95709c8e-3e1a-9bbe-2140-8bfb159d0265@xs4all.nl> > Quite the opposite IMHO, understanding that the anticipated means of > communication will be email and that the email address of a probe's host > will be generic, eg. , > redirecting all incoming emails to a final address. The redirection > would be configured via the portal then. Using an address as described above would allow enumeration attacks. If it would use a hash instead it would be safer. The hash for probe XXX would be obtainable via the portal, where you would need to look up probe's details anyway. Geert Jan From carsten at schiefner.de Sat Apr 20 14:16:44 2019 From: carsten at schiefner.de (Carsten Schiefner) Date: Sat, 20 Apr 2019 14:16:44 +0200 Subject: [atlas] contacing probe owner. In-Reply-To: <95709c8e-3e1a-9bbe-2140-8bfb159d0265@xs4all.nl> References: <95709c8e-3e1a-9bbe-2140-8bfb159d0265@xs4all.nl> Message-ID: Hi Geert Jan - On 20.04.2019 13:49, Geert Jan de Groot wrote: >> Quite the opposite IMHO, understanding that the anticipated means of >> communication will be email and that the email address of a probe's host >> will be generic, eg. , >> redirecting all incoming emails to a final address. The redirection >> would be configured via the portal then. > > Using an address as described above would allow enumeration attacks. true. OTOH & as I wrote: I don't really care. > If it would use a hash instead it would be safer. > > The hash for probe XXX would be obtainable via the portal, where you > would need to look up probe's details anyway. Do I? Always? I have attempted to deploy KISS here - but anyhow: I'd obviously also be fine with a more advanced (definition thereof) solution. Best, -C. From gboonie at gmail.com Sun Apr 21 19:59:53 2019 From: gboonie at gmail.com (Dave .) Date: Sun, 21 Apr 2019 19:59:53 +0200 Subject: [atlas] Communication with probes' owners In-Reply-To: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> Message-ID: If this gets implemented, please add a checkbox where one can indicate whether one is a user or also can get things fixed in the AS where your probe is connected. Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan : > It seems a good idea. I don't think this will be abused and in case it > would be easy to point out the spammers. > Would this be useful also for other kind of messages? > > Paolo > > ------------------------------ > > *Da: *"Grzegorz Ponikierski" > *A: *ripe-atlas at ripe.net > *Inviato: *Mercoled?, 17 aprile 2019 19:13:37 > *Oggetto: *[atlas] Communication with probes' owners > > Hi all! > > > > From time to time I find probes which has incorrect country in their > description. For example #10333 supposed to be in US but from my > measurements it looks like it is somewhere nearby Amsterdam. If something > has 10ms RTT to target in Amsterdam, has hops with ` > nl-ams14a-ri1-ae8-0.aorta.net > ` description and > has ASN for LibertyGlobal then this probe is rather in Europe. It takes > some time to resolve such issue via RIPE team so maybe we can get a form to > send direct and short message to probe owner to let him/her know that > something is wrong with his/her probe and we ask for verification. What do > you think about that? > > > > Regards, > > Grzegorz > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten at schiefner.de Sun Apr 21 23:59:27 2019 From: carsten at schiefner.de (Carsten Schiefner) Date: Sun, 21 Apr 2019 23:59:27 +0200 Subject: [atlas] Communication with probes' owners In-Reply-To: References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> Message-ID: <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> Am 21.04.2019 um 19:59 schrieb Dave . : > If this gets implemented, please add a checkbox where one can indicate whether one is a user or also can get things fixed in the AS where your probe is connected. Makes sense to me: +1. Would then a reminder every 1/2/3 month[s] make sense that this is (still) the case aka. this flag to be set? As the probe?s circumstances may change... > Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan : >> It seems a good idea. I don't think this will be abused and in case it would be easy to point out the spammers. >> Would this be useful also for other kind of messages? >> >> Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ve2mrx at hotmail.com Mon Apr 22 02:25:03 2019 From: ve2mrx at hotmail.com (Martin Boissonneault) Date: Mon, 22 Apr 2019 00:25:03 +0000 Subject: [atlas] Communication with probes' owners In-Reply-To: <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> , <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> Message-ID: The best might be for RIPE to contact the owner when the records don't match what is detected from the probe? Some method to trigger a check could be added to the probe's profile, and there would not be ANY chance of email abuse by throwaway accounts? Allowing users to contact probe owners has to be VERY well made to avoid all sorts of attacks and spam! Martin Boissonneault Sent from my iPhone On Apr 21, 2019, at 18:14, Carsten Schiefner > wrote: Am 21.04.2019 um 19:59 schrieb Dave . >: If this gets implemented, please add a checkbox where one can indicate whether one is a user or also can get things fixed in the AS where your probe is connected. Makes sense to me: +1. Would then a reminder every 1/2/3 month[s] make sense that this is (still) the case aka. this flag to be set? As the probe?s circumstances may change... Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan >: It seems a good idea. I don't think this will be abused and in case it would be easy to point out the spammers. Would this be useful also for other kind of messages? Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gponikie at akamai.com Tue Apr 23 13:10:49 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Tue, 23 Apr 2019 11:10:49 +0000 Subject: [atlas] Communication with probes' owners In-Reply-To: References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> Message-ID: <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> I thought about simple web form available only for logged users of RIPE Atlas. In this way all private data are hidden and RIPE can rate limit usage of the form. Message itself can be send to probe's owner via email from RIPE Atlas infra so sender identity also can be hidden. If somebody wants to switch to email communication then form can also be used to exchange email addresses. Regards, Grzegorz From: Martin Boissonneault Date: Monday 2019-04-22 at 02:25 To: Carsten Schiefner Cc: "ripe-atlas at ripe.net" Subject: Re: [atlas] Communication with probes' owners The best might be for RIPE to contact the owner when the records don't match what is detected from the probe? Some method to trigger a check could be added to the probe's profile, and there would not be ANY chance of email abuse by throwaway accounts? Allowing users to contact probe owners has to be VERY well made to avoid all sorts of attacks and spam! Martin Boissonneault Sent from my iPhone On Apr 21, 2019, at 18:14, Carsten Schiefner > wrote: Am 21.04.2019 um 19:59 schrieb Dave . >: If this gets implemented, please add a checkbox where one can indicate whether one is a user or also can get things fixed in the AS where your probe is connected. Makes sense to me: +1. Would then a reminder every 1/2/3 month[s] make sense that this is (still) the case aka. this flag to be set? As the probe?s circumstances may change... Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan >: It seems a good idea. I don't think this will be abused and in case it would be easy to point out the spammers. Would this be useful also for other kind of messages? Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From scg at gibbard.org Tue Apr 23 18:36:14 2019 From: scg at gibbard.org (scg at gibbard.org) Date: Tue, 23 Apr 2019 09:36:14 -0700 Subject: [atlas] Communication with probes' owners In-Reply-To: <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> Message-ID: Having individual users contacting other individual users about probe location problems seems like a not very scalable solution to this problem. It both leaves it somewhat random which issues will be caught, and may leave probe owners whose probes look somewhat atypical having to explain their situation over and over again to random people. I have a cron job that goes through the entire probe list every few hours and runs the IP addresses against the MaxMind Geolite databases. MaxMind has its own accuracy issues, but after a bunch of spot checking I decided that trusting the MaxMind answers was better than trusting the owner-reported information for the probes. If somebody wants to take a more systematic approach to getting the Atlas location data cleaned up, I?d be happy to share a diff. But I?d suggest that it be done by somebody with access to the database cleaning up things that look wrong, instead of bugging a bunch of individual probe owners. -Steve Steve Gibbard > On Apr 23, 2019, at 4:10 AM, Ponikierski, Grzegorz wrote: > > I thought about simple web form available only for logged users of RIPE Atlas. In this way all private data are hidden and RIPE can rate limit usage of the form. Message itself can be send to probe's owner via email from RIPE Atlas infra so sender identity also can be hidden. If somebody wants to switch to email communication then form can also be used to exchange email addresses. > > Regards, > Grzegorz > > From: Martin Boissonneault > Date: Monday 2019-04-22 at 02:25 > To: Carsten Schiefner > Cc: "ripe-atlas at ripe.net" > Subject: Re: [atlas] Communication with probes' owners > > The best might be for RIPE to contact the owner when the records don't match what is detected from the probe? > > Some method to trigger a check could be added to the probe's profile, and there would not be ANY chance of email abuse by throwaway accounts? > > Allowing users to contact probe owners has to be VERY well made to avoid all sorts of attacks and spam! > > Martin Boissonneault > Sent from my iPhone > > On Apr 21, 2019, at 18:14, Carsten Schiefner wrote: > > Am 21.04.2019 um 19:59 schrieb Dave . : > If this gets implemented, please add a checkbox where one can indicate whether one is a user or also can get things fixed in the AS where your probe is connected. > Makes sense to me: +1. > > Would then a reminder every 1/2/3 month[s] make sense that this is (still) the case aka. this flag to be set? > > As the probe?s circumstances may change... > > Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan : > It seems a good idea. I don't think this will be abused and in case it would be easy to point out the spammers. > Would this be useful also for other kind of messages? > > Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ve2mrx at hotmail.com Tue Apr 23 19:01:28 2019 From: ve2mrx at hotmail.com (Martin Boissonneault) Date: Tue, 23 Apr 2019 17:01:28 +0000 Subject: [atlas] Communication with probes' owners In-Reply-To: <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> , <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> Message-ID: Hi Grzegorz, I'm sorry if I sound paranoid, computer security does that to some ;-) My registering for my Atlas account was a few years ago, so I don't remember all the details. But usually, new account creation can be scripted and fake accounts can rapidly created by a willing party. For that reason, account creation should not be the only measure against spam. Limiting the speed of account creation based on network address can help, but can be circumvented. One big step would be physical address or ID validation. Linking the virtual and physical worlds is harder to abuse. Another way to limit spam is to control the message. The form could give a few checkboxes or pre-defined messages but no place to write a message. If you cannot advertise stuff on the form, it's useless for most spammers. Some forms can be used to DoS email by not using rate-limiting. So, that form could limit the rate per _destination and sender_ like the Digest mode of mailing lists. One or two digests per day, and replies would be like a mailing list. I mean that RIPE would always be the sender or the receiver, ensuring privacy of email address of one party to the other. Now that I think of it, it's pretty much the messaging system of most forums with a front-end. Except that your username is the probe's ID? I think RIPE could do it, if it there is enough demand? Martin Boissonneault Sent from my iPhone On Apr 23, 2019, at 07:10, Ponikierski, Grzegorz > wrote: I thought about simple web form available only for logged users of RIPE Atlas. In this way all private data are hidden and RIPE can rate limit usage of the form. Message itself can be send to probe's owner via email from RIPE Atlas infra so sender identity also can be hidden. If somebody wants to switch to email communication then form can also be used to exchange email addresses. Regards, Grzegorz From: Martin Boissonneault > Date: Monday 2019-04-22 at 02:25 To: Carsten Schiefner > Cc: "ripe-atlas at ripe.net" > Subject: Re: [atlas] Communication with probes' owners The best might be for RIPE to contact the owner when the records don't match what is detected from the probe? Some method to trigger a check could be added to the probe's profile, and there would not be ANY chance of email abuse by throwaway accounts? Allowing users to contact probe owners has to be VERY well made to avoid all sorts of attacks and spam! Martin Boissonneault Sent from my iPhone On Apr 21, 2019, at 18:14, Carsten Schiefner > wrote: Am 21.04.2019 um 19:59 schrieb Dave . >: If this gets implemented, please add a checkbox where one can indicate whether one is a user or also can get things fixed in the AS where your probe is connected. Makes sense to me: +1. Would then a reminder every 1/2/3 month[s] make sense that this is (still) the case aka. this flag to be set? As the probe?s circumstances may change... Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan >: It seems a good idea. I don't think this will be abused and in case it would be easy to point out the spammers. Would this be useful also for other kind of messages? Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ve2mrx at hotmail.com Tue Apr 23 20:13:51 2019 From: ve2mrx at hotmail.com (Martin Boissonneault) Date: Tue, 23 Apr 2019 18:13:51 +0000 Subject: [atlas] Communication with probes' owners In-Reply-To: References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com>, Message-ID: @Steve Gibbard I totally agree. I think it's best for RIPE to analyze the data and ask probe owners to update the probe profiles if it's believed wrong. Maybe tag the probe if the information is suspicious or the owner does not respond? Martin Boissonneault Sent from my iPhone On Apr 23, 2019, at 12:36, "scg at gibbard.org" > wrote: Having individual users contacting other individual users about probe location problems seems like a not very scalable solution to this problem. It both leaves it somewhat random which issues will be caught, and may leave probe owners whose probes look somewhat atypical having to explain their situation over and over again to random people. I have a cron job that goes through the entire probe list every few hours and runs the IP addresses against the MaxMind Geolite databases. MaxMind has its own accuracy issues, but after a bunch of spot checking I decided that trusting the MaxMind answers was better than trusting the owner-reported information for the probes. If somebody wants to take a more systematic approach to getting the Atlas location data cleaned up, I?d be happy to share a diff. But I?d suggest that it be done by somebody with access to the database cleaning up things that look wrong, instead of bugging a bunch of individual probe owners. -Steve Steve Gibbard On Apr 23, 2019, at 4:10 AM, Ponikierski, Grzegorz > wrote: I thought about simple web form available only for logged users of RIPE Atlas. In this way all private data are hidden and RIPE can rate limit usage of the form. Message itself can be send to probe's owner via email from RIPE Atlas infra so sender identity also can be hidden. If somebody wants to switch to email communication then form can also be used to exchange email addresses. Regards, Grzegorz From: Martin Boissonneault > Date: Monday 2019-04-22 at 02:25 To: Carsten Schiefner > Cc: "ripe-atlas at ripe.net" > Subject: Re: [atlas] Communication with probes' owners The best might be for RIPE to contact the owner when the records don't match what is detected from the probe? Some method to trigger a check could be added to the probe's profile, and there would not be ANY chance of email abuse by throwaway accounts? Allowing users to contact probe owners has to be VERY well made to avoid all sorts of attacks and spam! Martin Boissonneault Sent from my iPhone On Apr 21, 2019, at 18:14, Carsten Schiefner > wrote: Am 21.04.2019 um 19:59 schrieb Dave . >: If this gets implemented, please add a checkbox where one can indicate whether one is a user or also can get things fixed in the AS where your probe is connected. Makes sense to me: +1. Would then a reminder every 1/2/3 month[s] make sense that this is (still) the case aka. this flag to be set? As the probe?s circumstances may change... Op vr 19 apr. 2019 om 12:37 schreef Paolo Pozzan >: It seems a good idea. I don't think this will be abused and in case it would be easy to point out the spammers. Would this be useful also for other kind of messages? Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Apr 24 10:43:13 2019 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 24 Apr 2019 10:43:13 +0200 Subject: [atlas] Communication with probes' owners In-Reply-To: <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> Message-ID: <29e45396-cd55-83fe-dd67-3e32f41d4be4@ripe.net> On 2019-04-23 13:10, Ponikierski, Grzegorz wrote: > I thought about simple web form available only for logged users of RIPE > Atlas. In this way all private data are hidden and RIPE can rate limit > usage of the form. Message itself can be send to probe's owner via email > from RIPE Atlas infra so sender identity also can be hidden. If somebody > wants to switch to email communication then form can also be used to > exchange email addresses. > > ? > > Regards, > > Grzegorz Hi, I agree that allowing RIPE Atlas users to send messages to probe hosts would be a useful feature. I also think that requiring someone to log in first before sending a message to the probe hosts is a sufficiently high bar against systematic abuse (to begin with -- we can be stricter later if needed). I can imagine the form also having a feature to let the original sender expose her email to the recipient to facilitate further communication. Regards, Robert From philip.homburg at ripe.net Wed Apr 24 11:00:55 2019 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 24 Apr 2019 11:00:55 +0200 Subject: [atlas] All our atlas probes have reverted to DHCP In-Reply-To: <20190417065222.q2l3xlj6ectihzth@sol.office.noris.de> References: <20190417065222.q2l3xlj6ectihzth@sol.office.noris.de> Message-ID: On 2019/04/17 8:52 , Sebastian Wiesinger wrote: > all of our four atlas probes have reverted from their fixed network > configuration to DHCP which is a shame because there is no DHCP at > their present locations. Also this not the first time it happend. Can > someone explain why this happens and how to prevent this? This wastes > a lot of time and effort every time it happens. Hi Sebastian, I have to admit I have no idea what could be going on with your probes. With static IPv4 configuration, there is a bit of complexity in how the probes switches back up DHCP if the static config doesn't work. But your probes have IPv6 as well. For v3 probes, there is always the possibility that the filesystem on the USB stick become corrupt, and then the static config gets lost as well. But 3 of your probes are V1/V2. Maybe you can let me know when you plug them in a network that does have DHCP? There might be something in the probes' logs that gets reported when they connect. Philip From gponikie at akamai.com Wed Apr 24 19:20:37 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Wed, 24 Apr 2019 17:20:37 +0000 Subject: [atlas] Communication with probes' owners In-Reply-To: <29e45396-cd55-83fe-dd67-3e32f41d4be4@ripe.net> References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> <29e45396-cd55-83fe-dd67-3e32f41d4be4@ripe.net> Message-ID: 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 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. 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? Regards, Grzegorz From: Robert Kisteleki Organization: RIPE NCC Date: Wednesday 2019-04-24 at 10:43 To: "ripe-atlas at ripe.net" Subject: Re: [atlas] Communication with probes' owners On 2019-04-23 13:10, Ponikierski, Grzegorz wrote: I thought about simple web form available only for logged users of RIPE Atlas. In this way all private data are hidden and RIPE can rate limit usage of the form. Message itself can be send to probe's owner via email from RIPE Atlas infra so sender identity also can be hidden. If somebody wants to switch to email communication then form can also be used to exchange email addresses. Regards, Grzegorz Hi, I agree that allowing RIPE Atlas users to send messages to probe hosts would be a useful feature. I also think that requiring someone to log in first before sending a message to the probe hosts is a sufficiently high bar against systematic abuse (to begin with -- we can be stricter later if needed). I can imagine the form also having a feature to let the original sender expose her email to the recipient to facilitate further communication. Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile.aben at ripe.net Thu Apr 25 07:07:34 2019 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 25 Apr 2019 07:07:34 +0200 Subject: [atlas] Communication with probes' owners In-Reply-To: References: <727692337.158.1555669582841.JavaMail.paolo.pozzan@PC-Paolo> <856CDF71-0996-4FA1-B283-33817311F5A6@schiefner.de> <968237C5-1D91-4439-8A49-D10A9A14A173@akamai.com> <29e45396-cd55-83fe-dd67-3e32f41d4be4@ripe.net> Message-ID: <7d0c3b73-2f3b-a059-7392-71e490aeadbd@ripe.net> 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 From rami.dalky at gmail.com Sat Apr 27 14:30:02 2019 From: rami.dalky at gmail.com (Rami Al-Dalky) Date: Sat, 27 Apr 2019 08:30:02 -0400 Subject: [atlas] Probes fluctuation Message-ID: Hello, I am running a number of one-off measurements and all what I request is 200 probes. However, I see a fluctuation in the number of participating probes (sometimes I get 198 and sometimes as low as 175). Any idea what is the issue? Thanks a lot, Rami -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Apr 29 11:59:51 2019 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 29 Apr 2019 11:59:51 +0200 Subject: [atlas] Probes fluctuation In-Reply-To: References: Message-ID: On 2019-04-27 14:30, Rami Al-Dalky wrote: > Hello, > > I am running a number of one-off measurements and all what I request is > 200 probes. However, I see a fluctuation in the number of participating > probes (sometimes I get 198 and sometimes as low as 175). Any idea what > is the issue? > > Thanks a lot, > Rami Hi, There's no single best answer to this. It can be that you actually got the probes you wanted, but the results were delivered later than expected (see here: https://www.ripe.net/ripe/mail/archives/ripe-atlas/2019-April/003937.html) It's also possible that the system didn't allocate the probes to you -- either because they were too busy at certain times, or we couldn't talk to them, or there are not enough probes in general to satisfy your request. It's hard to tell what's the exact cause from this distance. Hope this helps, Robert From dfk at ripe.net Tue Apr 30 10:54:39 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Tue, 30 Apr 2019 10:54:39 +0200 Subject: [atlas] Probes fluctuation In-Reply-To: References: Message-ID: On 29/04/2019 11:59, Robert Kisteleki wrote: > ... It's also possible that the system didn't allocate the probes to you -- > either because they were too busy at certain times, or we couldn't talk > to them, or there are not enough probes in general to satisfy your > request. It's hard to tell what's the exact cause from this distance. I have come across this question a number of times over the years. Wouldn't it be relatively straightforward to provide more information to the user about these conditions and decisions of the probe selection process? Daniel From camin at ripe.net Tue Apr 30 10:57:24 2019 From: camin at ripe.net (Chris Amin) Date: Tue, 30 Apr 2019 10:57:24 +0200 Subject: [atlas] Probes fluctuation In-Reply-To: References: Message-ID: On 30/04/2019 10:54, Daniel Karrenberg wrote: > I have come across this question a number of times over the years. > Wouldn't it be relatively straightforward to provide more information to > the user about these conditions and decisions of the probe selection > process? There is an ongoing work item that will achieve this. It isn't completely straightforward because probe selection is distributed and has multiple stages, but it is doable and would indeed be useful in various cases. Chris