From mir at ripe.net Tue Nov 1 09:32:23 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 01 Nov 2011 09:32:23 +0100 Subject: [ncc-services-wg] IPv6 RIPEness - Production & Updates In-Reply-To: <4EAFAE77.60009@ripe.net> References: <4EAFAE77.60009@ripe.net> Message-ID: <4EAFAE97.2010107@ripe.net> [apologies for duplicates] Dear colleagues, Following your feedback, we decided to make IPv6 RIPEness a production service. Please find a short update on RIPE Labs: http://labs.ripe.net/Members/becha/ipv6-ripeness-production-updates We are currently also working on some new features. Stay tuned. Kind Regards, Mirjam Kuehne RIPE NCC From denis at ripe.net Tue Nov 1 12:08:24 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 01 Nov 2011 12:08:24 +0100 Subject: [ncc-services-wg] New RIPE Database Online Forms Message-ID: <4EAFD328.1060102@ripe.net> [Apologies for duplicate emails] Dear Colleagues, The RIPE NCC Database Group is pleased to announce further improvements to the RIPE Database online forms. The old CGIs for generating an MD5 password hash and requesting a password reset have been replaced by new online forms with a much improved workflow. https://apps.db.ripe.net/crypt/crypt.html https://apps.db.ripe.net/change-auth/ This concludes the RIPE Database Group's project to migrate old online forms and CGIs to the new database platform. We will continue to develop new tools and services on this platform to further enhance the RIPE Database experience. Regards Denis Walker Business Analyst RIPE NCC Database Group From thor.kottelin at turvasana.com Tue Nov 1 12:22:08 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Tue, 1 Nov 2011 13:22:08 +0200 Subject: [ncc-services-wg] New mailing list hardware and software at the RIPE NCC References: <4E96D7EF.2040000@ripe.net> Message-ID: > -----Original Message----- > From: Thor Kottelin [mailto:thor.kottelin at turvasana.com] > Sent: Thursday, October 13, 2011 3:28 PM > To: 'ncc-services-wg at ripe.net' > > -----Original Message----- > > From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg- > > bounces at ripe.net] On Behalf Of Mihnea-Costin Grigore > > Sent: Thursday, October 13, 2011 3:22 PM > > To: ncc-services-wg at ripe.net > > > after implementation, the mailing list archives will have > > a > > slightly different look and you will need to update any direct > > links to > > messages in the archives. > > Could this be done on the server level, using HTTP redirection? Judging from the lack of response and the present brokenness of a myriad of links, apparently not. :( Please try to avoid similar flaws when carrying out future changes. -- Thor Kottelin http://www.anta.net/ From mgrigore at ripe.net Tue Nov 1 17:21:29 2011 From: mgrigore at ripe.net (Mihnea-Costin Grigore) Date: Tue, 01 Nov 2011 17:21:29 +0100 Subject: [ncc-services-wg] Fwd: Fwd: Re: New mailing list hardware and software at the RIPE NCC In-Reply-To: <4EAFF412.40505@ripe.net> References: <4EAFF0F9.6010001@ripe.net> <4EAFF412.40505@ripe.net> Message-ID: <4EB01C89.5020103@ripe.net> >> Could this be done on the server level, using HTTP redirection? > Judging from the lack of response and the present brokenness of a myriad of > links, apparently not. :( > Please try to avoid similar flaws when carrying out future changes. Hello, Thank you for your feedback, and sorry for the delay in replying. The old archiving system that was in use until recently was no longer maintained and had several issues that resulted in problems with the generated archives. In cooperation with our IT department, we chose a newer, more resilient system and completed the implementation a couple of weeks ago. Unfortunately, the message indexes follow a completely different pattern in the new system, so it is not a simple matter of redirecting through HTTP. After the feedback received regarding this move, we are looking into ways of implementing a programmatic solution that would allow old links to function with the new system. However, that will not be available straight away and will require development and testing. We apologise for the inconvenience caused in the meantime. Regards, -- Mihnea-Costin Grigore RIPE NCC Web Services Team Leader -- http://www.ripe.net From mir at ripe.net Wed Nov 2 09:52:35 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 02 Nov 2011 09:52:35 +0100 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <4EB104A9.9090903@ripe.net> References: <4EB104A9.9090903@ripe.net> Message-ID: <4EB104D3.70708@ripe.net> [Apologies for duplicate mails] Dear colleagues, RIPE Atlas has made steady progress in its first year. But we have more ambitious plans. Read in this new article on RIPE Labs how we want to achieve these plans and why we need your support: http://labs.ripe.net/Members/dfk/a-ripe-atlas-probe-for-each-ripe-ncc-member Kind Regards, Mirjam Kuehne RIPE NCC From hank at efes.iucc.ac.il Wed Nov 2 15:32:22 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 02 Nov 2011 16:32:22 +0200 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <4EB104D3.70708@ripe.net> References: <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> Message-ID: <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> At 09:52 02/11/2011 +0100, Mirjam Kuehne wrote: >[Apologies for duplicate mails] > >Dear colleagues, 2.5MEuro for a "nice to have" system? What crucial Internet problem are you trying to solve with this amount of money? -Hank >RIPE Atlas has made steady progress in its first year. But we have more >ambitious plans. Read in this new article on RIPE Labs how we want to >achieve these plans and why we need your support: > >http://labs.ripe.net/Members/dfk/a-ripe-atlas-probe-for-each-ripe-ncc-member > >Kind Regards, >Mirjam Kuehne >RIPE NCC From henk at uijterwaal.nl Thu Nov 3 08:21:56 2011 From: henk at uijterwaal.nl (Henk Uijterwaal) Date: Thu, 03 Nov 2011 08:21:56 +0100 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> References: <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> Message-ID: <4EB24114.6060907@uijterwaal.nl> On 02/11/2011 15:32, Hank Nussbacher wrote: > At 09:52 02/11/2011 +0100, Mirjam Kuehne wrote: > >> [Apologies for duplicate mails] >> >> Dear colleagues, > > 2.5MEuro for a "nice to have" system? What crucial Internet problem are you > trying to solve with this amount of money? I asked myself a similar question. 20,000 probes translates roughly to 1 per active AS, 0.25 per active prefix or 2 per current member. Let's assume for a second that we indeed install those 20,000 probes equally distributed amongst the membership. Costs are now 2.5M/8000 = 300 euro/member. Now look at my current provider. They will have 2 probes installed in a network with O(100,000) customers. That is by any standard way too low to provide any useful information in case of an operational problem. It is also way too low to do any meaningful random sampling of performance that the average customer will see. In short, one will collect lots of data but it is unclear what operational use it will have. Now turn it around: let's say we want to install the probes such that meaningful information about an AS/prefix/member can be obtained. That means installing O(100) probes per unit. But 20000/100=200, so 7800 members will not benefit from this service. In this case, you'd think that the 200 members using the service pay for it (and the others don't). However, 2.5M/200 = 12,500 euro/participant. Looking at the TTM service, I seriously doubt that there will be 200 members willing to pay for this, plus that providing a service for only a small group is not what the RIPE NCC is supposed to be doing. Either way, I have to agree with Hank that the usefulness of this project is very limited. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From daniel.karrenberg at ripe.net Thu Nov 3 15:31:40 2011 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 3 Nov 2011 15:31:40 +0100 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <4EB24114.6060907@uijterwaal.nl> References: <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> <4EB24114.6060907@uijterwaal.nl> Message-ID: <20111103143140.GA591@reifripenet.local> Henk, good to hear from you again. RIPE Atlas is not intended for intra-AS measurements. Operators generally have their networks very well instrumented. RIPE Atlas is about situational awareness about the inter-AS mesh. Of course we want to have a number of probes inside big ASes, but most stub ASes are nicely covered with one or two. We would not provide other than incidental intra-AS measuremenets from the proposed funding unless the operator concerned provides additional funding and the results will be both available and useful for the community. So I am indeed proposing to distribute the probes and benefits as equally among the membership as possible. And the cost of 300 EUR for each member that you quote is for the deployment and two years of operations, so it comes down to EUR150/member/year for the first two years. About the usefulness of RIPE Atlas let me say just this much: At least one active probe in the network of each member would make for an unprecedented level of comprehensive active measurmenets. Products from these measurements are useful for detecting anomalies, monitoring trends and for analysing faults. Daniel From hank at efes.iucc.ac.il Thu Nov 3 17:47:30 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 03 Nov 2011 18:47:30 +0200 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <20111103143140.GA591@reifripenet.local> References: <4EB24114.6060907@uijterwaal.nl> <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> <4EB24114.6060907@uijterwaal.nl> Message-ID: <5.1.0.14.2.20111103183837.03623cd0@efes.iucc.ac.il> At 15:31 03/11/2011 +0100, Daniel Karrenberg wrote: >Henk, > >good to hear from you again. > >RIPE Atlas is not intended for intra-AS measurements. Operators >generally have their networks very well instrumented. RIPE Atlas is about >situational awareness about the inter-AS mesh. Of course we want to >have a number of probes inside big ASes, but most stub ASes are nicely >covered with one or two. We would not provide other than incidental >intra-AS measuremenets from the proposed funding unless the operator >concerned provides additional funding and the results will be both >available and useful for the community. > >So I am indeed proposing to distribute the probes and benefits as >equally among the membership as possible. And the cost of 300 EUR for >each member that you quote is for the deployment and two years of >operations, so it comes down to EUR150/member/year for the first >two years. I believe only 1% of the RIPE membership would make weekly use of such probes - you might believe I am way off and feel 10% of the RIPE membership would make use of such probes. Well, there is a simple way to determine whether the membership wants to spend a few million Euro on this - ask them via a poll. If a majority of those responding feel it is important - then you have your mandate. If a majority think otherwise, you don't have a mandate to spend all that money. It is called democracy. -Hank >About the usefulness of RIPE Atlas let me say just this much: >At least one active probe in the network of each member would >make for an unprecedented level of comprehensive active measurmenets. >Products from these measurements are useful for detecting anomalies, >monitoring trends and for analysing faults. > >Daniel From henk at uijterwaal.nl Fri Nov 4 08:21:14 2011 From: henk at uijterwaal.nl (Henk Uijterwaal) Date: Fri, 04 Nov 2011 08:21:14 +0100 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <20111103143140.GA591@reifripenet.local> References: <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> <4EB24114.6060907@uijterwaal.nl> <20111103143140.GA591@reifripenet.local> Message-ID: <4EB3926A.1090801@uijterwaal.nl> Daniel, > good to hear from you again. I never stopped talking ;-) > So I am indeed proposing to distribute the probes and benefits as > equally among the membership as possible. And the cost of 300 EUR for > each member that you quote is for the deployment and two years of > operations, so it comes down to EUR150/member/year for the first > two years. 150 euro/year is of the order of 2-3 engineer hours, somewhat depending on the economy where you are living. > Products from these measurements are useful for detecting anomalies, > monitoring trends and for analysing faults. What product is currently included in the probes that solves an issue that most AS's have _and_ where the data from the probe can be used to solve the problem much faster, where much faster means 2-3 hours less work on an annual basis? Right now, I don't see such application. Is there something in the pipeline that we haven't heard about? The question isn't new in itself, it was raised with different parameters for TTM years ago. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From henk at uijterwaal.nl Fri Nov 4 08:22:38 2011 From: henk at uijterwaal.nl (Henk Uijterwaal) Date: Fri, 04 Nov 2011 08:22:38 +0100 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <5.1.0.14.2.20111103183837.03623cd0@efes.iucc.ac.il> References: <4EB24114.6060907@uijterwaal.nl> <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> <4EB24114.6060907@uijterwaal.nl> <5.1.0.14.2.20111103183837.03623cd0@efes.iucc.ac.il> Message-ID: <4EB392BE.20500@uijterwaal.nl> On 03/11/2011 17:47, Hank Nussbacher wrote: > Well, there is a simple way to determine whether the > membership wants to spend a few million Euro on this - ask them via a poll. I'd make it a line-item in the annual budget, together with a few others, not a poll. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From daniel.karrenberg at ripe.net Tue Nov 8 11:16:27 2011 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 8 Nov 2011 11:16:27 +0100 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <4EB3926A.1090801@uijterwaal.nl> References: <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> <4EB24114.6060907@uijterwaal.nl> <20111103143140.GA591@reifripenet.local> <4EB3926A.1090801@uijterwaal.nl> Message-ID: <20111108101627.GL9940@reif.karrenberg.net> [cronss-posting to MAT WG as it is pertinent there as well] On 04.11 08:21, Henk Uijterwaal wrote: > ... > > 150 euro/year is of the order of 2-3 engineer hours, somewhat depending > on the economy where you are living. > > > Products from these measurements are useful for detecting anomalies, > > monitoring trends and for analysing faults. > > What product is currently included in the probes that solves an issue > that most AS's have _and_ where the data from the probe can be used to > solve the problem much faster, where much faster means 2-3 hours less > work on an annual basis? Right now, I don't see such application. Is > there something in the pipeline that we haven't heard about? Thank you Henk for putting the cost in terms of something as tangible as this. This message is long because of the number of scenarios. If youa are pressed for time, jump to "Summary". Here are a few scenarios that come to mind: - Monitor Traffic Engineering Results How does my traffic engineering affect actual latencies and losses? Does TE even do what I expect? Today traffic engineering is mostly monitored by comparing inbound flows from different peers before and after some actions. It can be difficult to even tell what path traffic takes or will take from a specific source. With RIPE Atlas widely deployed and user defined measurements (UDM) in place you can check inbound trajectories by running traceroutes and inbound latencies by running pings and application measurements from distant areas of interest towards your network. This gives you insights that are very hard to obtain otherwise in a comprehensive manner. Also the measurements will be useful when debugging with your peers and upstreams because they come from the RIPE NCC, a well respected source and everyone will be familiar with them. I can easily see how you can save 2-3 engineer hours per year right here by eliminating guessing time and speeding up analysis. - Is it slow for just me ? We all know this scenario: An important customer complains that he cannot get to his favourite content in Distanistan. Or a content customer complains that for "weeks" their hits from Distanistan have decreased. Of course you can check it out right now from the perspective of your network. But how about the pespective from Distanistan or a comparison with others in your region? With RIPE Atlas widely deployed you could set up a measurement from many different places around your region to Distanistan for a week or so and compare. It is even likely that there is a probe in close vicinity of Distanistan which can measure towards your network. If others have had problems with Distanistan too, it is likely that they have set up measurements already. All measurements are available in the RIPE Atlas pool of measurements. You can access those measurements right when the customer complains. At a minimum this may give you the opportunity to explain to the customer that everyone, not just you, has a problem and to prove it with measurements from an independent source, the RIPE NCC. The measurements will also allow you to concisely point out the problem to your peers and up-streams. I can easily see how this will both save hours of engineering time, make the results of trouble shooting better and help you be more credible with customers. - Situational Awareness Today, the routing plane is very well instrumented and we regularly see "events" discussed on operational lists. Very often the effects of these events on the transport plane are subject of speculation, guessing and the occasional isolated measurement. A widely deployed RIPE Atlas will improve our situational awareness by giving us near real time insight into the changes in latencies, packet trajectories and packet losses which are caused by events on the routing plane. The pool of RIPE Atlas measurements will be a treasure trove from which we can isolate signals both on the geographical and topological level. We can correlate them with events in the routing plane and gain a much better insight into the state of the Internet as a whole. A widely deployed RIPE Atlas will become a common frame of reference for dealing with regional and global events that involve many ASes. Having such a global frame of reference will in itself save many engineering hours by enabling quick, concise and unambiguous communication about events on the transport plane between routing engineers. - Long Term Comparative Analysis How are we doing compared to others in our market, region, the world? This is a common question. A widely deployed RIPE Atlas will help you answer those questions from an outside view in terms of stability, packet loss and latency. The measurements will be comparable and they come from a trusted external source. Building an infrastructure to do this ourselves is beyond the resources of most or even all of us. Doing it together makes this possible. For the equivalent of just 2-3 engineering hours per year we can make it happen. - Summary Referring to a common, well known measurement platform for the transport plane will save many engineer hours just by speeding up communication and preventing misunderstandings. RIPE Atlas will improve communications with your peers, up-streams and sophisticated customers by introducing hard transport plane data and a common frame of reference. RIPE Atlas will bring to the transport plane what we already have for the routing plane with route views and RIS. This alone will save more than 3 engineering hours per year for everyone. Add the unprecedented situational awareness of actual latencies, packet losses and packet trajectories and the credibility of the RPE NCC as a source of data, then one RIPE Atlas probe for every RIPE NCC member becomes a baragin. I realise thatwe have not realised most of the products I talk about. However we do have the architecture in place and almost 900 probes out there now. We also have some first examples of useful products: http://atlas.ripe.net/atlas/rtt_maps.html?msm_id=1001 http://atlas.ripe.net/atlas/comparative_root_rtt.html https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-in-the-making AS a probe host you can also look at measurement results from a large number of public probes at http://atlas.ripe.net/atlas/myprobes.html after registering. In the coming 6 months we will deploy user defined measurements and the measurement pool. We will also show more "map" products for situational awareness. We will convince you that speeding up RIPE Atlas deployment by providing at least one probe for every member is worth it. I am sure we can even convince the executive board that we should start this already in 2012 and not wait for the 2013 budget cycle. Watch this space. Daniel From nigel at titley.com Tue Nov 8 11:32:55 2011 From: nigel at titley.com (Nigel Titley) Date: Tue, 08 Nov 2011 10:32:55 +0000 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <20111108101627.GL9940@reif.karrenberg.net> References: <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> <4EB24114.6060907@uijterwaal.nl> <20111103143140.GA591@reifripenet.local> <4EB3926A.1090801@uijterwaal.nl> <20111108101627.GL9940@reif.karrenberg.net> Message-ID: <4EB90557.8060606@titley.com> On 08/11/2011 10:16, Daniel Karrenberg wrote: > In the coming 6 months we will deploy user defined measurements and > the measurement pool. We will also show more "map" products for > situational awareness. We will convince you that speeding up RIPE > Atlas deployment by providing at least one probe for every member is > worth it. I am sure we can even convince the executive board that we > should start this already in 2012 and not wait for the 2013 budget > cycle. Watch this space. Daniel The board is unlikely to be convinced until we see something concretely useful. Whilst I agree that the presence of a huge array of widely distributed probes gives us enormous potential, we still have to see concrete proposals of how they may easily be used for remote monitoring and debugging. What we have seen so far, is a tremendous start, but only a start. However, Daniel and his team being the professionals they are, I have no doubt that we will see this in the coming months and I look forward to it with great anticipation. Wearing my day-job hat for a moment, this would be extremely useful for us and we would be prepared to spend considerably more that 2 - 3 engineer hours (on top of our normal registry fees) for this functionality. All the best Nigel From fweimer at bfk.de Tue Nov 8 13:01:17 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 08 Nov 2011 12:01:17 +0000 Subject: [ncc-services-wg] New on RIPE Labs: A RIPE Atlas Probe for every RIPE NCC Member In-Reply-To: <20111108101627.GL9940@reif.karrenberg.net> (Daniel Karrenberg's message of "Tue, 8 Nov 2011 11:16:27 +0100") References: <4EB104A9.9090903@ripe.net> <4EB104A9.9090903@ripe.net> <5.1.0.14.2.20111102163134.00c5cc08@efes.iucc.ac.il> <4EB24114.6060907@uijterwaal.nl> <20111103143140.GA591@reifripenet.local> <4EB3926A.1090801@uijterwaal.nl> <20111108101627.GL9940@reif.karrenberg.net> Message-ID: <82ehxi3jsi.fsf@mid.bfk.de> * Daniel Karrenberg: > Also the measurements will be useful when debugging with your peers > and upstreams because they come from the RIPE NCC, a well respected > source and everyone will be familiar with them. I can easily see how > you can save 2-3 engineer hours per year right here by eliminating > guessing time and speeding up analysis. On the other hand, you could be forced to deal with additional complaints from people who use these tools and misinterpret the results, similar to what happens with traceroute and WHOIS today, but with the appeal to authority that RIPE NCC has detected a network problem. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mir at ripe.net Wed Nov 9 15:51:41 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 09 Nov 2011 15:51:41 +0100 Subject: [ncc-services-wg] New article on RIPE Labs: Password Management in RIPE Database In-Reply-To: <4EBA9341.8000306@ripe.net> References: <4EBA9341.8000306@ripe.net> Message-ID: <4EBA937D.7020004@ripe.net> [Apologies for duplicate emails] Dear colleagues, Please see a new article on RIPE Labs describing some issues with the use of password hashes and what you can do to secure your objects until this has been addressed: https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database Kind regards, Mirjam Kuehne RIPE NCC From denis at ripe.net Fri Nov 11 15:24:47 2011 From: denis at ripe.net (Denis Walker) Date: Fri, 11 Nov 2011 15:24:47 +0100 Subject: [ncc-services-wg] Securing MD5 Hashes in the RIPE Database Message-ID: <4EBD302F.80304@ripe.net> [Apologies for duplicate emails] Dear colleagues, The RIPE NCC has formed a technical solution for the issue of publicly displaying MD5 password hashes in the RIPE Database. The solution includes: * Filtering out of all "auth:" attributes from all query results of MNTNER objects * Displaying MNTNER objects with "auth:" attributes only in Webupdates after password authentication We published an article on RIPE Labs describing the details, including a mockup of the password authentication required by Webupdates: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database Additionally, we added a basic strength indicator to the password generator: https://apps.db.ripe.net/crypt/crypt.html We look forward to your comments and feedback, either on the Database Working Group mailing list or below the article itself. Kind regards, Denis Walker Business Analyst RIPE NCC Database Group From green at msu.ru Fri Nov 11 16:30:28 2011 From: green at msu.ru (Alexander Zubkov) Date: Fri, 11 Nov 2011 19:30:28 +0400 Subject: [ncc-services-wg] Securing MD5 Hashes in the RIPE Database In-Reply-To: <4EBD302F.80304@ripe.net> References: <4EBD302F.80304@ripe.net> Message-ID: <4EBD3F94.7030509@msu.ru> On 11/11/2011 06:24 PM, Denis Walker wrote: > [Apologies for duplicate emails] > > Dear colleagues, > > The RIPE NCC has formed a technical solution for the issue of > publicly displaying MD5 password hashes in the RIPE Database. The > solution includes: > > * Filtering out of all "auth:" attributes from all query results of > MNTNER objects Why filter all auth attributes? What if someone will want to use public key to send encrypted mail? :) Also what about implementing stronger schemes for plain passwords like SHA-256,512? > * Displaying MNTNER objects with "auth:" attributes only in > Webupdates after password authentication > > We published an article on RIPE Labs describing the details, including a > mockup of the password authentication required by Webupdates: > https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database > > Additionally, we added a basic strength indicator to the password > generator: > https://apps.db.ripe.net/crypt/crypt.html > > We look forward to your comments and feedback, either on the Database > Working Group mailing list or below the article itself. > > Kind regards, > > Denis Walker > Business Analyst > RIPE NCC Database Group > > From kranjbar at ripe.net Tue Nov 15 05:35:40 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Tue, 15 Nov 2011 05:35:40 +0100 Subject: [ncc-services-wg] Securing MD5 Hashes in the RIPE Database In-Reply-To: <4EBD3F94.7030509@msu.ru> References: <4EBD302F.80304@ripe.net> <4EBD3F94.7030509@msu.ru> Message-ID: [Sorry for the long reply] Hello Alexander, Thank you for your feedback. If you agree, I would suggest we continue rest of this discussion in the db-wg mailing list (CCed). On Nov 11, 2011, at 4:30 PM, Alexander Zubkov wrote: > > Why filter all auth attributes? What if someone will want to use public key to send encrypted mail? :) > You are right, we could filter out only the lines with MD5 hashes. The reasons we have proposed to filter all "auth:" attributes are: a) It is simpler and more straight forward. Think about the new users who will start using RIPE Database after these changes are made, system filtering all "auth:" attributes looks like rational behavior but filtering only some type of "auth:" attributes needs some explanation of the history. In two years, a lot of us will forget why that was implemented and then it will be just another behaviour of the system that we all have to live with :) b) The PGP Key referenced in the "auth:" attribute is not intended to be used as a pointer to a public-key for email encryption and actually it shouldn't be used for that purpose. Users might not have access to the private-key for decrypting emails (for example in automated setups) and -even if thy have the access- the value is not there to advertise the public-key. Also note that a MNTNER object is a container. It often contains credentials for several different people. The holder of the MNTNER object itself may be different from each of the people with credentials contained within it. If you encrypt an email based on a PGP credential contained within a MNTNER object, who would you send that email to? It is quite likely none of the email addresses in the MNTNER object relate directly to the person holding that PGP credential. The whole authentication model of the RIPE Database is complex with many levels of indirection. For these reasons, if anyone wants a key to be used for encryption users can be directly referred to the public-key in the database or there can be references to the public-key in the remarks lines of different objects, including role objects. But that's just our opinion and point of view, hiding only the MD5 "auth:" attributes will serve the purpose just as well. > Also what about implementing stronger schemes for plain passwords like SHA-256,512? I can see two different scenarios here: 1- We use different hash function and keep the keys published, In this case: a) This still leaves the door open for dictionary attacks. A strong hash does not help with a weak password. b) Processing power is constantly improving. We started with CRYPT-PW until it was considered to be week and was replaced with MD5. Now SHA 256/512 is a strong hashing function, but this might not be the case in 5 years. c) Experience has shown it takes years for users to change data. When we switched from CRYPT-PW to MD5 we allowed about a year for users to upgrade. At the end of that period we still had to lock many MNTNER objects that still only had CRYPT-PW. d) We didn't find any business case for keeping the hashes public. 2- Another scenario could be the case that we use different hash function and still go ahead and hide the hashes, hence in practice we use different hashing system for internal storage of password hashes a) It is definitely good idea and the way to go, after hiding the hashes we should think about making the internal storage more secure. b) In long term we may suggest moving the authentication to a system specifically designed for this purpose, for example RIPE Access. That system might even use HSMs to keep hashes safe but it will be that system's responsibility. Again, this is just clarifying our line of thinking for making that technical proposal, we might have missed something or our assumptions might be wrong, that's why we need community's feedback on the issue. And to emphasize Peter Koch's comments at RIPE 63's Database Session, there is a need to take a look at the bigger picture as well. This proposal only addresses publication of MD5 hashes. The issue of clear text password transport over email is still open and there might be other issues as well and that's why a security analysis of the whole process is useful and needed. Thank you again for contributing to the subject. Kind Regards, Kaveh. --- Kaveh Ranjbar, Database Group Manager, RIPE NCC From training at ripe.net Mon Nov 21 14:54:00 2011 From: training at ripe.net (Training Mailbox) Date: Mon, 21 Nov 2011 14:54:00 +0100 Subject: [ncc-services-wg] Announcement: RIPE NCC Training Courses Message-ID: <4ECA57F8.7070902@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/lir-services/training/courses/lir/outline/ - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/lir-services/training/courses/rr/ - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List& Registration https://lirportal.ripe.net/training/courses If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Spratley-Kanis Training Services Manager RIPE NCC From alexb at ripe.net Wed Nov 23 10:47:11 2011 From: alexb at ripe.net (Alex Band) Date: Wed, 23 Nov 2011 10:47:11 +0100 Subject: [ncc-services-wg] LIR Portal migration to RIPE NCC Access on 29 November 2011 Message-ID: <6F2E260A-A719-473B-82CF-3771A2C49E00@ripe.net> Dear colleagues, We are in the process of rolling out RIPE NCC Access. This will enable you to access various RIPE NCC services using just one password instead of having to sign in to each tool or service separately. RIPE NCC Access is already enabled for IS Alarms and RIPE Labs, and the next service scheduled for migration is the LIR Portal. The migration will be performed on Tuesday, 29 November 2011 starting at 16:00 UTC when the maintenance window opens. Before the migration takes place, we need to temporarily disable the option for LIR Portal administrators to create new users starting on Monday, 28 November 2011 at 16:00 UTC. During this period, you will still be able to access and use the LIR Portal using your current credentials. After the migration is complete, you will no longer be able to log in to the LIR Portal using your old credentials. All LIRs will receive an email on 29 November with further instructions. If you have any questions or comments about this, please contact . Kind regards, Alex Band Product Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From rramphul at ripe.net Wed Nov 30 09:59:56 2011 From: rramphul at ripe.net (Radha Ramphul) Date: Wed, 30 Nov 2011 09:59:56 +0100 Subject: [ncc-services-wg] Policy Proposal 2010-01 "Temporary Internet Number Assignment Policies" implemented Message-ID: <4ED5F08C.3040503@ripe.net> [Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that RIPE Policy Proposal 2010-01,"Temporary Internet Number Assignment Policies", has been implemented. The RIPE NCC is now ready to accept requests for Temporary Internet Number Assignments under this policy. The full proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2010-01 The new policy "Temporary Internet Number Assignment Policies" is available at: https://www.ripe.net/ripe/docs/ripe-526 The following documents now appear online as part of this policy implementation. 1. A new contract template has been formulated which can be used as the agreement between LIRs and End-users. It can be downloaded at: http://ripe.net/lir-services/resource-management/temp-assign-agreement 2. A new request template (currently in text format only) is now available. The LIR portal version will be coming soon. http://www.ripe.net/ripe/docs/ripe-536 3. Supporting notes explaining the various sections of the form and how to complete them have been added as well. http://www.ripe.net/ripe/docs/ripe-535 4. A new FAQ page can be accessed at: https://www.ripe.net/lir-services/resource-management/number-resources/temporary-internet-number-assignment/faq The following resources have been reserved for this purpose: IPv4: 151.216.0.0/13 16-bit ASN: AS58352-AS58367 No reservations have been made for IPv6 and 32-bit ASN. Regards Radha Ramphul RIPE NCC Registration Services