Re: [atlas] A number of built-ins stopped?
Hi, On 2022-12-23 18:25, Ernst J. Oud wrote: L.S. All the probes in NL that I had a look at, in a variety of different ASN’s, have no data available via the Atlas web of via the api (JSON, Magellan) for a.o. built-in measurement 1009 (ping to a.root-servers.net) and several others after December 22nd, around 18:00 hrs. UTC. When I have a look at German probes there is data available. This thus appears to be a problem with all and only Dutch probes’ data. A normal ping via a Windows command line works fine, i.e. a.root-servers.net is reachable. Creating a ping measurement via Magellan to a.root-servers.net using Dutch probes generates results, i.e. the probe infrastructure works but data storage does not, for data from probes in NL. Rather serious problem I guess. No mentioning on status.ripe.net though. I just updated the status page with an entry about this. Had an email conversation with Robert from the Atlas team today. No solution yet. We believe we've found the reason [1], and we expect these measurements to go back to normal in the next couple of hours. [1] from the status page: "the infrastructure declared some built-in measurements finished, therefore the probes stopped executing them" Happy holidays! Robert Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] A number of built-ins stopped?
L.S. All the probes in NL that I had a look at, in a variety of different ASN’s, have no data available via the Atlas web of via the api (JSON, Magellan) for a.o. built-in measurement 1009 (ping to a.root-servers.net) and several others after December 22nd, around 18:00 hrs. UTC. When I have a look at German probes there is data available. This thus appears to be a problem with all and only Dutch probes’ data. A normal ping via a Windows command line works fine, i.e. a.root-servers.net is reachable. Creating a ping measurement via Magellan to a.root-servers.net using Dutch probes generates results, i.e. the probe infrastructure works but data storage does not, for data from probes in NL. Rather serious problem I guess. No mentioning on status.ripe.net though. Had an email conversation with Robert from the Atlas team today. No solution yet. Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Credit sponsorship
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 6 Nov 2022, at 08:02, Julian Panke via ripe-atlas wrote: > Hi Finn, > > I have transferred 5 million tokens to your account. > > > Mit freundlichen Grüßen > > Julian Panke > > > > Original-Nachricht > Am 6. Nov. 2022, 08:57, schrieb Finn Holler < > finn.hol...@student.uni-tuebingen.de>: > > Hello, I am looking for probe operators, with a credit surplus, who would > want to transfer some credits to my RIPE Atlas account (email: > finn.hol...@student.uni-tuebingen.de). These credits are required for me to > interact with the measurement API, which I want to explore and ideally use, > to implement a service indicating the connectivity status of various internet > services to tenants of local student housing. The plan is to register some > probes, so this credit sponsorship is only necessary for initial trials. > Best, -Finn -- ripe-atlas mailing list ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Atlas SMTP Measurement
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 16 Oct 2022, at 02:37, Simon Brandt via ripe-atlas wrote: > Hi Michael, > > Both netcat and openssl wait for the 220 to continue. If a timeout would > occur during the STARTTLS phase, or before the 220, would this differ from a > conclusion perspective? In other words, is it necessary to test once for the > 220 to appear (or a timeout), then another time to see if the STARTTLS > completes? > > If you have a timeout while waiting for the initial 220 response (service > ready), the service is not available. Maybe the SMTP daemon is not running or > not answering for some reason, or there's a network issue. If a timeout > occurs later during the STARTTLS phase, the server is available and also the > underlying network connection seems to be fine. So yes, the conclusion would > be a different. But we still don't have to run two separate tests, i think. > > Could this be folded into a single test that does a 220, then the STARTTLS > and will report error when there’s a fail in the process? > > Yes. Since we do not really want to send an e-mail, we can probably use > OpenSSL for everything in a single run. If you use the -debug parameter, > you'll get *very* detailed output which contains all informations we want > (except for response-times, i think). There might be a more elegant way to > get a better-looking output from OpenSSL. But I don't know how, to be honest. > I haven't read the whole man-page :) > > $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 -debug > > Most work is probably to study the OpenSSL documentation, to find out the > different error messages we have to expect, depending on the problems we > might face: > > - TCP handshake not successfull > - Server does not reply with 220 (timeout) > - Server does not reply with 220 (server replies with another 4xx or 5xx code) > - Server is not ESMTP capable** > - Connection successfull, but the server does not offer 250-STARTTLS (not > supported or suppressed because of MITM attack) > - 250-STARTTLS was offered, but establishing encryption was still not > successful for some reason > > and maybe other typical certificate problems like: > > - certificate invalid (self-signed) > - certificate invalid (expired) > - certificate invalid (broken chain) > > > ** > SMTP Encryption is optional, but it is not supported by the original SMTP > protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP > "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by > RFC 1869. From a communication perspective, the main difference is, that the > initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO > = Enhanced HELO). If the server does support ESMTP, it will tell the client > it's features. If the server does not support ESMTP, it will reply with an > error. I don't know what the OpenSSL output looks like, if you try to connect > to a server which does not support ESMTP. It will probably output some error > message. This error should be evaluated by the Atlas SMTP measurement too. > 99.9% of all mailservers nowadays should support ESMTP, but there might be > some usecases... "special application blabla". It could be possible that > someone would start a Atlas SMTP measurement for a non-ESMTP compliant > target. That's why i am mention this. > > > BR, > Simon > > > > On 05.10.22 17:55, Michel Stam wrote: > Hi Simon, > > Thanks for the rundown, that helps. > > The Atlas measurement code uses something different than nc, but that isn’t > really relevant, the process is roughly the same. > > I have a question, though. Both netcat and openssl wait for the 220 to > continue. If a timeout would occur during the STARTTLS phase, or before the > 220, would this differ from a conclusion perspective? In other words, is it > necessary to test once for the 220 to appear (or a timeout), then another > time to see if the STARTTLS completes? Could this be folded into a single > test that does a 220, then the STARTTLS and will report error when there’s a > fail in the process? > > As to the TCP traceroute, this is something used by people to measure service > availability using Atlas. It isn’t something I came up with perse, but yes > its to measure response time as well as availability of the service at the > TCP level. > > With regard to additional check such as DANE, these lie somewhere between > DNSSEC and TLS measurement. I’ll make a note of this, thanks for the > suggestion. > > As to measurements in general, all currently support IPv6 to my knowledge. I > agree that new ones should support this too. > > Regards, > > Michel > > > On 1 Oct 2022, at 17:11, ripe@toppas.net wrote: > Hi Michel, > > That would would indeed mean a
Re: [atlas] RIPE Atlas SMTP Measurement
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 23 Sep 2022, at 16:08, Simon Brandt via ripe-atlas wrote: > Hi Michel, > > >Are we monitoring the Internet or monitoring a service using the proposed > >SMTP measurement? > First of all, we are monitoring the service of a specific target. Same as > http or ntp measurements, just another protocol. But we also monitor the > Internet. Using an SMTP measurement, we could identify censorship or discover > Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS > command). > > >Can we achieve the first 2 items of this measurement by doing a TCP > >traceroute on port 25? > I would say no. Using TCP Traceroute, you can may check for > reachability/responsiveness of the host, but not the actual service (smtp). > > >Does the SSL measurement cover the intended use cases? > I would say no. Correct me if am am wrong. Usually (for example HTTPS or > LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was > successfull. For SMTP, that doesn't work. That's because regular SMTP > communication starts first, so both sides can negotiate if SSL/TLS encryption > is possible (via Enhanced SMTP Status Codes). However, as far as i know, > OpenSSL does support SMTP and STARTTLS. So you could probably modify the > existing SSL measurement. > > Keep in mind that there's also MTA-STS and DANE, which are really enhancing > SMTPs security. A dedicated SMTP measurement would be a good thing. > > BR, > Simon > > > > On 23.09.22 16:04, Michel Stam wrote: > Hi everyone, > > Great that this request sparked a good discussion on the merits of a > measurement, as well as its potential impact on servers around the world. > Good to see this! > > So I’m going to do a quick recap here, hoping that I capture the intent and > the concerns correctly. Please correct me if I err. > > The intent of the measurement would be to validate whether an SMTP server is: > • reachable > • responsive > • capable of secured transmissions > > The concern is that such a check would trigger one of a variety of anti spam > measures in place around the world, and/or cause undue traffic to SMTP server > operators. > > With this in mind, I am wondering: > • Are we monitoring the Internet or monitoring a service using > the proposed SMTP measurement? > • Can we achieve the first 2 items of this measurement by doing a > TCP traceroute on port 25? > • Does the SSL measurement cover the intended use cases? > ◦ Is it worth exploring STARTTLS support as an extension and > what would the implications be? > > Have a good weekend! > > Best regards, > > Michel > > On 21 Sep 2022, at 00:11, Avamander wrote: > > Making arguments based upon extreme cases, assumptions, or > > potential-for-collateral-damage is not scientific. "I know one that even > > [...]" Anecdotal evidence isn't scientific. > > From the perspective of your previous sentences that's kinda humorous. "To > avoid unnecessary costs incurred from disruption of service, excessive > traffic, annoyances using up *my* time, and countless other reasonable > rationale from *my* point of view." Because sure, a few (hypothetical RIPE > probe) connections are exactly that, zero exaggeration, right? > > In the end such fail2ban-fueled (or similar) behaviour I initially addressed, > is exactly a non-scientific extreme-case assumption-based approach. There are > better and even more standard ways. > > Crutch solutions out in the wild shouldn't be a showstopper for measuring the > ecosystem. (That is already quite neglected) > > > What _objective_ risk/benefit analysis are you basing your opinions upon? > > And you? What's the implication here about systems being as trigger-happy as > previously described? > > Because sure, at some point rate limits make total sense, but certainly not > at the point where it would ban any potential RIPE probes. > > > Are you a systems administrator? > > Let's not get into such measuring contests, even if it is the RIPE Atlas > mailing list. > > On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas > wrote: > On 9/20/2022 10:45 AM, Avamander wrote: > Great to hear it works for you, but the potential unfortunate collateral from > such a blanket action is not really RIPE Atlas' problem. There are more > fine-grained methods against bruteforce attempts and open relay probes, than > triggering on a few connections. > What _objective_ risk/benefit analysis are you basing your opinions upon? Are > you a systems administrator? My responsibility is to avoid unnecessary costs > incurred from disruption of service, excessive traffic, annoyances using up > *my* time, and countless other reasonable
Re: [atlas] Tagging probes which are using the ISP's DNS server?
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 6 Oct 2022, at 12:32, Simon Brandt via ripe-atlas wrote: > Hi, > > Since a lot of probes use RFC1918 DNS resolvers (like home DSL/Cable routers > etc.) you can't tell, if an ISP-resolver or Public-resolver is actually used. > > Another thing I noticed is, that some eyeball providers stopped provisioning > their own DNS resolvers. Instead, they assing public resolvers like > Cloudflare to their customers. > > If the distinction isn't to difficult to implement, I would prefer these > three types as system tags: > > Inside-AS DNS > Outside-AS DNS > RFC1918 DNS > > Best Regards, > Simon > > > On 6 October 2022 09:23:15 UTC, Robert Kisteleki wrote: > Hello, > > This seems to be an interesting question. > > We can certainly apply some (system) tags for probes that have the popular > resolvers 8.8.8.8, 9.9.9.9 and so on in the resolver configuration. This > would allow users like you to easily filter for, or filter out, probes that > do this. > > One complication is that in many cases probes (an by extension, the users) > have such a public resolver *in addition to* whatever else they use - which > complicates the semantics of what resolver was actually used. But I guess one > can accept that as a fact and still consider the feature to be useful. > > As an extension, we can, if that's deemed useful, tag other resolvers, along > the lines of: > * resolvers on private IPs (ie. on-net in the home?) > * mixed private-and-quadX > * mixed private-and-public > > If we go this far, a probe could have multiple tags, eg. uses- + > uses-private + mixed-private-and-quad. This may be overdoing it... > > We'd be curious about what you think. > > Regards, > Robert > > > On 2022-10-06 03:38, Max Grobecker wrote: > Hi, > > a few days ago I wanted to debug a name resolution problem of one of our > domains. > For this reason, I wanted to test if probes inside a specific ASN are having > difficulties to resolve a specific name (because only customers of this ISP > were complaining). > This lead to very mixed results, mostly because some of the selected probes > did queries to a public DNS service like Google, Quad9 and so on. > The problem existed only with the provider's DNS servers for some reason. > > > It did take some time to make a script which tried to filter out these > probes, so I wondered if anyone else had the same use-case and problem. > Is there a way to automatically tag probes, which are (seemingly) using the > ISP's own DNS servers, or, at least, not a well-known public service? > This could be done maybe by querying a special DNS name which returns the IP > address from where the query was received (like "whoami.akamai.net"). > By comparing the ASN of the probe and the ASN of the IP address returned by > the DNS query, one could determine, if the ISP's servers are used. > This would also be true for people running their own recursor, but this could > be filtered as well very easy. > If an ISP is using multiple ASN, this could be a problem. Maybe there's an > easy solution for this as well. > > Probes which pass this test, could then be tagged with "DNS-using-ISP-server" > or something like that and explicitly be selected for specific DNS resolution > tests. > > > Greetings, > Max > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] v4 Probe Available
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 10 Oct 2022, at 10:06, Alexander Burke via ripe-atlas wrote: > Hello all, > > I have one more v4 probe available for distribution. If anyone is interested > in (reliably!) hosting it, please email me off-list with your address, and > I'll get it out to you. > > First reply gets it. > > Cheers, > Alex > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
[atlas] Apologies for OOO reply
Hi all, As some of you might have seen, something went wrong with my out-of-office email settings, and I'm sorry that you received the email multiple times. We're cleaning up the mailing list, and I wish you all happy holidays and a great year ahead. Kind regards, Guy Meyer -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Atlas SMTP Measurement
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 1 Oct 2022, at 16:11, Simon Brandt via ripe-atlas wrote: > Hi Michel, > > That would would indeed mean a combination of TCP and SSL measurement to > achieve all 3 required functions. Is it problematic if the result comes from > multiple steps? If so, can you explain how? > The intent of the measurement would be to validate whether an SMTP server is: > • reachable > • responsive > • capable of secured transmissions > > First, let's define the testmethod. In my opinion: > > - reachable > 3-way TCP Handshake with target on tcp/25 successful? > > - responsive > when establishing and SMTP connection, does the smtp-server signalize > readiness of the service (SMTP 220)? > > - capable of secured transmissions > when sending an EHLO, the server will tell us his features. 250-STARTTLS > should be there. > > > For all three checks, it's the easiest to use netcat. > > Reachability: > $ nc -vz mahimahi.ripe.net 25 > mahimahi.ripe.net [193.0.19.114] 25 (smtp) open > > Note, that we have not measured the response time. That's why you wanted to > use TCP Traceroute, right? We can also go with TCP Traceroute here. > > > Responsiveness (wait for 220): > $ nc -C mahimahi.ripe.net 25 > 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:25:22 +0200 > quit > 221 mahimahi.ripe.net closing connection > > You might want to use the -w option here, to specify a timeout. > > > capable of secured transmissions (send EHLO and check response): > $ nc -C mahimahi.ripe.net 25 > 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:54:04 +0200 > EHLO p123456.probes.atlas.ripe.net > 250-mahimahi.ripe.net Hello p123456.probes.atlas.ripe.net [123.123.123.123] > 250-SIZE 52428800 > 250-8BITMIME > 250-ETRN > 250-PIPELINING > 250-PIPE_CONNECT > 250-STARTTLS > 250 HELP > > > To check the Certificate validity and if encryption is indeed successful, we > can use OpenSSL: > $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 > (output to long, i stripped it) > > > > You’re correct, the current SSL measurement does not support any form of > STARTTLS, this is something that would have to be considered for > implementation. I assume, much like with SMTP, similar cases could be made > for IMAP4/POP3 or XMPP. > Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp > (ftps, not sftp). > > > As i said before, there are additional e-mail security features that we could > check. There's MTA-STS, where we would have to perform a combination of HTTP > and SSL check. Also, there is DANE, where we would perform a combination of > DNS and SSL check (including DNSSEC). But DANE can be used for other > protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate > check type. > > Last but no least, we should check for Forward-confirmed reverse DNS and > matching SMTP banner, which is a combination of DNS and netcat check. This > would be a reasonable part of every smtp measurement. > > > Please note, that the creator of the measurement should either specify the > exact mailserver FQDN, or the target Domain. In the latter case, an MX record > lookup has to be performed before the measurement starts, not while the > measurement is running. Otherwise it could cause credit consumption trouble, > if suddenly multiple mx records are added the domain, while the measurement > is running. > > Oh, and please make the SMTP measurement IPv6 capable :) > > > BR, > Simon > > > > On 29.09.22 11:50, Michel Stam wrote: > Hi Simon, > > >Can we achieve the first 2 items of this measurement by doing a TCP > >traceroute on port 25? > I would say no. Using TCP Traceroute, you can may check for > reachability/responsiveness of the host, but not the actual service (smtp). > > That would would indeed mean a combination of TCP and SSL measurement to > achieve all 3 required functions. Is it problematic if the result comes from > multiple steps? If so, can you explain how? > > I just noticed that the SSL measurement offers a time to connect, response > time, certificates as well as SSL alerts which may be leveraged, see here: > https://atlas.ripe.net/docs/apis/result-format/#version-4610, under "Version > 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, > although I understand it is typically used to determine service availability. > > >Does the SSL measurement cover the intended use cases? > I would say no. Correct me if am am wrong. Usually (for example HTTPS or > LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was > successfull. For SMTP, that doesn't work. That's because regular SMTP > communication starts first, so both sides can negotiate if SSL/TLS encryption > is possible (via
Re: [atlas] V5 probes
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 30 Sep 2022, at 17:38, Simon Brandt via ripe-atlas wrote: > It was shown at RIPE84: > > https://mobile.twitter.com/bortzmeyer/status/1526932317838745602 > > BR, > Simon > > > On 30.09.22 18:17, Ernst J. Oud wrote: > L.S. > > Is there a sneak preview of the V5 probes available somewhere? > > Regards, > > Ernst J. Oud > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Atlas SMTP Measurement
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 27 Sep 2022, at 00:12, Simon Brandt via ripe-atlas wrote: > Hi everyone, > > multiple times, i wrote about "enhanced SMTP Status Codes". That was > nonsense. What i meant were Extended SMTP commands (e.g. 250-STARTTLS). > Sounds similar, but is something different: > > ESMTP - https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Extensions > Enhanced Status Codes - > https://en.wikipedia.org/wiki/List_of_SMTP_server_return_codes#Enhanced_status_code > > My apologies! > > > Best regards, > Simon > > > > On 23.09.22 17:08, Simon Brandt via ripe-atlas wrote: > Hi Michel, > > >Are we monitoring the Internet or monitoring a service using the proposed > >SMTP measurement? > First of all, we are monitoring the service of a specific target. Same as > http or ntp measurements, just another protocol. But we also monitor the > Internet. Using an SMTP measurement, we could identify censorship or discover > Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS > command). > > >Can we achieve the first 2 items of this measurement by doing a TCP > >traceroute on port 25? > I would say no. Using TCP Traceroute, you can may check for > reachability/responsiveness of the host, but not the actual service (smtp). > > >Does the SSL measurement cover the intended use cases? > I would say no. Correct me if am am wrong. Usually (for example HTTPS or > LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was > successfull. For SMTP, that doesn't work. That's because regular SMTP > communication starts first, so both sides can negotiate if SSL/TLS encryption > is possible (via Enhanced SMTP Status Codes). However, as far as i know, > OpenSSL does support SMTP and STARTTLS. So you could probably modify the > existing SSL measurement. > > Keep in mind that there's also MTA-STS and DANE, which are really enhancing > SMTPs security. A dedicated SMTP measurement would be a good thing. > > BR, > Simon > > > > On 23.09.22 16:04, Michel Stam wrote: > Hi everyone, > > Great that this request sparked a good discussion on the merits of a > measurement, as well as its potential impact on servers around the world. > Good to see this! > > So I’m going to do a quick recap here, hoping that I capture the intent and > the concerns correctly. Please correct me if I err. > > The intent of the measurement would be to validate whether an SMTP server is: > • reachable > • responsive > • capable of secured transmissions > > The concern is that such a check would trigger one of a variety of anti spam > measures in place around the world, and/or cause undue traffic to SMTP server > operators. > > With this in mind, I am wondering: > • Are we monitoring the Internet or monitoring a service using > the proposed SMTP measurement? > • Can we achieve the first 2 items of this measurement by doing a > TCP traceroute on port 25? > • Does the SSL measurement cover the intended use cases? > ◦ Is it worth exploring STARTTLS support as an extension and > what would the implications be? > > Have a good weekend! > > Best regards, > > Michel > > On 21 Sep 2022, at 00:11, Avamander wrote: > > Making arguments based upon extreme cases, assumptions, or > > potential-for-collateral-damage is not scientific. "I know one that even > > [...]" Anecdotal evidence isn't scientific. > > From the perspective of your previous sentences that's kinda humorous. "To > avoid unnecessary costs incurred from disruption of service, excessive > traffic, annoyances using up *my* time, and countless other reasonable > rationale from *my* point of view." Because sure, a few (hypothetical RIPE > probe) connections are exactly that, zero exaggeration, right? > > In the end such fail2ban-fueled (or similar) behaviour I initially addressed, > is exactly a non-scientific extreme-case assumption-based approach. There are > better and even more standard ways. > > Crutch solutions out in the wild shouldn't be a showstopper for measuring the > ecosystem. (That is already quite neglected) > > > What _objective_ risk/benefit analysis are you basing your opinions upon? > > And you? What's the implication here about systems being as trigger-happy as > previously described? > > Because sure, at some point rate limits make total sense, but certainly not > at the point where it would ban any potential RIPE probes. > > > Are you a systems administrator? > > Let's not get into such measuring contests, even if it is the RIPE Atlas > mailing list. > > On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas > wrote: > On 9/20/2022 10:45 AM, Avamander wrote: > Great to hear it works for
Re: [atlas] V5 probes
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 2 Oct 2022, at 02:05, Simon Brandt via ripe-atlas wrote: > By the way, a lot of them are already registered (Probe IDs 6). > > https://atlas.ripe.net/probes/60006/ > https://atlas.ripe.net/probes/60008/ > https://atlas.ripe.net/probes/60009/ > https://atlas.ripe.net/probes/60011/ > https://atlas.ripe.net/probes/60012/ > https://atlas.ripe.net/probes/60018/ > https://atlas.ripe.net/probes/60019/ > https://atlas.ripe.net/probes/60023/ > ... > https://atlas.ripe.net/probes/63101/ > > Currently, there are ~3100 registered v5 probes, of which only 35 are online. > The others are not yet in use (never connected). As far as i can see, the > first v5 probes went online in january this year. The architecture type is > "atlas-mox". > > > BR, > Simon > > > On 30.09.22 18:38, ripe@toppas.net wrote: > It was shown at RIPE84: > > https://mobile.twitter.com/bortzmeyer/status/1526932317838745602 > > BR, > Simon > > > On 30.09.22 18:17, Ernst J. Oud wrote: > L.S. > > Is there a sneak preview of the V5 probes available somewhere? > > Regards, > > Ernst J. Oud > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V5 probes
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 2 Oct 2022, at 14:27, Simon Brandt via ripe-atlas wrote: > You can get the specs from the RIPE84 photo: > > 256MB DDR3L - SK Hynix H5TC4G63CFR > 4GB eMMC Flash - SK Hynix H26M31001HPR > ARMv8 CPU - Marvell Armada 3720 (88F3720) > Micro-USB Port > > But the sample shown at RIPE84 was a prototype. Some things might have > changed. > > However, it looks like the prototype has some GPIO ports? Oh boy, what can we > expect? Hardware extension boards? Maybe we could create some sort of global > radiation measurement network, connect outdoor heat sensors or stuff like > that^^ > > > BR, > Simon > > > On 02.10.22 14:58, Eric Kochen wrote: > Have a look at this: > > https://atlas.ripe.net/docs/probe-v5/ > > Might be USB-C? > > Op 2 okt. 2022, om 14:33 heeft Alexander Burke via ripe-atlas > het volgende geschreven: > I really hope that's USB-C and not Micro USB. > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V5 probes
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 2 Oct 2022, at 21:39, Alexander Burke via ripe-atlas wrote: > Hi Bjørn, > > Micro-USB is mechanically inferior: less reliable (easier to accidentally > disconnect) and less robust than USB Type-C. > > > > Oct 2, 2022 16:12:35 Bjørn Mork : > > Alexander Burke via ripe-atlas writes: > > I really hope that's USB-C and not Micro USB. > > Why would that matter? It's not like you're going to share the cable > with other devices, or ever unplug it from the probe. > > The only factor I can imagine matter to anyone would be plug-n-play > replacement of older probes. Which gives Micro USB a small advantage. > > > Bjørn > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] API error
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 5 Oct 2022, at 05:32, Dimeji Fayomi via ripe-atlas wrote: > Hi, > I have also been experiencing this authorization error when I attempt to > download first and second hop ping data of public probes. > I'd please appreciate any tips or pointers to dealing with this. > > Thanks > Dimeji > > -- > Dimeji Fayomi > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V5 probes
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 2 Oct 2022, at 13:33, Alexander Burke via ripe-atlas wrote: > I really hope that's USB-C and not Micro USB. > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V5 probes
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 3 Oct 2022, at 11:37, Simon Brandt via ripe-atlas wrote: > Hi Robert, > > i noticed that v1 probes are stuck with Firmware Version 4790. Does that > mean, they are missing crucial functionalities of the later firmwares? > > BR, > Simon > > > On 03.10.22 09:37, Robert Kisteleki wrote: > Deal All, > > Let me provide some information about the v5 probes, as it seems some of you > are interested in the details :-) > > The technical bits: the probes are derived from Turris Mox, "simplified" to > match our need (e.g. no WiFi). The specs include: Marvell Armada 3720 CPU, > 4GB eMMC, 512MB RAM, 1Gb ethernet, microUSB power. > > A few of these are up and running already, hosted by testers (incl. some > staff). We are gearing up to start distributing them via the usual channels > (applications, ambassadors, sponsors, ...) > > We do not (yet) recommend "upgrading" form earlier probes, as long as those > still work. Of course we're always interested in new locations/networks to > cover, so feel free to propose that! :-) > > Regards, > Robert Kisteleki > for the RIPE Atlas team > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Tagging probes which are using the ISP's DNS server?
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 6 Oct 2022, at 19:11, Karsten Thomann via ripe-atlas wrote: > On Thursday, 6 October 2022 19:42:58 EEST netravnen+ripel...@gmail.com wrote: > On Thu, 6 Oct 2022 at 13:32, Simon Brandt via ripe-atlas > > wrote: > If the distinction isn't to difficult to implement, I would prefer these > three types as system tags: > > Inside-AS DNS > Outside-AS DNS > RFC1918 DNS > > Agreed, these three tags would IMO satisfy *most* use cases. Certainly > mine, too. > I'm now curious how that would work with dual-stack probes using different > providers for v4 and v6... > > My probe uses my local Provider for v4 and HE for IPv6 (static /48 network > with reverse dns delegation would never be possible from my local provider). > According to that logic, using my local router as dns server for the probe, > could set all three tags depending on the used dns server. > As an example depending on the transport protocol used for dns: > - v4 uses RFC1918 IP as resolver IP and inside AS DNS Server > - v6 uses public IP of subnet and resolves via a different AS if the query is > sent over v6 > It could also be argued, that the v6 case is still Inside-AS DNS, but it > should be clear how the tags are determined. > > Or is this case in the meantime special enough to ignore it due to the rising > native v6 rollout by providers? > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Apply for Quantum Internet Hackathon: 1-2 December, 6 locations & online
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 15 Oct 2022, at 12:20, Gery Escalier via ripe-atlas wrote: > Fantastic Vesna! thank you so much for sharing it on the list! > > > Gery > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] V4 probe looses connection
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 22 Oct 2022, at 18:12, Szabolcs Sipos via ripe-atlas wrote: > 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 > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] atlas related mails come 4 times
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 2 Dec 2022, at 10:28, Peter Eckel via ripe-atlas wrote: > Hi Endre, > > looking at your E-Mail-Address I'd suspect some issue at the service > providing the "rediremail.com" addresses. > > Can you look at the full headers of all emails and see if you can finde > differences in mail routing? > > I never had any problems of that kind with this list, so I suspect the > problem lies somewhere else. > > Best regards, > > Pete. > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Atlas api down
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 14 Dec 2022, at 09:03, Alexander Burke via ripe-atlas wrote: > Hi Robert, > > If the status page is manually updated, it should probably show a prominent > note to that effect so that it is consumed well-salted. > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Atlas api down
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 14 Dec 2022, at 09:22, Alexander Burke via ripe-atlas wrote: > Hi, > > > The event shows up in the "past incidents" section of the page. Is that what > you're looking for > ? > > I'm sure it does now, but I was referring to this: > > Dec 13, 2022 20:22:57 Ernst J. Oud : > > After some two hours it appears to work again. > > status.rip.net showed no problems… > > and: > > Dec 14, 2022 09:39:25 Robert Kisteleki : > > I am updating the status page now. > > > > > Dec 14, 2022 10:09:25 Robert Kisteleki : > > > > On 2022-12-14 10:03, Alexander Burke via ripe-atlas wrote: > Hi Robert, > If the status page is manually updated, it should probably show a prominent > note to that effect so that it is consumed well-salted. > > Hi, > > The event shows up in the "past incidents" section of the page. Is that what > you're looking for? > > Robert > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Credit sponsorship
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 6 Nov 2022, at 08:07, Simon Brandt via ripe-atlas wrote: > Hi Finn, > > i've just send you 10 million as well. Have fun! > > Gruß, > Simon > > > On 06.11.22 09:02, Julian Panke via ripe-atlas wrote: > Hi Finn, > > I have transferred 5 million tokens to your account. > > > Mit freundlichen Grüßen > > Julian Panke > > > > Original-Nachricht > Am 6. Nov. 2022, 08:57, schrieb Finn Holler < > finn.hol...@student.uni-tuebingen.de>: > > Hello, I am looking for probe operators, with a credit surplus, who would > want to transfer some credits to my RIPE Atlas account (email: > finn.hol...@student.uni-tuebingen.de). These credits are required for me to > interact with the measurement API, which I want to explore and ideally use, > to implement a service indicating the connectivity status of various internet > services to tenants of local student housing. The plan is to register some > probes, so this credit sponsorship is only necessary for initial trials. > Best, -Finn -- ripe-atlas mailing list ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] RIPE Atlas SMTP Measurement
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 11 Nov 2022, at 13:16, Simon Brandt via ripe-atlas wrote: > Hi Michel, > > Thanks for your feedback! > > Note: the SSL measurement currently does not use the OpenSSL library. > Is that a reason to not use OpenSSL for SMTP measurements? Are there any > reasons to not use OpenSSL? > > > BR, > Simon > > > > > On 11.11.22 13:57, Michel Stam wrote: > Hi Simon, > > This seems to have gotten a bit idle since RIPE85. Let me give a bit of an > update: > > • Adding TLSv1.3 is gonna be tricky since the SSL measurement > implements the first stages of the TLS handshake only. This means adding that > complexity to the code, which as Niall commented to me is not trivial. Note: > the SSL measurement currently does not use the OpenSSL library. > • Other than retrieving the certificate from the peer, no other > validation happens in the current SSL measurement. This includes not > validating the certificate chain, which may be a self-signed certificate. > • Adding STARTTLS the way OpenSSL has done it involves issuing > the appropriate command after receiving certain output from the remote end, > then starting the TLS handshake. This should be doable. > > Hope this helps, have a nice weekend! > > Regards, > > Michel > > On 20 Oct 2022, at 17:30, Michel Stam wrote: > Hello Simon, > > I’ll first have a look at OpenSSL to gauge the amount of effort required. > I’ll also look at the existing SSL measurement to see what that offers. That > will likely provide the best path forward. Lastly, I’ll have an internal > discussion on measuring SMTP/STARTTLS/etc. > > Ripe 85 is up next week, I’ll be attending there, so my response may be > delayed somewhat. > > Please bear with me. > > Regards, > > Michel > > On 16 Oct 2022, at 03:37, ripe@toppas.net wrote: > Hi Michael, > > Both netcat and openssl wait for the 220 to continue. If a timeout would > occur during the STARTTLS phase, or before the 220, would this differ from a > conclusion perspective? In other words, is it necessary to test once for the > 220 to appear (or a timeout), then another time to see if the STARTTLS > completes? > > If you have a timeout while waiting for the initial 220 response (service > ready), the service is not available. Maybe the SMTP daemon is not running or > not answering for some reason, or there's a network issue. If a timeout > occurs later during the STARTTLS phase, the server is available and also the > underlying network connection seems to be fine. So yes, the conclusion would > be a different. But we still don't have to run two separate tests, i think. > > Could this be folded into a single test that does a 220, then the STARTTLS > and will report error when there’s a fail in the process? > > Yes. Since we do not really want to send an e-mail, we can probably use > OpenSSL for everything in a single run. If you use the -debug parameter, > you'll get *very* detailed output which contains all informations we want > (except for response-times, i think). There might be a more elegant way to > get a better-looking output from OpenSSL. But I don't know how, to be honest. > I haven't read the whole man-page :) > > $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 -debug > > Most work is probably to study the OpenSSL documentation, to find out the > different error messages we have to expect, depending on the problems we > might face: > > - TCP handshake not successfull > - Server does not reply with 220 (timeout) > - Server does not reply with 220 (server replies with another 4xx or 5xx code) > - Server is not ESMTP capable** > - Connection successfull, but the server does not offer 250-STARTTLS (not > supported or suppressed because of MITM attack) > - 250-STARTTLS was offered, but establishing encryption was still not > successful for some reason > > and maybe other typical certificate problems like: > > - certificate invalid (self-signed) > - certificate invalid (expired) > - certificate invalid (broken chain) > > > ** > SMTP Encryption is optional, but it is not supported by the original SMTP > protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP > "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by > RFC 1869. From a communication perspective, the main difference is, that the > initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO > = Enhanced HELO). If the server does support ESMTP, it will tell the client > it's features. If the server does not support ESMTP, it will reply with an > error. I don't know what the OpenSSL output looks like, if you try to connect > to a server which does not support ESMTP. It will probably output some error >
Re: [atlas] What is the trick with "+Reuse a set from a measurement" ?????
Hello,
I am currently out of the office until January 2nd.
If this is an urgent message please reach out to my manager Robert Kisteleki or
myself directly at +31 643419539.
Happy holidays :)
Guy Meyer
On 21 Nov 2022, at 03:17, Malte Tashiro via ripe-atlas
wrote:
> Hi Barry,
>
> this function does indeed still work, but it appears that the web interface
> for it is somewhat broken?
> If I search for "traceroute" one of the results is measurement 1001589 [0],
> which has this term in the description, but searching for that measurement id
> gives no result. And in any case, the only available results seem to be very
> old looking at the ids.
>
> What _does_ work is using the measurement API, for example:
>
> "probes": [
> {
> "type": "msm",
> "value": your_msm_id_here,
> "requested": number_of_probes_here
> }
> ]
>
> Not sure this is the answer you wanted to hear, but maybe someone from the
> Atlas development team can figure out what's up with the web interface.
>
> Best,
> Malte
>
> [0] https://atlas.ripe.net/measurements/1001589
>
> On 11/21/22 03:16, Barry Greene wrote:
> Hi Team,
> I’m trying to use “+Reuse a set from a measurement.” (See
> https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html
> )
> I’m going back to my own measurements and trying different Measurement IDs.
> None of them work. I try from someone else’s test. None of them work.
> Q. Does this function work anymore?
> Barry
> --
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Unknown probe in my account
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 26 Nov 2022, at 20:09, Simon Brandt via ripe-atlas wrote: > Hi Giuseppe, > > it's one of the new v5 probes. The RIPE Atlas team was not able to send out > new probes for a while, due to a shortage of new probes. > Did you apply for a new probe some time ago? > > New probes are currently being shipped. If you are about to receive a new > probe, you can already see it in your userprofile, even before it arrives. > > BR, > Simon > > > On 26.11.22 18:41, Giuseppe Macario wrote: > Hello everyone, I have a probe that works properly but, a few weeks ago, my > account also started to show a probe that doesn't work and that I don't know. > I contacted atlas @ripe.net to ask for clarification but I didn't get > anything (apart from a semi-automated message). So could anyone delete this > unknown probe? https://atlas.ripe.net/probes/63078/ Thank you. > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Unknown probe in my account
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 26 Nov 2022, at 20:40, Simon Brandt via ripe-atlas wrote: > Hi Giuseppe, > > Did you apply for another probe some time ago? > If so, that's probably why you see a probe in your user profile, that you > don't own (yet). > > If you did not apply for a new probe, be patient and wait for an answer from > at...@ripe.net. Maybe it happened by accident. > > BR, > Simon > > On 26.11.22 21:29, Giuseppe Macario wrote: > My working probe is https://atlas.ripe.net/probes/55083/ > So, if I understand correctly, am I receiving a new probe? > > Il giorno sab 26 nov 2022 alle ore 21:11 Simon Brandt via ripe-atlas > ha scritto: > Hi Giuseppe, > > it's one of the new v5 probes. The RIPE Atlas team was not able to send out > new probes for a while, due to a shortage of new probes. > Did you apply for a new probe some time ago? > > New probes are currently being shipped. If you are about to receive a new > probe, you can already see it in your userprofile, even before it arrives. > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 15 Dec 2022, at 05:57, Alexander Burke via ripe-atlas wrote: > Hello, > > From the linked page: > > A total of 173 users scheduled at least one, 81 users have at least two, one > specific user scheduled 91.5% of all of these. > > That is surprising. What do those numbers look like if you zoom out to the > past 6/12/24 months? > > If you can count on one hand the number of users using >90% of the private > measurements over a longer timeframe than two weeks, then I submit that the > choice is clear. > > Cheers, > Alex > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: Add support for STARTTLS measurements [STARTTLS]
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 15 Dec 2022, at 05:11, Alexander Burke via ripe-atlas wrote: > Hello, > > As a security and privacy specialist, I am absolutely in favour of RIPE Atlas > gaining the ability to detect and measure phenomena such as STARTTLS > stripping, certificate replacement, etc. > > Cheers, > Alex > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: remove per-hop “late” packets from traceroute [LATE-PACKETS]
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 15 Dec 2022, at 03:55, Malte Tashiro via ripe-atlas wrote: > Hi Robert, > > I support this proposal. I only recently learned through side channels how to > correctly interpret this field, as I apparently misunderstood the description > in > the documentation, so replacing it with a counter is a good idea in my > opinion. > > Best, > Malte > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 16 Dec 2022, at 21:39, Daniel Suchy via ripe-atlas wrote: > Hello, > I support Gert here, network operators (LIRs) can have valid reasons to make > some their measurements non-public. So I don't support removal of this > feature. It's a bad idea... > > If some probe host has problem with that, why don't mark such probes as > not-available for private measurements (this can be implemented easily)? And > I think there will be only minority of probes marked like that. Majority of > hosts will not care at all... > > And keep in mind that Atlas is funded by LIRs and their money. All the > big-data infrastructure (and also making of hardware probes) costs real (and > not small) money. Existence of rivate measurements might be one reason, why > LIRs allow spending money for this useful project. Probe hosting is only > small piece in expenses within this project... > > - Daniel > > On 12/16/22 19:13, Gert Doering wrote: > Hi, > On Thu, Dec 15, 2022 at 10:41:42AM -0800, Steve Gibbard wrote: > Atlas, and the RIPE NCC, have two fairly separate constituencies: > researchers and operators. > This. > Operators (like me) are willing to host Atlas anchors and probes, and > thus contribute to the system. > I might be troubleshooting something in our network where I have no > interest in making the results public. So I value the option to have > non-public measurements. > There's no "right to see all measurements" here - if someone wants to > see something, they are free to run their own measurements with their > own credits. What I do with my credits (which do not come for free) > and who can see the results should be my decision. > Gert Doering > -- NetMaster > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Low cost, low energy consumption probe
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 19 Dec 2022, at 17:10, Stijn Jonker via ripe-atlas wrote: > Hi Ernst, Hi Others, > > I would be interested as well maybe even exploring the USB model/option. > However I would be keen to pursue only if it would be low maintenance as the > current HW probes (i.e. config via portal, sw updates covered etc). To be > fair I think an additional option might be that instead of sending out probes > for free, that somehow you can order a probe directly or via Ripe or some > reseller by providing a kitlist. As I would be keen to deploy some additional > probes here and there (think ±12 locations at the end) but don't dare to ask > for additional probes... > > So maybe instead of reinventing the wheel, @ripe would it be an consideration > to provide an kitlist/place to purchase the previous or current V5 HW model? > > -- > Met vriendelijke groet, > Stijn Jonker > > > > > On 19 Dec 2022, at 16:42, Ernst J. Oud wrote: > > Hi, > > I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for > Windows. These small PC’s consume a lot more than the Ripe supplied HW probes. > > So I looked for a cheap and *very* low energy alternative. > > TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on > Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW > has been ported to it. With some acrobatics I managed to turn it into an > excellent alternative. Runs fine, energy consumption 700 mW (!). The device > is as small as the Ripe supplied probe. > > Since the flash memory of this device is too small for some of the required > libraries, the acrobatics involved copying them to RAM and putting links to > them in flash. This means that with FTP after a power outage a couple of > files need to be copied to the device and that one command must be given > after that. > > There is a more expensive version with a USB port so that a USB stick can be > used to store those files. Will investigate that option. > > If someone here wants a detailed write-up let me know and I will invest the > time to write it. > > Regards, > > Ernst J. Oud > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Re: [atlas] Low cost, low energy consumption probe
Hello, I am currently out of the office until January 2nd. If this is an urgent message please reach out to my manager Robert Kisteleki or myself directly at +31 643419539. Happy holidays :) Guy Meyer On 21 Dec 2022, at 13:06, Stijn Jonker via ripe-atlas wrote: > Hi Michel, > > For the $dayjob, I have access to today 13, soon even more locations with > good (redundant) internet connectivity but very little compute hardware. To > the extend that there is no hypervisor, however I personally really like the > Atlas project. Will this add great value to the Atlas project, possibly not > as the locations are kind a meh / non-exotic. So I perfectly understand me > requesting a bunch of probes would be an issue. > > As such from personal pocket (depending on cost on the total #) I'm happy to > source/buy a bunch of probes. For instance, if it would work, I would be > happy to buy some TP-Link MR3020 (the V3 probe), which seems to be ±22 euro > here, and some USB sticks (and POE to USB cables) and last enroll them into > Atlas. > > Happy to discuss offlist further. > > -- > Met vriendelijke groet, > Stijn Jonker > > > On 21 Dec 2022, at 13:51, Michel Stam wrote: > > Hello Stijn, > > What kind of locations are you looking at for your probes? We don’t bite if > asked, but yes is not guaranteed :) > > The v5 hardware probe is a custom design based off the Turris Mox. > > If we would do something like this we would need to split the Atlas > application from the OS firmware, which for hardware probes currently is > bundled. This to some extent ensures that the probe is not doing anything > else (security). > > There’s a couple of considerations to be had here, mostly with regard to > support and security. > Can you detail why you want to BYOP (Build-Your-Own-Probe)? > > Regards, > > Michel > > On 19 Dec 2022, at 18:10, Stijn Jonker via ripe-atlas > wrote: > > Hi Ernst, Hi Others, > > I would be interested as well maybe even exploring the USB model/option. > However I would be keen to pursue only if it would be low maintenance as the > current HW probes (i.e. config via portal, sw updates covered etc). To be > fair I think an additional option might be that instead of sending out probes > for free, that somehow you can order a probe directly or via Ripe or some > reseller by providing a kitlist. As I would be keen to deploy some additional > probes here and there (think ±12 locations at the end) but don't dare to ask > for additional probes... > > So maybe instead of reinventing the wheel, @ripe would it be an consideration > to provide an kitlist/place to purchase the previous or current V5 HW model? > > -- > Met vriendelijke groet, > Stijn Jonker > > > > > On 19 Dec 2022, at 16:42, Ernst J. Oud wrote: > > Hi, > > I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for > Windows. These small PC’s consume a lot more than the Ripe supplied HW probes. > > So I looked for a cheap and *very* low energy alternative. > > TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on > Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW > has been ported to it. With some acrobatics I managed to turn it into an > excellent alternative. Runs fine, energy consumption 700 mW (!). The device > is as small as the Ripe supplied probe. > > Since the flash memory of this device is too small for some of the required > libraries, the acrobatics involved copying them to RAM and putting links to > them in flash. This means that with FTP after a power outage a couple of > files need to be copied to the device and that one command must be given > after that. > > There is a more expensive version with a USB port so that a USB stick can be > used to store those files. Will investigate that option. > > If someone here wants a detailed write-up let me know and I will invest the > time to write it. > > Regards, > > Ernst J. Oud > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > > > > -- > ripe-atlas mailing list > ripe-atlas@ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
