From atlas at net-principles.com Fri Aug 3 08:10:36 2012 From: atlas at net-principles.com (Miles McCredie) Date: Fri, 03 Aug 2012 02:10:36 -0400 Subject: [atlas] HTTP UDM? Message-ID: <501B6B5C.10507@net-principles.com> Are there any plans to support an HTTP UDM? Thanks -Miles From daniel.karrenberg at ripe.net Fri Aug 3 08:37:47 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 3 Aug 2012 08:37:47 +0200 Subject: [atlas] HTTP UDM? In-Reply-To: <501B6B5C.10507@net-principles.com> References: <501B6B5C.10507@net-principles.com> Message-ID: <2BEE4076-B3AC-4B69-84F4-3394182B6A3F@ripe.net> On 03.08.2012, at 08:10, Miles McCredie wrote: > Are there any plans to support an HTTP UDM? Yes, but .... it will be very basic and definitely not be there to compete with widely available "web site testing". It will likely be very restrictive on the amount of data it fetches and the number of probes. RIPE Atlas is designed as a network level measurement tool and not an application tester. We are also somewhat concerned about consequences for our probe hosts. Consider what can happen if an atlas user causes your probe to access content that is considered inappropriate or even illegal where you live and run your probe. Considering this, it would be very useful to know what it is that you want to achieve and have a discussion on what RIPE Atlas should do. Daniel From maildanrl at gmail.com Fri Aug 3 08:47:34 2012 From: maildanrl at gmail.com (Dan Luedtke) Date: Fri, 3 Aug 2012 08:47:34 +0200 Subject: [atlas] Sharing Stats? In-Reply-To: <500D4E07.2000301@ripe.net> References: <20120505132358.35d8fa31@columbia> <4FA7BA76.6030908@ripe.net> <500D4E07.2000301@ripe.net> Message-ID: On Mon, Jul 23, 2012 at 3:13 PM, Robert Kisteleki wrote: > To come back to this one: the introduction of "API keys" (see previous > mails) is also meant to facilitate sharing of such graphs and data. Thanks! From atlas at net-principles.com Fri Aug 3 17:36:12 2012 From: atlas at net-principles.com (Miles McCredie) Date: Fri, 03 Aug 2012 11:36:12 -0400 Subject: [atlas] HTTP UDM? In-Reply-To: <2BEE4076-B3AC-4B69-84F4-3394182B6A3F@ripe.net> References: <501B6B5C.10507@net-principles.com> <2BEE4076-B3AC-4B69-84F4-3394182B6A3F@ripe.net> Message-ID: <501BEFEC.9050807@net-principles.com> On 8/3/12 02:37 , Daniel Karrenberg wrote: > it will be very basic and definitely not be there to compete with > widely available "web site testing". > It will likely be very restrictive on the amount of data it fetches and the number of probes. RIPE Atlas is designed as a network level measurement tool and not an application tester. > > We are also somewhat concerned about consequences for our probe hosts. Consider what can happen if an atlas user causes your probe to access content that is considered inappropriate or even illegal where you live and run your probe. Understood. Some thoughts: - Restrict the UDM to retrieving /robots.txt. (Generally innocuous/legal content and not too large?) - Limit the UDM to retrieving 4500 bytes or so of data and then sending a RST. (Enough data to confirm max MTU frames can be received but not enough to contain inappropriate or illegal content?) - Send a RST after receiving a SYN-ACK response. (Would be useful to allow port configuration in this case to allow tests for filtering.) Thanks -Miles From daniel.karrenberg at ripe.net Fri Aug 3 17:45:14 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 3 Aug 2012 17:45:14 +0200 Subject: [atlas] HTTP UDM? In-Reply-To: <501BEFEC.9050807@net-principles.com> References: <501B6B5C.10507@net-principles.com> <2BEE4076-B3AC-4B69-84F4-3394182B6A3F@ripe.net> <501BEFEC.9050807@net-principles.com> Message-ID: On 03.08.2012, at 17:36, Miles McCredie wrote: > On 8/3/12 02:37 , Daniel Karrenberg wrote: >> it will be very basic and definitely not be there to compete with >> widely available "web site testing". >> It will likely be very restrictive on the amount of data it fetches and the number of probes. RIPE Atlas is designed as a network level measurement tool and not an application tester. >> >> We are also somewhat concerned about consequences for our probe hosts. Consider what can happen if an atlas user causes your probe to access content that is considered inappropriate or even illegal where you live and run your probe. > Understood. > > Some thoughts: > - Restrict the UDM to retrieving /robots.txt. (Generally > innocuous/legal content and not too large?) > - Limit the UDM to retrieving 4500 bytes or so of data and then sending > a RST. (Enough data to confirm max MTU frames can be received but not > enough to contain inappropriate or illegal content?) > - Send a RST after receiving a SYN-ACK response. (Would be useful to > allow port configuration in this case to allow tests for filtering.) > > Thanks > -Miles In addition to those we thought about restricting to the HEAD method. This is currently our favorite. Any problems with that? Doing stuff on the TCP level is a complex thing to implement and get right, but possible. One concern remains that purely accessing a specific server/service may be regarded as inappropriate or illegal in certain places and saying "It was an Atlas probe and it only fetched robots.txt" is not going to be a viable defense. But again: what exactly are you trying to achieve/measure? Knowing that from you and others looking for HTTP UDMs would help us understand the problem space better and to propose a solution. Daniel From atlas at net-principles.com Fri Aug 3 18:01:13 2012 From: atlas at net-principles.com (Miles McCredie) Date: Fri, 03 Aug 2012 12:01:13 -0400 Subject: [atlas] HTTP UDM? In-Reply-To: References: <501B6B5C.10507@net-principles.com> <2BEE4076-B3AC-4B69-84F4-3394182B6A3F@ripe.net> <501BEFEC.9050807@net-principles.com> Message-ID: <501BF5C9.2040907@net-principles.com> On 8/3/12 11:45 , Daniel Karrenberg wrote: > But again: what exactly are you trying to achieve/measure? Knowing that from you and others looking for HTTP UDMs would help us understand the problem space better and to propose a solution. My short term interest is in collecting data about the availability of which Win8 will be using to determine connectivity to the IPv6 Internet. HEAD would be useful but "GET /ncsi.txt" would be better (and smaller :-). Longer term, I'm also interested in comparing the relative performance of IPv4 and IPv6 for dual-stack hosts and in measuring TCP port filtering. Thanks -Miles From BECHA at ripe.net Mon Aug 6 12:33:44 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 06 Aug 2012 12:33:44 +0200 Subject: [atlas] Make more measurements Message-ID: <501F9D88.6070007@ripe.net> Dear Atlas users, for few weeks already it is possible to perform *more* UDMs (User Defined Measurements), since we have increased the limits, and allowed you to spend your well-earned "credits": - you can perform up to 5 measurements simultaneously, - from up to 50 probes, - and you can spend 270,000 credits per day. A reminder of documentation location: - to see your measurements, and schedule a new one: https://atlas.ripe.net/atlas/udm.html - to find out more about UDM functionality: https://atlas.ripe.net/doc/udm You can read much more about Atlas on RIPE Labs: https://labs.ripe.net/atlas Have a great summer! Vesna From inigo at infornografia.net Mon Aug 6 13:43:46 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Mon, 6 Aug 2012 13:43:46 +0200 Subject: [atlas] Make more measurements In-Reply-To: <501F9D88.6070007@ripe.net> References: <501F9D88.6070007@ripe.net> Message-ID: Dear Atlas community (yes, _community_, as it looks more like it now ;-) On Mon, Aug 6, 2012 at 12:33 PM, Vesna Manojlovic wrote: > Dear Atlas users, > > for few weeks already it is possible to perform *more* UDMs > (User Defined Measurements), since we have increased the limits, > and allowed you to spend your well-earned "credits": > Even though it is old news, I simply wanted to thank the Atlas team for getting involved on the lists as well as making this announcement. I find this attitude very important if we want to be building a succesfull community around Atlas, and so would like to encourage you to keep making announcements so we can all stay updated. > - you can perform up to 5 measurements simultaneously, > - from up to 50 probes, > - and you can spend 270,000 credits per day. > Limits are now more reasonable than the ones used previously, which were tad bit restrictive. Im glad they have finally been raised for everyone. Worth noting the NCC staff has always been very kind towards adjusting the limits under request. > A reminder of documentation location: > > - to see your measurements, and schedule a new one: > https://atlas.ripe.net/atlas/udm.html > > - to find out more about UDM functionality: > https://atlas.ripe.net/doc/udm > > > You can read much more about Atlas on RIPE Labs: > https://labs.ripe.net/atlas > > Have a great summer! > You too! > Vesna > > Thanks everyone for the hard and fine work. Regards, -- - As? que este es el futuro del hombre: calentarse a los rayos del sol, ba?arse en las claras corrientes de agua, y comer los frutos de la tierra olvidando todo trabajo y fatiga. - Bueno, y por qu? no? "El tiempo en sus manos" From BECHA at ripe.net Wed Aug 8 16:05:34 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 08 Aug 2012 16:05:34 +0200 Subject: [atlas] RIPE Atlas Roadmap: monthly update: August Message-ID: <5022722E.5080305@ripe.net> Dear Atlas community, (thanks, Inigo ;-) while developing RIPE Atlas, we wish to keep *you* involved and informed. We are maintaining a roadmap of the features we are working on, and with this update we are asking for feedback, so that we can use it as guidance for making further plans. You can find much more details are in the RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-roadmap-august-2012-update Here I only want to copy the plans for next 4-6 weeks, and three months after that, and to repeat the questions from the article: Plans for the next month: * Users can get more flavors of customized measurements: DNS & SSL - new wizard for two new types of measurements, currently beta-tested * Making it possible to download measurements results without having to be logged in - by deploying & enabling API Keys * Making it easier to follow the rate of deployment of probes over time - by updating the graphs that show the distribution and status of probes * Atlas hosts and sponsors can meet developers during RIPE65, Amsterdam - exchange experiences, give feedback and requirements - so developers can adjust priorities Plans for Q4 2012: * Installing Atlas Anchors as new targets for pre-defined measurements - this will offer greater topological diversity for measurements - Atlas Anchors will also become powerful probes, capable of performing more measurements then small probes * In order to remind you if the probe is not plugged in or if it is down - we will add more automatic email notifications of events * We will create Internet Traffic Maps based on Atlas data - maps will illustrate the health (e.g. reachability) of measured networks Questions: - About the current functionality: what do you want us to improve? - About additions to the next release: what are the most-wanted features for each one of them? - And finally, from the less-specific planned functionalities that we will work on three-six months from now: - what do you find most important? - to which one of them shall we give most priority? Thank you for your feedback, have a great summer, and see you soon in Amsterdam, Vesna From david.lebrun at student.uclouvain.be Wed Aug 15 12:39:48 2012 From: david.lebrun at student.uclouvain.be (David Lebrun) Date: Wed, 15 Aug 2012 19:39:48 +0900 Subject: [atlas] Traceroute path consistency Message-ID: <502B7C74.4030301@student.uclouvain.be> Hi all, I have a suggestion regarding the udp traceroute feature: allowing the user to specify the source port. The motivation for this suggestion is to keep consistent paths between two traceroutes towards the same destination. I understand that the source port is used to discriminate concurrent traceroutes, so perhaps allocating a range for user-defined source ports would do the trick. There is of course the issue of two users selecting the same source port for the same destination but this is very unlikely. Do you think this is feasible ? David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From david.lebrun at student.uclouvain.be Wed Aug 15 12:44:05 2012 From: david.lebrun at student.uclouvain.be (David Lebrun) Date: Wed, 15 Aug 2012 19:44:05 +0900 Subject: [atlas] Traceroute path consistency In-Reply-To: <502B7C74.4030301@student.uclouvain.be> References: <502B7C74.4030301@student.uclouvain.be> Message-ID: <502B7D75.20002@student.uclouvain.be> On 08/15/2012 07:39 PM, David Lebrun wrote: > There is of course the issue of two users selecting the same source port > for the same destination but this is very unlikely. Correction: the issue is two users selecting the same source port for *any* destination. This becomes a bit more likely, so perhaps delaying the measurement until the port is available would fix the problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From philip.homburg at ripe.net Wed Aug 15 13:32:37 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 15 Aug 2012 13:32:37 +0200 Subject: [atlas] Traceroute path consistency In-Reply-To: <502B7C74.4030301@student.uclouvain.be> References: <502B7C74.4030301@student.uclouvain.be> Message-ID: <502B88D5.6030002@ripe.net> On 8/15/12 12:39 , David Lebrun wrote: > > I have a suggestion regarding the udp traceroute feature: allowing the > user to specify the source port. > > The motivation for this suggestion is to keep consistent paths between > two traceroutes towards the same destination. I understand that the > source port is used to discriminate concurrent traceroutes, so perhaps > allocating a range for user-defined source ports would do the trick. > > The paris-traceroute mode, which is default for firmware above 4400 keeps the source port consistent as long as a UDM is running on a probe. It does vary the destination port to trigger different routes, but the variation is included in the output (paris_id) Unfortunately, for IPv4 the source port is needed by the traceroute implementation, so it cannot be made user settable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at dckd.nl Wed Aug 15 14:05:37 2012 From: jeroen at dckd.nl (Jeroen van der Ham) Date: Wed, 15 Aug 2012 14:05:37 +0200 Subject: [atlas] Static configuration feedback Message-ID: <1226F7FE-7AF4-4A92-8035-1BE20DEC97F5@dckd.nl> Hi, I've noticed that the table on the webpage which displays the status of a probe's static configuration is not working right. If the "Static Enabled" setting is ticked, the "Probe Knows" is automatically ticked as well, *even for probes which are offline*. The feedback this gives is wrong and actually counterproductive. Could this be fixed please? Jeroen. From randy at psg.com Wed Aug 15 15:12:12 2012 From: randy at psg.com (Randy Bush) Date: Wed, 15 Aug 2012 22:12:12 +0900 Subject: [atlas] Traceroute path consistency In-Reply-To: <502B88D5.6030002@ripe.net> References: <502B7C74.4030301@student.uclouvain.be> <502B88D5.6030002@ripe.net> Message-ID: > Unfortunately, for IPv4 the source port is needed by the traceroute > implementation, so it cannot be made user settable. could you go into a bit of detail on 'needed'? randy From philip.homburg at ripe.net Wed Aug 15 15:22:17 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 15 Aug 2012 15:22:17 +0200 Subject: [atlas] Traceroute path consistency In-Reply-To: References: <502B7C74.4030301@student.uclouvain.be> <502B88D5.6030002@ripe.net> Message-ID: <502BA289.1080801@ripe.net> On 8/15/12 15:12 , Randy Bush wrote: >> Unfortunately, for IPv4 the source port is needed by the traceroute >> implementation, so it cannot be made user settable. > could you go into a bit of detail on 'needed'? > > To keep things simple, the source port encodes the index in a table of measurements. In theory, a user-settable source port together with the destination address could be used as input to a hash table or a red-black tree. From dquinn at ripe.net Thu Aug 16 14:02:21 2012 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 16 Aug 2012 14:02:21 +0200 Subject: [atlas] Static configuration feedback In-Reply-To: <1226F7FE-7AF4-4A92-8035-1BE20DEC97F5@dckd.nl> References: <1226F7FE-7AF4-4A92-8035-1BE20DEC97F5@dckd.nl> Message-ID: <2743C2BB-DE56-4A37-AE92-D88736F96F4B@ripe.net> On Aug 15, 2012, at 2:05 PM, Jeroen van der Ham wrote: > I've noticed that the table on the webpage which displays the status of a probe's static configuration is not working right. If the "Static Enabled" setting is ticked, the "Probe Knows" is automatically ticked as well, *even for probes which are offline*. > The feedback this gives is wrong and actually counterproductive. > > Could this be fixed please? Hi there, I've added this issue to my "to-do" list, and will be looking into it soon. When it's finished and pushed to production we'll let you know. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From BECHA at ripe.net Tue Aug 28 10:34:22 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 28 Aug 2012 10:34:22 +0200 Subject: [atlas] Two new measurements types, and a new interface (wizard) Message-ID: <503C828E.9060400@ripe.net> Dear Atlas community, I am happy to announce DNS & SSL certificate measurements, a new addition to the UDMs, making it in total 4 types of customized measurements you can perform! Please find out the details in the RIPE Labs article: https://labs.ripe.net/Members/becha/dns-user-defined-measurements-in-ripe-atlas In order to make more types of measurements possible, we have also introduced the new web interface: so-called wizard. It has been extensively tested by the beta-testers for two months, and we hope that the rest of the Atlas UDM users will find it handy. The old interface has been deprecated, so the usual link now leads to the new wizard: https://atlas.ripe.net/atlas/udm.html Please let us know what you think, and enjoy the measurements :) If you have a success-story to share, consider giving a presentation at the RIPE65, or writing RIPE Labs article. I am willing to work on this together with you, so do let me know if you need any help. Regards, Vesna -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 8.png Type: image/png Size: 27744 bytes Desc: not available URL: From bortzmeyer at nic.fr Tue Aug 28 10:40:32 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 28 Aug 2012 10:40:32 +0200 Subject: [atlas] Two new measurements types, and a new interface (wizard) In-Reply-To: <503C828E.9060400@ripe.net> References: <503C828E.9060400@ripe.net> Message-ID: <20120828084032.GA20976@nic.fr> On Tue, Aug 28, 2012 at 10:34:22AM +0200, Vesna Manojlovic wrote a message of 554 lines which said: > I am happy to announce DNS & SSL certificate measurements, Great but this is not the proper wording. They are X.509 certificates, not SSL certificates (SSL - TLS, actually - can use non-X.509 certificates, see RFC 6091) From philip.homburg at ripe.net Tue Aug 28 10:53:16 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 28 Aug 2012 10:53:16 +0200 Subject: [atlas] Two new measurements types, and a new interface (wizard) In-Reply-To: <20120828084032.GA20976@nic.fr> References: <503C828E.9060400@ripe.net> <20120828084032.GA20976@nic.fr> Message-ID: <503C86FC.8000701@ripe.net> On 8/28/12 10:40 , Stephane Bortzmeyer wrote: > On Tue, Aug 28, 2012 at 10:34:22AM +0200, > Vesna Manojlovic wrote > a message of 554 lines which said: > >> I am happy to announce DNS & SSL certificate measurements, > Great but this is not the proper wording. They are X.509 certificates, > not SSL certificates (SSL - TLS, actually - can use non-X.509 > certificates, see RFC 6091) > The idea is that this measurement just returns whatever certificates the SSL server presents. Do you know of a server that uses non-X.509 certificates that I can try? From robert at ripe.net Wed Aug 29 18:34:12 2012 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 29 Aug 2012 18:34:12 +0200 Subject: [atlas] Operational issue between ~14h-16h UTC Message-ID: <503E4484.8020509@ripe.net> Dear Atlas users, This afternoon our developers deployed an upgrade to the Atlas controlling infrastructure. Unfortunately, the update contained a bug that we did not catch in the test environment. This bug caused all probes to suspend their running UDMs (User Defined Measurements) between approximately 14h-16h (UTC, different probes were affected at different times). After noticing the error we reverted the changes, and resumed all UDMs. Because of this, your UDMs likely have missing data points for this time frame. Obviously, more frequent measurements will have more missing results while less frequent measurements will have less (or even nothing) missing results. "Built-in" measurements (i.e. non-UDMs) have not been affected. Based on this experience, we'll enhance our testing procedure to lower the chance of these kind of errors happening again. Excuses for the inconvenience this issue may have caused. Regards, Robert Kisteleki RIPE NCC From BECHA at ripe.net Fri Aug 31 13:50:13 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 31 Aug 2012 13:50:13 +0200 Subject: [atlas] Announcing RIPE Atlas Anchors, Pilot Phase Message-ID: <5040A4F5.2000409@ripe.net> Dear Atlas community, Please find a new article on RIPE Labs describing the details of RIPE Atlas Anchors: https://labs.ripe.net/Members/dfk/ripe-atlas-anchors Right now, we are looking for a small number of pilot hosts from the RIPE NCC membership for deployment to begin in October 2012. If you are interested, please contact me or Daniel Karrenberg before the RIPE65. We will be discussing further details at the RIPE meeting. Regards, Vesna Manojlovic -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net