From bortzmeyer at nic.fr Mon Sep 2 20:32:34 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 2 Sep 2013 20:32:34 +0200 Subject: [atlas] Disabling one measurement on my probe... In-Reply-To: References: Message-ID: <20130902183234.GA7760@sources.org> On Tue, Aug 27, 2013 at 05:49:00PM -0400, Warren Kumari wrote a message of 34 lines which said: > Due to much stupidity my probe lives behind 2 NATs (don't ask). Actually, I think it is a very good idea to have probes in many various setups, so we can test many cases, not just the "properly managed and IETF-sanctioned newtwork". Do note that future (currently in state AUTH48) RFC 7021 "Assessing the Impact of Carrier-Grade NAT on Network Applications" describes exactly such tests on CGN/dual-NAT/NAT444/whateveryoucallit. From bortzmeyer at nic.fr Wed Sep 4 12:31:10 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 4 Sep 2013 12:31:10 +0200 Subject: [atlas] Using Atlas for commercial services Message-ID: <20130904103110.GA8335@nic.fr> Hello, happy Atlasers, After reading (specially the part about using Atlas to monitor reachability from Nagios), the ToS and checking the FAQ , I still have a question: Can I use Atlas as a basis for commercial services? Today, most Atlas uses seem to be for public research, or for "selfish" measurements (checking my network). But I see nothing forbidding people to sell services (monitoring, quality assessment) to other people, based on Atlas. Is it on purpose? [Yes, I have one or two business ideas and I would like to know before I continue developing them.] From alexsaroyan at gmail.com Wed Sep 4 13:02:43 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Wed, 04 Sep 2013 15:02:43 +0400 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <20130904103110.GA8335@nic.fr> References: <20130904103110.GA8335@nic.fr> Message-ID: <52271353.7000907@gmail.com> Hi, Ripe atlas is sponsored by LIRs and other contributors such as probe hosts and sponsors, I have a feeling that it is not fair to make money selling services of platform which is supported by parties who are not stakeholders of the business. I don't propose to share business with all the sponsoring parties just mention that it is not fair. When you use Atlas to measure your own network's quality and ensure your companies service quality is good enough then well - this is one of purposes of the Atlas especially when you are a host or sponsor. But selling Atlas service which belongs to community and not to one company then it sounds sad. Regards. /Alex Saroyan On 09/04/2013 02:31 PM, Stephane Bortzmeyer wrote: > Hello, happy Atlasers, > > After reading > > (specially the part about using Atlas to monitor reachability from > Nagios), the ToS and checking > the FAQ , I still have a question: > > Can I use Atlas as a basis for commercial services? > > Today, most Atlas uses seem to be for public research, or for > "selfish" measurements (checking my network). But I see nothing > forbidding people to sell services (monitoring, quality assessment) to > other people, based on Atlas. Is it on purpose? > > [Yes, I have one or two business ideas and I would like to know before > I continue developing them.] > From pk at DENIC.DE Wed Sep 4 13:26:15 2013 From: pk at DENIC.DE (Peter Koch) Date: Wed, 4 Sep 2013 13:26:15 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <52271353.7000907@gmail.com> References: <20130904103110.GA8335@nic.fr> <52271353.7000907@gmail.com> Message-ID: <20130904112615.GE1181@x28.adm.denic.de> On Wed, Sep 04, 2013 at 03:02:43PM +0400, Alex Saroyan wrote: > companies service quality is good enough then well - this is one of > purposes of the Atlas especially when you are a host or sponsor. But just obeserving that you need credits to execute these measurements and IIUC there are three ways to acquire credits: hosting, sponsoring, and 'obtaining' from another credit holder. Now, if for the latter a market would evolve, that might have interesting consequences, including the 'dredits' becoming assets inthe books. I'd imagine the NCC has spent some cycles on the 'atlas credit economics' already. -Peter From bengan at resilans.se Wed Sep 4 13:36:39 2013 From: bengan at resilans.se (=?ISO-8859-1?Q?Bengt_G=F6rd=E9n?=) Date: Wed, 04 Sep 2013 13:36:39 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <52271353.7000907@gmail.com> References: <20130904103110.GA8335@nic.fr> <52271353.7000907@gmail.com> Message-ID: <52271B47.9000505@resilans.se> 2013-09-04 13:02, Alex Saroyan skrev: > Hi, > > > Ripe atlas is sponsored by LIRs and other contributors such as probe > hosts and sponsors, I have a feeling that it is not fair to make money > selling services of platform which is supported by parties who are not > stakeholders of the business. > I don't propose to share business with all the sponsoring parties just > mention that it is not fair. > > When you use Atlas to measure your own network's quality and ensure > your companies service quality is good enough then well - this is one > of purposes of the Atlas especially when you are a host or sponsor. > But selling Atlas service which belongs to community and not to one > company then it sounds sad. > Hi, As Stephane says, there seems to be something that hinders the use for commercial purposes. But I think nobody got himself a probe for others to make money off. But I could imagine that there is a radio button on my probe page to indicate that "we" (probe owner) agree that you will use this probe for that purpose, and that a certain amount of the revenue goes back to the atlas/ripe/probe-owners. regards, /bengan > Regards. > /Alex Saroyan > > On 09/04/2013 02:31 PM, Stephane Bortzmeyer wrote: >> Hello, happy Atlasers, >> >> After reading >> >> >> (specially the part about using Atlas to monitor reachability from >> Nagios), the ToS and checking >> the FAQ , I still have a question: >> >> Can I use Atlas as a basis for commercial services? >> >> Today, most Atlas uses seem to be for public research, or for >> "selfish" measurements (checking my network). But I see nothing >> forbidding people to sell services (monitoring, quality assessment) to >> other people, based on Atlas. Is it on purpose? >> >> [Yes, I have one or two business ideas and I would like to know before >> I continue developing them.] >> > > From bengan at resilans.se Wed Sep 4 13:46:17 2013 From: bengan at resilans.se (=?ISO-8859-1?Q?Bengt_G=F6rd=E9n?=) Date: Wed, 04 Sep 2013 13:46:17 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <52271B47.9000505@resilans.se> References: <20130904103110.GA8335@nic.fr> <52271353.7000907@gmail.com> <52271B47.9000505@resilans.se> Message-ID: <52271D89.90902@resilans.se> 2013-09-04 13:36, Bengt G?rd?n skrev: > 2013-09-04 13:02, Alex Saroyan skrev: >> Hi, >> >> >> Ripe atlas is sponsored by LIRs and other contributors such as probe >> hosts and sponsors, I have a feeling that it is not fair to make >> money selling services of platform which is supported by parties who >> are not stakeholders of the business. >> I don't propose to share business with all the sponsoring parties >> just mention that it is not fair. >> >> When you use Atlas to measure your own network's quality and ensure >> your companies service quality is good enough then well - this is one >> of purposes of the Atlas especially when you are a host or sponsor. >> But selling Atlas service which belongs to community and not to one >> company then it sounds sad. >> > > Hi, > > As Stephane says, there seems to be something ^^^^^^^^^^ s/something/nothing From bortzmeyer at nic.fr Wed Sep 4 14:06:33 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 4 Sep 2013 14:06:33 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <20130904103110.GA8335@nic.fr> References: <20130904103110.GA8335@nic.fr> Message-ID: <20130904120633.GA15773@nic.fr> On Wed, Sep 04, 2013 at 12:31:10PM +0200, Stephane Bortzmeyer wrote a message of 17 lines which said: > Can I use Atlas as a basis for commercial services? Oh, and, by the way, I understand that Atlas is "best effort", that I cannot sue the RIPE-NCC if it breaks and stops my commercial service, etc. From the.lists at mgm51.com Wed Sep 4 16:34:26 2013 From: the.lists at mgm51.com (Mike.) Date: Wed, 04 Sep 2013 10:34:26 -0400 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <20130904103110.GA8335@nic.fr> References: <20130904103110.GA8335@nic.fr> Message-ID: <201309041034260519.0041B08A@smtp.24cl.home> On 9/4/2013 at 12:31 PM Stephane Bortzmeyer wrote: |Hello, happy Atlasers, | |After reading | |(specially the part about using Atlas to monitor reachability from |Nagios), the ToS and checking |the FAQ , I still have a question: | |Can I use Atlas as a basis for commercial services? | |Today, most Atlas uses seem to be for public research, or for |"selfish" measurements (checking my network). But I see nothing |forbidding people to sell services (monitoring, quality assessment) to |other people, based on Atlas. Is it on purpose? | |[Yes, I have one or two business ideas and I would like to know before |I continue developing them.] ============= I would not want my network hosting the probe to be used for commercial purposes because, among myriad other reasons, I do not have a business connection with my ISP. From ghane0 at gmail.com Thu Sep 5 04:19:26 2013 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Thu, 5 Sep 2013 10:19:26 +0800 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <20130904103110.GA8335@nic.fr> References: <20130904103110.GA8335@nic.fr> Message-ID: On Wed, Sep 4, 2013 at 6:31 PM, Stephane Bortzmeyer wrote: > Can I use Atlas as a basis for commercial services? > I see no reason why not. As long as the use patterns on my probes do not change, I lose nothing, and you are welcome to make money. > Today, most Atlas uses seem to be for public research, or for > "selfish" measurements (checking my network). But I see nothing > forbidding people to sell services (monitoring, quality assessment) to > other people, based on Atlas. Is it on purpose? > I plan to use Atlas for my MSc thesis. I think this is a selfish as you selling measurements to people who want to know when their hosts are down. In any case, you will need credits to run measurements, so you must host probes, which we non-commercial guys can use -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghane0 at gmail.com Thu Sep 5 06:46:04 2013 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Thu, 5 Sep 2013 12:46:04 +0800 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <52271353.7000907@gmail.com> References: <20130904103110.GA8335@nic.fr> <52271353.7000907@gmail.com> Message-ID: On Wed, Sep 4, 2013 at 7:02 PM, Alex Saroyan wrote: > Ripe atlas is sponsored by LIRs and other contributors such as probe hosts > and sponsors, I have a feeling that it is not fair to make money selling > services of platform which is supported by parties who are not stakeholders > of the business. > I don't propose to share business with all the sponsoring parties just > mention that it is not fair. > It seems to be me that Stephane's model is no different from, eg, Red Hat. Any of the prospective customers can get a probe, rack up credits, and do their stuff for free anyway. As long as it is clear that the payment is for the service addon, not the packets themselves. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane -------------- next part -------------- An HTML attachment was scrubbed... URL: From listclient at sokolov.eu.org Thu Sep 5 06:56:26 2013 From: listclient at sokolov.eu.org (Daniel AJ Sokolov (lists)) Date: Thu, 05 Sep 2013 01:56:26 -0300 Subject: [atlas] Using Atlas for commercial services In-Reply-To: References: <20130904103110.GA8335@nic.fr> Message-ID: <52280EFA.2010405@sokolov.eu.org> On 2013-09-04 23:19 wrote Sanjeev Gupta: > > In any case, you will need credits to run measurements, so you must host > probes, And there is no guarantee you will be given a sufficient number of probes, eh. BR Daniel AJ From grinapo+ripeatlas at gmail.com Thu Sep 5 08:04:19 2013 From: grinapo+ripeatlas at gmail.com (Peter Gervai) Date: Thu, 5 Sep 2013 08:04:19 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: References: <20130904103110.GA8335@nic.fr> Message-ID: On Thu, Sep 5, 2013 at 4:19 AM, Sanjeev Gupta wrote: > On Wed, Sep 4, 2013 at 6:31 PM, Stephane Bortzmeyer > wrote: >> >> Can I use Atlas as a basis for commercial services? > > I see no reason why not. As long as the use patterns on my probes do not > change, I lose nothing, and you are welcome to make money. Exactly my point. Unless the probes don't consume significantly more resources it's there to help connectivity. If someone wants to provide a service then s/he must constantly generate credits which results more probes to be available for me. It causes me no harm if someone earns money while providing me resources. However as others mentioned it strongly requires a well balanced credit system to prevent large volume users (be they commercial or not) to consume too much resource, and to prevent small individual probe owners from starving by not being able to provide enough credits to be able to make their own measurements. Basically that's the same as open source / open content economy: commercial insterests have to provide resources to the others in exchange of their (smaller) resources. (Probably there should be some requirement to assure topologically well distributed probes from mass users.) g From ghane0 at gmail.com Thu Sep 5 11:22:50 2013 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Thu, 5 Sep 2013 17:22:50 +0800 Subject: [atlas] Using Atlas for commercial services In-Reply-To: References: <20130904103110.GA8335@nic.fr> Message-ID: On Thu, Sep 5, 2013 at 2:04 PM, Peter Gervai wrote: > Exactly my point. Unless the probes don't consume significantly more > resources it's there to help connectivity. If someone wants to provide > a service then s/he must constantly generate credits which results > more probes to be available for me. It causes me no harm if someone > earns money while providing me resources. > And while Stephane makes money, the system is being strengthened, to my advantage. I assume the new commercial offering will need, and hence place, probes in Africa as well, which I will use, for free! > However as others mentioned it strongly requires a well balanced > credit system to prevent large volume users (be they commercial or > not) to consume too much resource, and to prevent small individual > probe owners from starving by not being able to provide enough credits > to be able to make their own measurements. > The number of credits I get is not affected by what Stephane uses, right? And Stephane had better create as many credits as are required by customers. So it in the commercial entities self-interest to go sponsor more probes, and keep them online. > Basically that's the same as open source / open content economy: > commercial insterests have to provide resources to the others in > exchange of their (smaller) resources. (Probably there should be some > requirement to assure topologically well distributed probes from mass > users.) > The first service to use Atlas probably will not be well balanced, but the next few can. After all, there is nothing to stop me stealing^Wbeing inspired by the current proposal, and implementing it for Asia. Adam Smith was right, the baker and the butcher feed me by being selfish. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Thu Sep 5 11:42:52 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 5 Sep 2013 11:42:52 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: References: <20130904103110.GA8335@nic.fr> Message-ID: <20130905094252.GA29039@nic.fr> On Thu, Sep 05, 2013 at 05:22:50PM +0800, Sanjeev Gupta wrote a message of 107 lines which said: > Adam Smith was right, the baker and the butcher feed me by being selfish. So, apparently, there is no consensus among the Atlas community. An interesting discussion to have in Athens? From daniel.karrenberg at ripe.net Thu Sep 5 13:39:46 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 5 Sep 2013 13:39:46 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <20130905094252.GA29039@nic.fr> References: <20130904103110.GA8335@nic.fr> <20130905094252.GA29039@nic.fr> Message-ID: <388C4864-3D31-44C9-97AD-374FA7407DFA@ripe.net> On 05.09.2013, at 11:42 , Stephane Bortzmeyer wrote: > On Thu, Sep 05, 2013 at 05:22:50PM +0800, > Sanjeev Gupta wrote > a message of 107 lines which said: > >> Adam Smith was right, the baker and the butcher feed me by being selfish. > > So, apparently, there is no consensus among the Atlas community. An > interesting discussion to have in Athens? It is a discussion we should have in the mat-wg. The working groups work on the mailing lists; physical meetings are just focal points for the work. Daniel From hook at 2x.to Thu Sep 5 16:30:38 2013 From: hook at 2x.to (Hook) Date: Thu, 5 Sep 2013 16:30:38 +0200 Subject: [atlas] Using Atlas for commercial services Message-ID: As already said, commercial usage would also mean that you have to earn credits in some way. As far as I know, it's only possible to earn credits by - hosting probes itself - sponsoring new probes - getting a LIR In either of the first two cases, the atlas project will benefit from it. The third one is a special case and isn't worth a discussion. So I think we should allow commercial usage of the Atlas project, if commercial usage still means to support the Atlas project itself because of the need for credits! Would be a win-win situation. Michael 2013/9/5 Daniel Karrenberg > > On 05.09.2013, at 11:42 , Stephane Bortzmeyer wrote: > > > On Thu, Sep 05, 2013 at 05:22:50PM +0800, > > Sanjeev Gupta wrote > > a message of 107 lines which said: > > > >> Adam Smith was right, the baker and the butcher feed me by being > selfish. > > > > So, apparently, there is no consensus among the Atlas community. An > > interesting discussion to have in Athens? > > It is a discussion we should have in the mat-wg. The working groups work > on the mailing lists; physical meetings are just focal points for the work. > > Daniel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgpt at ucsd.edu Thu Sep 5 18:58:32 2013 From: tgpt at ucsd.edu (Tom Guptill) Date: Thu, 5 Sep 2013 16:58:32 +0000 Subject: [atlas] Using Atlas for commercial services In-Reply-To: <52280EFA.2010405@sokolov.eu.org> Message-ID: One issue I can think of is that some probes are hosted on networks which are subsidized by public money partly on the condition that they not be used for commercial purposes. Of course you can interpret "used for commercial purposes" in more than one way (research projects can have commercial partners), but it is something to keep in mind - actually making a direct profit off of the use of a non-commercial network might be stretching the rules too far. - tg From tjeb at tjeb.nl Thu Sep 5 19:50:12 2013 From: tjeb at tjeb.nl (Jelte) Date: Thu, 05 Sep 2013 19:50:12 +0200 Subject: [atlas] Using Atlas for commercial services In-Reply-To: References: Message-ID: <5228C454.40708@tjeb.nl> On 09/05/2013 06:58 PM, Tom Guptill wrote: > > One issue I can think of is that some probes are hosted on networks > which are subsidized by public money partly on the condition that > they not be used for commercial purposes. > slightly related, or perhaps more generally, folks might object to the probe they stick in their network being used commercially, for several reasons (principle, contracts, etc). I don't think I would, but I don't think it is what people signed up for :) > Of course you can interpret "used for commercial purposes" in more > than one way (research projects can have commercial partners), but > it is something to keep in mind - actually making a direct profit > off of the use of a non-commercial network might be stretching the > rules too far. > Conceivably this could be a hosting option for your probe ([] this probe may be used for commercial services), but then again, that could open up a can of worms as well (why make the distinction solely at commercial/noncommercial, and indeed, what is commercial in the first place). Jelte From warren at kumari.net Sat Sep 7 19:24:12 2013 From: warren at kumari.net (Warren Kumari) Date: Sat, 7 Sep 2013 13:24:12 -0400 Subject: [atlas] "Spoofing" tests. Message-ID: Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it. I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack. So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things. W --- It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams From jzp-ripe at rsuc.gweep.net Sat Sep 7 19:39:09 2013 From: jzp-ripe at rsuc.gweep.net (Joe Provo) Date: Sat, 7 Sep 2013 13:39:09 -0400 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: Message-ID: <20130907173909.GA89434@gweep.net> On Sat, Sep 07, 2013 at 01:24:12PM -0400, Warren Kumari wrote: > Apologies if this has already been discussed enlist -- I took a > quick look though the archives and didn't see it. See thread "Spoofing the source IP address from a probe?" from around RIPE66. > I believe that the reason for not allowing things like tests that > send spoofed packets is that it might violate the AUP that participants > have with their ISPs / be viewed by participants ISPs as an attack. > > So, what about having a checkbox in the Probe Settings that says > something like: "I have no AUP with my ISP or I'm fine to violate > my AUP. Run intrusive or dangerous tests on this probe" ? This would > create a subset of probes that could be used for more interesting > tests, an d would allow for greater visibility into things. There was traffic seeming to support the idea of a properly opted-in method (as recently as 30 July) but there hadn't been specifics regarding the implementation nor commitment that it would get to such a one. :-) -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From daniel.karrenberg at ripe.net Sun Sep 8 13:45:13 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sun, 8 Sep 2013 13:45:13 +0200 Subject: [atlas] "Spoofing" tests. In-Reply-To: <20130907173909.GA89434@gweep.net> References: <20130907173909.GA89434@gweep.net> Message-ID: On 07.09.2013, at 19:39 , Joe Provo wrote: > There was traffic seeming to support the idea of a properly opted-in > method (as recently as 30 July) but there hadn't been specifics > regarding the implementation nor commitment that it would get to > such a one. :-) And there was traffic clearly opposed to the idea as well. I cannot see any consensus there yet, one way or the other. And then there is the question of cost to implement and priorities ... Daniel From robachevsky at isoc.org Mon Sep 9 09:33:49 2013 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Mon, 9 Sep 2013 09:33:49 +0200 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: Message-ID: <522D79DD.4010206@isoc.org> I think that would be one way to alleviate the concerns, yes. Also note that we are talking about special category of users who have somewhat more control over their network - not a typical BB user sitting behind a NAT. Another important question IMO is how these data is going to be used. Several people I talked to were supporting of the idea of instigating an "anti-spoofing" movement among the ISPs, where in order to get (and stay) on a public list of networks who care one needs to pass anti-spoofing tests. Atlas and Spoofer would be instrumental in this effort. Andrei Warren Kumari wrote on 9/7/13 7:24 PM: > Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it. > > I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack. > > So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things. > > W > > --- > It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams > > From mgalante at ripe.net Mon Sep 9 15:40:13 2013 From: mgalante at ripe.net (Michela Galante) Date: Mon, 9 Sep 2013 15:40:13 +0200 Subject: [atlas] New On RIPE Labs: The Seismograph And Other RIPE Atlas Features Message-ID: <76211FBA-7B06-489D-840D-F3064ED1D038@ripe.net> Dear colleagues, We have added a couple of new RIPE Atlas features including the Seismograph, zoomable ping graphs and others. You can find the details in an article on RIPE Labs here: https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-features Kind regards Michela Galante Project Coordinator RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Mon Sep 9 20:03:17 2013 From: warren at kumari.net (Warren Kumari) Date: Mon, 9 Sep 2013 14:03:17 -0400 Subject: [atlas] "Spoofing" tests. In-Reply-To: <522D79DD.4010206@isoc.org> References: <522D79DD.4010206@isoc.org> Message-ID: <04185AF1-E43B-44D0-813E-DD1BA5D66C31@kumari.net> On Sep 9, 2013, at 3:33 AM, Andrei Robachevsky wrote: > I think that would be one way to alleviate the concerns, yes. Also note > that we are talking about special category of users who have somewhat > more control over their network - not a typical BB user sitting behind a > NAT. > Yup. Although if some BB users behind NATs did check the box, I'm sure that they would still be useful for some tests, just not spoofing ones. Actually, that's still not true -- I came across a number of CPE devices that seem to use the following logic: 1: If the source IP is on my "internal" network perform the NAT function (rewrite, install session in NAT table, etc) 2: If the source IP is *not* on the "internal" network simply pass the packet unaltered. IIRC it was some d-link devices that that did this, I wonder how common it is? > Another important question IMO is how these data is going to be used. > Several people I talked to were supporting of the idea of instigating an > "anti-spoofing" movement among the ISPs, where in order to get (and > stay) on a public list of networks who care one needs to pass > anti-spoofing tests. Atlas and Spoofer would be instrumental in this effort. Yes -- the issue that I see with things like the Spoofer project is that they require someone to download and run a client app -- this limits the number and scope of test that they see and also creates selection bias. Yes, there is even more selection bias with Atlas probes, but Atlas seems to have a fairly wide spread these days. If even a fraction of users clicked the button? Trying to push BCP38 these days may be tilting at windmills, but can't hurt. I'm sure that a bunch of other uses could also be found for probes that are AUP free?. W > > Andrei > > Warren Kumari wrote on 9/7/13 7:24 PM: >> Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it. >> >> I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack. >> >> So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things. >> >> W >> >> --- >> It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams >> >> > -- The above email is neither interesting or relevant, but at least it provided no new information. From pk at DENIC.DE Mon Sep 9 21:37:10 2013 From: pk at DENIC.DE (Peter Koch) Date: Mon, 9 Sep 2013 21:37:10 +0200 Subject: [atlas] "Spoofing" tests. In-Reply-To: <04185AF1-E43B-44D0-813E-DD1BA5D66C31@kumari.net> References: <522D79DD.4010206@isoc.org> <04185AF1-E43B-44D0-813E-DD1BA5D66C31@kumari.net> Message-ID: <20130909193710.GB22408@x28.adm.denic.de> On Mon, Sep 09, 2013 at 02:03:17PM -0400, Warren Kumari wrote: > I'm sure that a bunch of other uses could also be found for probes that are AUP free?. sure. Why not have another checkbox [ ] I consent to the probe hosted by me participating in online protest campaigns -Peter From bortzmeyer at nic.fr Tue Sep 10 16:42:24 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 10 Sep 2013 16:42:24 +0200 Subject: [atlas] A small matter of terminology Message-ID: <20130910144224.GA1643@nic.fr> A long time ago, there was only one sort of measurement. Then, one-off measurements were created. How do we call the other category? Periodic measurements? Repeated measurements? From d_churchill at comcast.net Thu Sep 12 15:39:58 2013 From: d_churchill at comcast.net (David Churchill) Date: Thu, 12 Sep 2013 09:39:58 -0400 Subject: [atlas] No IPv6 Connection on Probe Message-ID: <000a01ceafbd$96be59a0$c43b0ce0$@net> I've noticed that my probe (12070) has not had any IPv6 connectivity for the last several days. I've reset the probe a couple of times and verified that my internet service still has full IPv6 connectivity (@http://test-ipv6.comcast.net/). Is there anything I can do to restore the IPv6 connectivity? Thanks, David C. Churchill 5285 Vinings Springs Trl Mableton, GA 30126 770.819.5935 d_churchill at comcast.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony at ripe.net Fri Sep 13 00:54:47 2013 From: antony at ripe.net (Antony Antony) Date: Fri, 13 Sep 2013 00:54:47 +0200 Subject: [atlas] No IPv6 Connection on Probe In-Reply-To: <000a01ceafbd$96be59a0$c43b0ce0$@net> References: <000a01ceafbd$96be59a0$c43b0ce0$@net> Message-ID: <20130912225447.GA9965@puppy.ripe.net> Hi David, The Atlas Controllers now see your probe as IPv6 capable. If you look at your probe page most of the connections since Aug was over IPv6. I suspect the last time the probe rebooted IPv6 RA arrived a bit later or so. By then the probe was connected to the controller over V4 and stayed that way. We are working on a better way to detect IPv6 address changes. Once we finish that IPv6 address changes will be picked faster. regards, -antony On Thu, Sep 12, 2013 at 09:39:58AM -0400, David Churchill wrote: > I've noticed that my probe (12070) has not had any IPv6 connectivity for the > last several days. I've reset the probe a couple of times and verified that > my internet service still has full IPv6 connectivity > (@http://test-ipv6.comcast.net/). Is there anything I can do to restore the > IPv6 connectivity? > > > > Thanks, > > > > David C. Churchill > > 5285 Vinings Springs Trl > > Mableton, GA 30126 > > 770.819.5935 > > d_churchill at comcast.net > > > From the.lists at mgm51.com Fri Sep 13 16:16:26 2013 From: the.lists at mgm51.com (Mike.) Date: Fri, 13 Sep 2013 10:16:26 -0400 Subject: [atlas] IPv6, RA and static IPv6 assignment Message-ID: <201309131016260303.003A1A54@smtp.24cl.home> Are there any plans to allow the probe's listening for RA to be disabled so that I can configure a static IPv6 address, router and DNS server without RA overwriting my values? From neitzel at marshlabs.gaertner.de Fri Sep 13 22:27:38 2013 From: neitzel at marshlabs.gaertner.de (neitzel at marshlabs.gaertner.de) Date: Fri, 13 Sep 2013 22:27:38 +0200 Subject: [atlas] IPv6, RA and static IPv6 assignment In-Reply-To: <201309131016260303.003A1A54@smtp.24cl.home> References: <201309131016260303.003A1A54@smtp.24cl.home> Message-ID: <201309132027.r8DKRcvW001780@miles.marshlabs.gaertner.de> mgm> Are there any plans to allow the probe's listening for RA to be mgm> disabled so that I can configure a static IPv6 address, router and DNS mgm> server without RA overwriting my values? I am a teensy litttle bit worried about the missing green checkmarks in the probe management console, too. But it is mostly that, I guess. A related issue, not mentioned on this list so far: I'm v6-multi-homed at home with 2a00:1030:100::/48 2a00:1030:1004:1000::/56 and RA-announce two prefixes/gateways on the probe's net. It's a matter of luck whether the probe auto-configures its primary address to the prefix I'd prefer (the one also used in the static prescription). (That's not specific to the ATLAS probe -- a lot of my gear is non-deterministic in this respect.) To get specific: My probe 2781 has a static configuration for: 2a00:1030:100::149 It currently uses as its primary address: p2781.probes.atlas.ripe.net has IPv6 address 2a00:1030:1004:1000:220:4aff:fee0:2212 In fact, it responds to its one static and two autoconfigured addresses. You can ping6 any of these: 2a00:1030:100::149 2a00:1030:100::220:4aff:fee0:2212 2a00:1030:1004:1000:220:4aff:fee0:2212 I'd happily trade in the two extra SLAAC adresses for a single extra static address: 2a00:1030:1004:1000::149 (You'll find the DNS for atlas.ml.gaertner.de already prepared for that. That also means that only every other ping6 on the name succeeds. :-) I'm not complaining, just pointing out actual behaviour here at my little home lab. The ATLAS project is big fun and that the RIPE ATLAS team is doing a great job! Martin From philip.homburg at ripe.net Sat Sep 14 00:01:26 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 14 Sep 2013 00:01:26 +0200 Subject: [atlas] IPv6, RA and static IPv6 assignment In-Reply-To: <201309132027.r8DKRcvW001780@miles.marshlabs.gaertner.de> References: <201309131016260303.003A1A54@smtp.24cl.home> <201309132027.r8DKRcvW001780@miles.marshlabs.gaertner.de> Message-ID: <52338B36.8070805@ripe.net> On 2013/09/13 22:27 , neitzel at marshlabs.gaertner.de wrote: > A related issue, not mentioned on this list so far: > > I'm v6-multi-homed at home with > > 2a00:1030:100::/48 > 2a00:1030:1004:1000::/56 > > and RA-announce two prefixes/gateways on the probe's net. It's a > matter of luck whether the probe auto-configures its primary address > to the prefix I'd prefer (the one also used in the static prescription). > (That's not specific to the ATLAS probe -- a lot of my gear is > non-deterministic in this respect.) > > At my home I have 4 IPv6 prefixes (2 from xs4all, HE, and 6to4). The best way to retain some sort of sanity is to make sure that all but one are deprecated. Alternatively, make sure that all just work and that it doesn't matter which one is used. The main problem there is reverse DNS. Philip From bicknell at ufp.org Sun Sep 15 02:19:22 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 14 Sep 2013 19:19:22 -0500 Subject: [atlas] "Spoofing" tests. In-Reply-To: <20130907173909.GA89434@gweep.net> References: <20130907173909.GA89434@gweep.net> Message-ID: On Sep 7, 2013, at 12:39 PM, Joe Provo wrote: > There was traffic seeming to support the idea of a properly opted-in > method (as recently as 30 July) but there hadn't been specifics > regarding the implementation nor commitment that it would get to > such a one. :-) My personal opinion is that I have no issue with _RIPE_ conducting a spoofing test using my probes, but I have an objection to letting a random person conduct a spoofing test. With the former I have confidence it won't be used for evil in any way, with the latter I can see cases where my values and the probe creators values don't completely overlap. I would like to see RIPE try and spoof a RIPE IP from all the probes, and report on the results, at least once. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tapio.sokura at iki.fi Sun Sep 15 04:04:57 2013 From: tapio.sokura at iki.fi (Tapio Sokura) Date: Sun, 15 Sep 2013 05:04:57 +0300 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: <20130907173909.GA89434@gweep.net> Message-ID: <523515C9.6060209@iki.fi> On 15.9.2013 3:19, Leo Bicknell wrote: > I would like to see RIPE try and spoof a RIPE IP from all the probes, > and report on the results, at least once. A big plus one to this suggestion. A big chunk of today's common ddos attack methods would simply disappear if all networks prevented source address spoofing. And for the rest of the attacks finding and eliminating the sources (or at least the middle men being abused for generating the traffic) would be a bit easier. A concrete demonstration on the prevalence(?) of networks allowing source address spoofing would help in getting this hole plugged, I would think. Publishing specific details about which ASes let spoofed packets out might be problematic, but publishing percentages and following how the percentage develops over time should not hurt. Tapio From randy at psg.com Sun Sep 15 04:16:02 2013 From: randy at psg.com (Randy Bush) Date: Sat, 14 Sep 2013 16:16:02 -1000 Subject: [atlas] "Spoofing" tests. In-Reply-To: <523515C9.6060209@iki.fi> References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> Message-ID: > A concrete demonstration on the prevalence(?) of networks allowing > source address spoofing would help in getting this hole plugged a jillion spoofed botnets did not make the point pretty clearly? hypothesis: atlas probes show a bias toward clueful locations. unless there is a calibration set with a different, or better yet known, bias, what useful is actually being measured? unless it's a name and shame game. and then you will want to know if things 'improve' over time, which means it is not a one-shot. randy From bicknell at ufp.org Sun Sep 15 04:22:55 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 14 Sep 2013 21:22:55 -0500 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> Message-ID: <75304DDB-3AAD-4D5D-84C9-53BB396DC32D@ufp.org> On Sep 14, 2013, at 9:16 PM, Randy Bush wrote: > hypothesis: atlas probes show a bias toward clueful locations. unless > there is a calibration set with a different, or better yet known, bias, > what useful is actually being measured? unless it's a name and shame > game. and then you will want to know if things 'improve' over time, > which means it is not a one-shot. I do not think RIPE probes are representative of the larger Internet, because they are generally run by more clueful individuals. In that sense, they represent an "ideal situation". People who know and more often than not care. If the results from this ideal situation are that a majority of probes can spoof, we might as well give up on source address validation, and move on to some other techniques to mitigate the problem. On the other side, if nearly zero probes can spoof addresses it is proof-by-example that if you care to implement BCP38, it can work and can help. That data may help convince those who don't care today that caring can result in a good outcome. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Sun Sep 15 04:57:21 2013 From: randy at psg.com (Randy Bush) Date: Sat, 14 Sep 2013 16:57:21 -1000 Subject: [atlas] "Spoofing" tests. In-Reply-To: <75304DDB-3AAD-4D5D-84C9-53BB396DC32D@ufp.org> References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> <75304DDB-3AAD-4D5D-84C9-53BB396DC32D@ufp.org> Message-ID: i am not against this in principle. but i want to see a hypothesis and an experimental design which can produce something real. >> hypothesis: atlas probes show a bias toward clueful locations. unless >> there is a calibration set with a different, or better yet known, bias, >> what useful is actually being measured? unless it's a name and shame >> game. and then you will want to know if things 'improve' over time, >> which means it is not a one-shot. > I do not think RIPE probes are representative of the larger Internet, > because they are generally run by more clueful individuals. my point. i have been calling route views "feeds from the 'clue core'." > In that sense, they represent an "ideal situation". it may be a bit of a stretch from 'bias' to 'ideal'. > People who know and more often than not care. some months ago, the ncc said over half the probes were behind nats. i.e. clue core folk took them home, where they are likely behind someone else's broadband network. then again, if you think most of the botnets are behind broadband home networks, it makes an interesting sample. compare spoof density of natted vs un-natted. but then, how you gonna spoof from behind a nat? as i said, a real hypothesis and an experimental design to test it. i guess i am still stuck in middle school science class. > If the results from this ideal situation are that a majority of probes > can spoof, we might as well give up on source address validation ok, i give. with an already flawed measure, how did you decide on the majority of probes? and, if the majority of probes are behind nats, and you can not figure out how to spoof from behind a nat, then you can declare victory, such as it is. as i have said many times, i do not think ranting has done much in recent years. and having some data ain't gonna help. randy From tapio.sokura at iki.fi Sun Sep 15 05:08:54 2013 From: tapio.sokura at iki.fi (Tapio Sokura) Date: Sun, 15 Sep 2013 06:08:54 +0300 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> Message-ID: <523524C6.3050008@iki.fi> On 15.9.2013 5:16, Randy Bush wrote: >> A concrete demonstration on the prevalence(?) of networks allowing >> source address spoofing would help in getting this hole plugged > > a jillion spoofed botnets did not make the point pretty clearly? Yes, but because they are spoofed, it's not easy to determine which networks are the ones that allow spoofing. > what useful is actually being measured? unless it's a name and shame > game. and then you will want to know if things 'improve' over time, > which means it is not a one-shot. Name and shame can work in some cases. And yes, I'd like to see a trend, i.e. not making this a one-shot deal. Even if there is a bias towards probes being in networks that care, the way the figures change over time (derivative) should be less biased. Tapio From jeroen at dckd.nl Sun Sep 15 13:03:56 2013 From: jeroen at dckd.nl (Jeroen van der Ham) Date: Sun, 15 Sep 2013 13:03:56 +0200 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> Message-ID: <16C00CB0-3174-4926-8762-21931FD7FABF@dckd.nl> On 15 Sep 2013, at 04:16, Randy Bush wrote: > hypothesis: atlas probes show a bias toward clueful locations. unless > there is a calibration set with a different, or better yet known, bias, > what useful is actually being measured? unless it's a name and shame > game. and then you will want to know if things 'improve' over time, > which means it is not a one-shot. Even clueful individuals have broadband connections at home, creating a network over which they do not have much control. Especially those networks are of interest regarding the (non-)filtering of spoofed packets. Jeroen. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 275 bytes Desc: Message signed with OpenPGP using GPGMail URL: From robachevsky at isoc.org Mon Sep 16 12:51:43 2013 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Mon, 16 Sep 2013 12:51:43 +0200 Subject: [atlas] "Spoofing" tests. In-Reply-To: <523524C6.3050008@iki.fi> References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> <523524C6.3050008@iki.fi> Message-ID: <5236E2BF.7070408@isoc.org> Tapio Sokura wrote on 9/15/13 5:08 AM: > >> what useful is actually being measured? unless it's a name and shame >> game. and then you will want to know if things 'improve' over time, >> which means it is not a one-shot. > > Name and shame can work in some cases. It can be a "name and shame" with a positive spin - an "anti-spoofing" movement I mentioned before. A network can get and stay on a list if (until) they pass a spoofer or atlas test. I think it can help raise awareness and attention to this issue, at least. Andrei From daniel.karrenberg at ripe.net Mon Sep 16 14:06:40 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 16 Sep 2013 14:06:40 +0200 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> <75304DDB-3AAD-4D5D-84C9-53BB396DC32D@ufp.org> Message-ID: <14F0CF2B-08AC-4289-B8B8-B8EB85B47898@ripe.net> On 15.09.2013, at 4:57 , Randy Bush wrote: > i am not against this in principle. but i want to see a hypothesis and > an experimental design which can produce something real. I find myself agreeing with Randy. I also would like to hear an argument about what specific information and knowledge this experiment will generate over and above what is already known and measured by http://spoofer.cmand.org/ and similar experiments as well as why this experiment cannot be achieved without using RIPE Atlas. Once we have such a proposal we can have a discussion whether it is worth both the effort and the risk to RIPE Atlas. If we are going in the direction of naming and shaming I would want to hear from the RIPE community beyond the MAT WG that this is what they want; best venue for this probably is http://www.ripe.net/ripe/mail/ripe-mailing-lists/ncc-services-wg . I do not want the RIPE NCC to be criticised for spending effort here and for naming and shaming. In this discussion I will bring up http://www.ripe.net/ripe/docs/ripe-379 and my assessment of why it was not as successful as we anticipated and caution against expecting too much from additional efforts in this area. Once we have community consensus about these things and if it is to go ahead, we need to discuss relative priorities in the MAT WG, using http://roadmap.ripe.net/ripe-atlas/ . Finally: The community discussion should happen on this closed list but on http://www.ripe.net/ripe/groups/wg/mat . Daniel From becha at ripe.net Mon Sep 16 14:35:07 2013 From: becha at ripe.net (becha) Date: Mon, 16 Sep 2013 14:35:07 +0200 Subject: [atlas] RIPE Atlas anchors update Message-ID: Dear RIPE Atlas users, we are happy to share with you the results of the pilot phase of RIPE Atlas anchors, and plans for the production service. Two recent RIPE Labs article give you the details: * technical results of virtualization testing: https://labs.ripe.net/Members/romeo_zwart/further-virtualisation-testing-for-atlas-anchor * "mesh" measurements between all anchors, moving to smaller box and different hardware platform, and making the service for all, not only members: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-pilot-summary-and-next-steps We are looking forward to see you at RIPE67, MAT-WG, and in the meantime, to your comments and feedback on this list. Kind regards, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexsaroyan at gmail.com Mon Sep 16 16:39:16 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Mon, 16 Sep 2013 18:39:16 +0400 Subject: [atlas] "Spoofing" tests. In-Reply-To: <14F0CF2B-08AC-4289-B8B8-B8EB85B47898@ripe.net> References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> <75304DDB-3AAD-4D5D-84C9-53BB396DC32D@ufp.org> <14F0CF2B-08AC-4289-B8B8-B8EB85B47898@ripe.net> Message-ID: <52371814.9030002@gmail.com> Small remark: Regarding concern that many probes are behind NAT and outcome of Spoofing check will not be so effective. In future perspective: in IPv6 world none or maybe only few probes should stay behind NAT so, in case of IPv6 this spoofing check should be very effective. Regards. /Alex Saroyan On 09/16/2013 04:06 PM, Daniel Karrenberg wrote: > On 15.09.2013, at 4:57 , Randy Bush wrote: > >> i am not against this in principle. but i want to see a hypothesis and >> an experimental design which can produce something real. > I find myself agreeing with Randy. I also would like to hear an argument about what specific information and knowledge this experiment will generate over and above what is already known and measured by http://spoofer.cmand.org/ and similar experiments as well as why this experiment cannot be achieved without using RIPE Atlas. Once we have such a proposal we can have a discussion whether it is worth both the effort and the risk to RIPE Atlas. > > If we are going in the direction of naming and shaming I would want to hear from the RIPE community beyond the MAT WG that this is what they want; best venue for this probably is http://www.ripe.net/ripe/mail/ripe-mailing-lists/ncc-services-wg . I do not want the RIPE NCC to be criticised for spending effort here and for naming and shaming. In this discussion I will bring up http://www.ripe.net/ripe/docs/ripe-379 and my assessment of why it was not as successful as we anticipated and caution against expecting too much from additional efforts in this area. > > Once we have community consensus about these things and if it is to go ahead, we need to discuss relative priorities in the MAT WG, using http://roadmap.ripe.net/ripe-atlas/ . > > Finally: The community discussion should happen on this closed list but on http://www.ripe.net/ripe/groups/wg/mat . > > Daniel > > > > > From lorenzo at google.com Wed Sep 18 06:42:36 2013 From: lorenzo at google.com (Lorenzo Colitti) Date: Wed, 18 Sep 2013 13:42:36 +0900 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> <75304DDB-3AAD-4D5D-84C9-53BB396DC32D@ufp.org> Message-ID: On Sun, Sep 15, 2013 at 11:57 AM, Randy Bush wrote: > then again, if you think most of the botnets are behind broadband home > networks, it makes an interesting sample. compare spoof density of > natted vs un-natted. but then, how you gonna spoof from behind a nat? > Just send the packet? I expect a nontrivial proportion of NATs will just say "Source address not in 192.168.1.0/24? Cool, don't have to NAT! Just pass it along." :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robachevsky at isoc.org Wed Sep 18 08:37:34 2013 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Wed, 18 Sep 2013 08:37:34 +0200 Subject: [atlas] "Spoofing" tests. In-Reply-To: References: <20130907173909.GA89434@gweep.net> <523515C9.6060209@iki.fi> <75304DDB-3AAD-4D5D-84C9-53BB396DC32D@ufp.org> Message-ID: <52394A2E.8080104@isoc.org> [copying mat-wg, since it is about measureents] Lorenzo Colitti wrote on 9/18/13 6:42 AM: > On Sun, Sep 15, 2013 at 11:57 AM, Randy Bush > wrote: > > then again, if you think most of the botnets are behind broadband home > networks, it makes an interesting sample. compare spoof density of > natted vs un-natted. but then, how you gonna spoof from behind a nat? > > > Just send the packet? > > I expect a nontrivial proportion of NATs will just say "Source address > not in 192.168.1.0/24 ? Cool, don't have to NAT! > Just pass it along." :-) If only we had data ;). It would be interesting, indeed, to see how feasible spoofing is in a natted environment, broadband access networks in particular. It seems that this is the case where spoofing may cause serious problems to the provider itself, as opposed to someone else in the Internet. So, one could assume that even if there are NATs that allow this stupid thing, there maybe DOCSIS SAV and other safeguards in the BB provider provisioning system. Andrei From ot at cisco.com Thu Sep 19 12:21:19 2013 From: ot at cisco.com (Ole Troan) Date: Thu, 19 Sep 2013 12:21:19 +0200 Subject: [atlas] IPv6, RA and static IPv6 assignment In-Reply-To: <52338B36.8070805@ripe.net> References: <201309131016260303.003A1A54@smtp.24cl.home> <201309132027.r8DKRcvW001780@miles.marshlabs.gaertner.de> <52338B36.8070805@ripe.net> Message-ID: <1494B67C-8E57-4353-B288-18FF62D67FB0@cisco.com> >> A related issue, not mentioned on this list so far: >> >> I'm v6-multi-homed at home with >> >> 2a00:1030:100::/48 >> 2a00:1030:1004:1000::/56 >> >> and RA-announce two prefixes/gateways on the probe's net. It's a >> matter of luck whether the probe auto-configures its primary address >> to the prefix I'd prefer (the one also used in the static prescription). >> (That's not specific to the ATLAS probe -- a lot of my gear is >> non-deterministic in this respect.) >> >> > At my home I have 4 IPv6 prefixes (2 from xs4all, HE, and 6to4). The > best way to retain some sort of sanity is to make sure that all but one > are deprecated. > > Alternatively, make sure that all just work and that it doesn't matter > which one is used. The main problem there is reverse DNS. my home is also IPv6 multi-homed. I expect the RIPE probe to probe using both source addresses. my routing infrastructure does SADR, so the probe by choosing source address also chooses exit. cheers, Ole -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rm at romanrm.net Thu Sep 19 12:56:17 2013 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 19 Sep 2013 16:56:17 +0600 Subject: [atlas] Add E-Mail notification when a probe is back up (for more than 60 minutes) Message-ID: <20130919165617.26a3cad5@natsu> Hello, Got one of these: > Your probe 73 has been disconnected since 2013-09-19 09:26:19 UTC. > > This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 60 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/atlas/myprobes.html, click on "My Probes" and then on probe 73. In the opened tab, select "Probe's Settings" and then "Notifications" to change your settings. > > Kind regards, > > RIPE Atlas Team > What's unusual this time, is that I did not change anything in my network setup, and I can still ping the probe both on its local v4 and global v6 addresses. So one way of action would be to unplug and replug the probe in hope that it sorts out itself; 2nd course of action would be to simply wait and see if it reconnects on its own. If I choose this, I have to keep the Atlas website open in a browser tab, refreshing from time to time to see if the readings changed to "Connected". So what baffles me about this, why can't I get a simple E-Mail notification same way as "it went down", to tell me that "ok now it's back up"? -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From philip.homburg at ripe.net Thu Sep 19 14:12:57 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 19 Sep 2013 14:12:57 +0200 Subject: [atlas] IPv6, RA and static IPv6 assignment In-Reply-To: <1494B67C-8E57-4353-B288-18FF62D67FB0@cisco.com> References: <201309131016260303.003A1A54@smtp.24cl.home> <201309132027.r8DKRcvW001780@miles.marshlabs.gaertner.de> <52338B36.8070805@ripe.net> <1494B67C-8E57-4353-B288-18FF62D67FB0@cisco.com> Message-ID: <523AEA49.1080003@ripe.net> On 2013/09/19 12:21 , Ole Troan wrote: >>> >> At my home I have 4 IPv6 prefixes (2 from xs4all, HE, and 6to4). The >> best way to retain some sort of sanity is to make sure that all but one >> are deprecated. >> >> Alternatively, make sure that all just work and that it doesn't matter >> which one is used. The main problem there is reverse DNS. > > my home is also IPv6 multi-homed. I expect the RIPE probe to probe using both source addresses. > my routing infrastructure does SADR, so the probe by choosing source address also chooses exit. > > At the moment, probes do not explicitly select sources addresses. What gets used in a measurement is whatever the Linux kernel on the probe considers the best address for a particular destination. That may change in the future because source address selection may be needed for Atlas anchors, but at the moment the time frame is unknown. Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Sep 19 14:52:48 2013 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 19 Sep 2013 14:52:48 +0200 Subject: [atlas] Problems with one-off measurements Message-ID: <523AF3A0.90603@ripe.net> Dear RIPE Atlas users, It has come to our attention that one-off measurements at the moment don't produce the expected number of results. So far our investigation shows that this is most likely a probe firmware issue. We'll let you know once we find the real cause and have a fix for this. In the meantime please accept our apologies for the reduced usefulness of this function. Regards, Robert Kisteleki for the RIPE Atlas team From klaus.mailinglists at pernau.at Tue Sep 24 13:05:34 2013 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 24 Sep 2013 13:05:34 +0200 Subject: [atlas] REST API Problems for DNS measurements with DO and TCP Message-ID: <524171FE.6010604@pernau.at> Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option. According to the documentation (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant properties are use_EDNS0 and use_tcp. So I tried it with { "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_EDNS0": false, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], } but that does not work - the generated measurements do not use TCP and DO. When I create the measurement via the web interface and review the measurement via the REST API, I see that other properties are set: "do" and "protocol". E.g: # curl https://atlas.ripe.net/api/v1/measurement/1027747/ {"all_scheduling_requests_fulfilled": true, "can_visualise": false, "creation_time": 1380018470, "description": "TEST via WEB", "do": true, "dst_addr": "194.0.25.13", "dst_asn": "1921", "dst_name": "194.0.25.13", "interval": 240, "is_oneoff": true, "is_public": true, "msm_id": 1027747, "nsid": true, "participant_count": 1, "protocol": "TCP", "query": {"class": "IN", "type": "SOA", "value": "versicherung."}, "resolve_on_probe": false, "resolved_ips": ["194.0.25.13"], "result": "/api/v1/measurement/1027747/result/", "start_time": 1380018470, "status": {"id": 7, "name": "Failed"}, "stop_time": 1380018904, "type": {"id": 6, "name": "dns"}, "udp_payload_size": 512} So I tried to create measurements with the "do" and "protocol" properties, but these properties are again ignored. If I am doing something wrong, so please give me some hints. Otherwise the API documentation is wrong and these properties can not be set via REST, only via the web interface - and should be fixed. Thanks Klaus From bortzmeyer at nic.fr Wed Sep 25 10:17:44 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 25 Sep 2013 10:17:44 +0200 Subject: [atlas] REST API Problems for DNS measurements with DO and TCP In-Reply-To: <524171FE.6010604@pernau.at> References: <524171FE.6010604@pernau.at> Message-ID: <20130925081744.GA14924@nic.fr> On Tue, Sep 24, 2013 at 01:05:34PM +0200, Klaus Darilion wrote a message of 57 lines which said: > Hi! I managed to create DNS measurements via the REST API, but fail > to set the DO and protocol:TCP option. TCP worked for me (launched from the API). See public measurement #1025096, TCP is set. I just tried again (public measurement #1027850) with the attached program, launched as: python perf-dns.py -t -6 2001:678:c::1 and it seems to work From bortzmeyer at nic.fr Wed Sep 25 10:18:50 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 25 Sep 2013 10:18:50 +0200 Subject: [atlas] REST API Problems for DNS measurements with DO and TCP In-Reply-To: <20130925081744.GA14924@nic.fr> References: <524171FE.6010604@pernau.at> <20130925081744.GA14924@nic.fr> Message-ID: <20130925081849.GA15309@nic.fr> On Wed, Sep 25, 2013 at 10:17:44AM +0200, Stephane Bortzmeyer wrote a message of 16 lines which said: > I just tried again (public measurement #1027850) with the attached > program, Really attached, this time. -------------- next part -------------- A non-text attachment was scrubbed... Name: perf-dns.py Type: text/x-python Size: 3167 bytes Desc: not available URL: From robert at ripe.net Wed Sep 25 12:12:40 2013 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 25 Sep 2013 12:12:40 +0200 Subject: [atlas] Replacing "ping RRDs" with "zoomable ping graphs" Message-ID: <5242B718.4090007@ripe.net> Dear RIPE Atlas users, As you may have read in the recent RIPE Labs article (https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-features), we've replaced the old style, RRD based visualisation for built-in ping measurements with client side, zoomable graphs. Since then we've also changed the graphs that represent the probe's bandwidth usage. The new graphs have the benefit that they retain all details, even for longer time intervals. (These details were lost in the RRD based graphs over time.) Other reasons why we changed include that generating the RRD graphs did not scale well with the increasing number of RIPE Atlas probes, and making them required us to maintain a large set of backend servers, each being a single point of failure. With the new approach you still have visualisations for this information, with more details and interactivity (though it does require running JavaScript on the client side). We'll change the remaining RRDs to this new model as well in the coming period, and stop generating the RRD based images altogether. We expect to stop with the "built-in pings" and the probe traffic RRDs first, likely in the second week of October. If you would like to embed these new style visualisations into your pages (maybe because you used the RRD graphs before), then you'll have to embed a RIPEstat widget; see https://stat.ripe.net/widgets/demo/atlas_probe_widgets.html for details. Regards, Robert Kisteleki for the RIPE Atlas team From dquinn at ripe.net Wed Sep 25 12:35:43 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 25 Sep 2013 12:35:43 +0200 Subject: [atlas] REST API Problems for DNS measurements with DO and TCP In-Reply-To: <524171FE.6010604@pernau.at> References: <524171FE.6010604@pernau.at> Message-ID: <5242BC7F.1060602@ripe.net> On 09/24/2013 01:05 PM, Klaus Darilion wrote: > Hi! I managed to create DNS measurements via the REST API, but fail to > set the DO and protocol:TCP option. According to the documentation > (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant > properties are use_EDNS0 and use_tcp. So I tried it with This was a mistake in our API (my bad). There was some confusion as to what should be used (|use_EDNS0|, |use_DO|, |do|, etc.) and it caused some unpredictability in the code. I have now gone through and (hopefully) changed everything to use |do| and nothing else. I've also updated the API doc. So, for the record, the request that started this thread should look like this: |{ "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], ... }| If there are questions, or if you think that I've missed something, just let me know :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus.mailinglists at pernau.at Thu Sep 26 11:08:28 2013 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 26 Sep 2013 11:08:28 +0200 Subject: [atlas] REST API Problems for DNS measurements with DO and TCP In-Reply-To: <5242BC7F.1060602@ripe.net> References: <524171FE.6010604@pernau.at> <5242BC7F.1060602@ripe.net> Message-ID: <5243F98C.8010902@pernau.at> Hi Daniel! Thanks for the fast response. The usage of 'do' works now fine and the description is consistent with the usage. However there are still problems with 'protocol'/'use_tcp'. According to the API description, the property to use is 'use_tcp'. And using this property works when creating measurements. E.g. "use_tcp": "true", "protocol": "UDP", will use TCP for querying. But when reviewing the measurement, the property is called 'protocol', e.g. see https://atlas.ripe.net/api/v1/measurement/1028085/ 1 Scheduled TCP ... IMO, this should be consistent too. Thanks Klaus On 25.09.2013 12:35, Daniel Quinn wrote: > On 09/24/2013 01:05 PM, Klaus Darilion wrote: > >> Hi! I managed to create DNS measurements via the REST API, but fail to >> set the DO and protocol:TCP option. According to the documentation >> (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant >> properties are use_EDNS0 and use_tcp. So I tried it with > > This was a mistake in our API (my bad). There was some confusion as to > what should be used (|use_EDNS0|, |use_DO|, |do|, etc.) and it caused > some unpredictability in the code. I have now gone through and > (hopefully) changed everything to use |do| and nothing else. I've also > updated the API doc. > > So, for the record, the request that started this thread should look > like this: > > |{ > "definitions": [ > { > "is_public": true, > "is_oneoff" : false, > "target": "194.0.25.13", > "description": "a.dns.nic.versicherung_IP4_TCP_noDO", > "type": "dns", > "af": 4, > "interval": 300, > "use_TCP": true, > "use_probe_resolver": false, > "use_NSID": true, > "query_class": "IN", > "query_type": "SOA", > "query_argument": "versicherung", > "udp_payload_size": 1024, > "protocol": "TCP", > "do": true > } > ], > ... > }| > > If there are questions, or if you think that I've missed something, just > let me know :-) > From dquinn at ripe.net Thu Sep 26 14:11:11 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 26 Sep 2013 14:11:11 +0200 Subject: [atlas] REST API Problems for DNS measurements with DO and TCP In-Reply-To: <5243F98C.8010902@pernau.at> References: <524171FE.6010604@pernau.at> <5242BC7F.1060602@ripe.net> <5243F98C.8010902@pernau.at> Message-ID: <5244245F.5090100@ripe.net> On Thu 26 Sep 2013 11:08:28 AM CEST, Klaus Darilion wrote: IMO, this should be consistent too. You know what, you?re totally right. I had a rough time setting this all up in the beginning and this one slipped through the cracks. I?ve now gone ahead and made the change to the API to use |protocol| instead of |use_tcp|. New appropriate values include |TCP| or |UDP|. *Using the old method will no longer work*, and the documentation has been appropriately updated. Thanks for catching this, and my apologies to those of you who may be using |use_tcp|. I'm sure you can all agree though that consistency is best for something like this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus.mailinglists at pernau.at Thu Sep 26 15:46:08 2013 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 26 Sep 2013 15:46:08 +0200 Subject: [atlas] REST API Problems for DNS measurements with DO and TCP In-Reply-To: <5244245F.5090100@ripe.net> References: <524171FE.6010604@pernau.at> <5242BC7F.1060602@ripe.net> <5243F98C.8010902@pernau.at> <5244245F.5090100@ripe.net> Message-ID: <52443AA0.7080104@pernau.at> On 26.09.2013 14:11, Daniel Quinn wrote: > On Thu 26 Sep 2013 11:08:28 AM CEST, Klaus Darilion wrote: > > IMO, this should be consistent too. > > You know what, you?re totally right. I had a rough time setting this all > up in the beginning and this one slipped through the cracks. I?ve now > gone ahead and made the change to the API to use |protocol| instead of > |use_tcp|. New appropriate values include |TCP| or |UDP|. *Using the old > method will no longer work*, and the documentation has been > appropriately updated. > > Thanks for catching this, and my apologies to those of you who may be > using |use_tcp|. I'm sure you can all agree though that consistency is > best for something like this. I tested it and it works now as you describe. Thanks Klaus From randy at psg.com Fri Sep 27 02:47:00 2013 From: randy at psg.com (Randy Bush) Date: Thu, 26 Sep 2013 14:47:00 -1000 Subject: [atlas] finding a probe Message-ID: remote hands plugged an old style probe in. i see it on the ether port they claimed, its mac is 00:80:a3:91:4b:0d (my others are all 00:20, hmmm) i plug the dhcp-issued address 198.180.152.27 into the page at https://atlas.ripe.net/register/ it tells me there is no probe there how to debug? randy From bortzmeyer at nic.fr Mon Sep 30 16:58:21 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 30 Sep 2013 16:58:21 +0200 Subject: [atlas] Credits transfer no longer working? Message-ID: <20130930145821.GA22176@nic.fr> Did anyone notice problems with credit transfers? I run a RIPE Atlas workshop tomorrow abnd I tried to transfer credits to attendants, people with a RIPE account, both in the same LIR and outside. Nothing is credited on their side. From dquinn at ripe.net Mon Sep 30 17:13:36 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 30 Sep 2013 17:13:36 +0200 Subject: [atlas] Credits transfer no longer working? In-Reply-To: <20130930145821.GA22176@nic.fr> References: <20130930145821.GA22176@nic.fr> Message-ID: <52499520.3020108@ripe.net> Looks like a Javascript error on the page is causing things to flake out when you opt for the "Select a recipient from a list" option. If you type the address in manually it appears to work. I'll look at the issue now, but if you need this ASAP, manual entries will still do the job. From jean-philippe.pick at nic.fr Mon Sep 30 17:31:22 2013 From: jean-philippe.pick at nic.fr (Jean-Philippe Pick) Date: Mon, 30 Sep 2013 17:31:22 +0200 Subject: [atlas] Credits transfer no longer working? In-Reply-To: <52499520.3020108@ripe.net> References: <20130930145821.GA22176@nic.fr> <52499520.3020108@ripe.net> Message-ID: <20130930153122.GD31159@electron.nic.fr> On 30 Sep, Daniel Quinn wrote: > If you type the address in manually it appears to work. Hello Daniel, I just tested : transfer does not work with *newly* created RIPE Access account. I got this error message "That email address is not associated with any user in our system". But, according to the LIR Portal (Add Users > Search), the account was okay : "The user Foo Bar (foo.bar+ripe at nic.fr) has been found in RIPE NCC Access." -- Jean-Philippe From dquinn at ripe.net Mon Sep 30 17:41:59 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 30 Sep 2013 17:41:59 +0200 Subject: [atlas] Credits transfer no longer working? In-Reply-To: <20130930153122.GD31159@electron.nic.fr> References: <20130930145821.GA22176@nic.fr> <52499520.3020108@ripe.net> <20130930153122.GD31159@electron.nic.fr> Message-ID: <52499BC7.2010403@ripe.net> Without knowing the actual email address in question it's tough to know for sure, but I'm going to guess that while the user exists as part of LIR Portal, that user has yet to login and visit RIPE Atlas. For reasons I can't go into for reasons of it's long and boring, users are only considered RIPE Atlas users if they've visited the site while logged in. If you think that this is not the case, go ahead and drop me a line off-list and I'll take a look. From ivan.beveridge at dreamtime.org Mon Sep 30 19:25:33 2013 From: ivan.beveridge at dreamtime.org (Ivan Beveridge) Date: Mon, 30 Sep 2013 18:25:33 +0100 Subject: [atlas] Credits transfer no longer working? In-Reply-To: <52499BC7.2010403@ripe.net> References: <20130930145821.GA22176@nic.fr> <52499520.3020108@ripe.net> <20130930153122.GD31159@electron.nic.fr> <52499BC7.2010403@ripe.net> Message-ID: <4108da1d-ab30-45b9-98f7-bde207aad160@email.android.com> FWIW I created a new Atlas user last week and transferred credits across (by email address) without issue. I do not know how the drop-down is populated. Thx - Ivan Daniel Quinn wrote: >Without knowing the actual email address in question it's tough to know > >for sure, but I'm going to guess that while the user exists as part of >LIR Portal, that user has yet to login and visit RIPE Atlas. For >reasons I can't go into for reasons of it's long and boring, users are >only considered RIPE Atlas users if they've visited the site while >logged in. > >If you think that this is not the case, go ahead and drop me a line >off-list and I'll take a look. -- Ivan Beveridge