- db-wg - mailman.ripe.net

help
by Caraliu.Samuel 16 Feb '12

16 Feb '12

2012/2/15 <db-wg-request(a)ripe.net> > Send db-wg mailing list submissions to > db-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request(a)ripe.net > > You can reach the person managing the list at > db-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Suggestion for a way to retrieve filtered objects > (Anders Mundt Due) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Feb 2012 18:10:33 +0100 > From: "Anders Mundt Due" <anders.mundt.due(a)uni-c.dk> > Subject: [db-wg] Suggestion for a way to retrieve filtered objects > To: "Database WG" <db-wg(a)ripe.net> > Message-ID: > <80D52320F10F9143AF3670B571348EEA01F497BB(a)LGBEXCHANGE01.unic.local> > Content-Type: text/plain; charset="UTF-8" > > Hi there, > > We just had a problem with the RFC3068-MNT object, from what I can see, if > you have an object with at least one > auth: MD5 ... > > Only people that have one of the passwords can see the object in the > webupdater and get the full object to manipulate the object. > > So now, instead of having a chance to get rid of shared > passwords/passphrases, everybody needs to have one, because of the way > objects are filtered. > > Only idea I've had so far, would be that there should be a way to request > an object in a way where I can authenticate with my PGPKEY, for instance > using email and not a webbrowser, so I'd sign a mail requesting an object, > with a key that would be listed as authentication in the object I request, > and that would return the unfiltered object to me. > > Of course, the other solution is to just get hold of all the people with > an auth: MD5 line and make them take it out, that way you can get the full > object without authenticating on the webupdater. > > I'm not sure if my thought here is useable, good or practical. But it > someone can come up with a brilliant way to make shared objects of this > kind smoothly, I suspect the people implementing the database will be eager > to hear about it, and at the very least the people behind RFC3068-MNT will > be gratefull. > > /Anders > Forskningsnettet dk.denet > > End of db-wg Digest, Vol 6, Issue 2 > *********************************** >

1 0

cmd line asused and webasused
by Nina Hjorth Bargisen 18 Jan '12

18 Jan '12

Hi all Last year I learned - by asking around - that the asused tool commandline script was no longer supported by RIPE - that was after not being able to find it on the usual ftp site. We have since managed to get by with an old copy but now it seems that this is no longer able to get output from the RIPE db and hence all our adress usage and other homemade scripts are now broken. I assume that this step has been taken after some discussion that I myself have been too lazy to follow in this working group, but as I cant manage to find any reference of it in a brief search in the archives and my mailbox that holds mails from a few years, I hope someone in the group can enlighten me about why this step was taken. I have tried to use the webtool, but as it spams *every* person in the LIR contact list with several mails and all the output is jammed together in one long list, I am not really too happy about rewriting all my scripts to some how use the webtool to give me the nessercary output. So - Is there *ANY* chance of somehow get support of a similar tool to the old asused used, that one can install and run from our own box and with the support of the same options as before or does all tools now focus on small LIRs with very and hence very easily manually managed addressspace? /Nina TDC dk.teledanmark

7 11

Re: [db-wg] cmd line asused and webasused
by Alex Band 18 Jan '12

18 Jan '12

Hi Nigel, I can assure you that the action the board gave, what Axel understood and what we are developing is perfectly aligned. "Merely provisioning an API into the webasused tool" is not what I said and definitely not what we're creating. Our goal is to cater to all needs that the membership has with regards to address space information and management. Some just want a simple web based interface that they can check without needing to download and run a local tool. Some have a need to integrate address space information into their local (IPAM) toolsets and workflows. But what all users have in common is the desire to have a more comprehensive information set than is currently available, such as an overview of the invalid assignments, as Nina pointed out. This is why we're taking an approach of using Registry data instead of the RIPE Database. To summarise, again, we will provide functionality for both web-based and stand-alone use. In the mean time, we will do everything we can to make sure the current asused functionality is not disrupted. Kind regards, Alex On 17 Jan 2012, at 17:53, Nigel Titley wrote: > Nick, Alex et al > > At the Board meeting on the 8th December the board gave Axel an action "to reinstate/redevelop the stand-alone version of the RIPE NCC ASused tool" > > I doubt that this action would be satisfied merely by the provision of an API into the webasused tool. > > Alex, you may like to check this with Axel. It is possible that it was misunderstood by him, but it is very clearly minuted. > > And I'd agree with Nick that lack of platform portability is one of the few brickbats that cannot be aimed at perl. > > Nigel > > -----Original Message----- > From: db-wg-bounces(a)ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of Nick Hilliard > Sent: 17 January 2012 16:22 > To: Alex Band > Cc: db-wg(a)ripe.net > Subject: Re: [db-wg] cmd line asused and webasused > > Hi Alex, > > On 17/01/2012 14:25, Alex Band wrote: >> Thanks for bringing up asused. It is a tool that was written and >> maintained by the RIPE NCC many years ago and later handed to the open >> source community, where it can be found in packages such as Debian: >> http://packages.qa.debian.org/a/asused.html >> >> This, along with the fact that is was written in a very platform >> specific manner, is the reason why the tool is no longer actively >> developed and supported by the RIPE NCC. On the other hand, we have >> always kept the existence of asused in mind, which means that we would >> never intentionally change anything to our (whois) configuration that >> would break asused. I want to assure you that we'll try to fix any >> issue that you may have on a best effort basis. > > Problem is, we don't yet have a replacement command-line tool for dealing with quick-n-easy LIR resource usage summarisation. This has meant that the people who depended on this tool were left hanging for the last 8 years, because the code slowly rotted as interfaces subtly changed over time. This is not a criticism of changing the DB interface or anything, btw - progress needs to happen. > > In terms of being platform specific, it was limited to any platform which could run perl - perhaps with minor modifications. There are lots of complaints that people make about perl, (some legitimate) but platform portability is not one of them. > > OTOH, webasused can be very slow. E.g. I submitted a request for a LIR at > 15:28 GMT today, and got a reply at 15:39. This makes it unusable for a typical workflow process (e.g. run asused, check output against internal records, submit a couple of updates, run asused again, check again, repeat until satisfied). > > The web version is also unauthenticated which means that it's open to third parties submitting requests for arbitrary LIRs. And it doesn't support ipv6, which means that it's still difficult to do resource reconciliation for v6 assignments. > > I'll admit that not everyone likes command line tools, but for those of us who continue to us asused, it's a real pity that it wasn't maintained and further developed to support ipv6. > > Nick > >

2 1

MD5 Password Security Update Deployed
by Denis Walker 12 Jan '12

12 Jan '12

Dear colleagues, [Apologies for duplicate emails.] The RIPE NCC is pleased to announce that the implementation of the MD5 password security change has now been fully deployed. This was discussed recently on the RIPE Database Working Group mailing list. The RIPE NCC was asked to implement the technical change as outlined in this RIPE Labs article: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database This deployment has an impact only when you modify a MNTNER object that contains an MD5 password. This can only be done using Webupdates. You must be one of the password holders to make changes. Operations on all other object types are unchanged. The RIPE NCC will now: - Send emails to contact addresses in all MNTNER objects containing MD5 passwords recommending a password change and suggesting that a strong password be used - Perform a small MNTNER clean-up by preparing a list of unreferenced MNTNER objects and deleting those that are still unreferenced one month later. If you have not followed this discussion, we recommend that you read the RIPE Labs article to ensure that you understand the new process for maintaining MNTNER objects in the RIPE Database. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Security of MD5 hashes in the RIPE Database
by Denis Walker 10 Jan '12

10 Jan '12

Dear Colleagues, The RIPE NCC Database Group is pleased to announce that the implementation of the MD5 password security change is now ready for deployment. This was discussed recently on the DB WG mailing list. The Database Group was asked to implement the technical change as outlined in this RIPE Labs article: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database The Database Group will now: - Fully deploy these changes on Thursday 12 January 2012 - Send emails to contact addresses in all MNTNER objects containing MD5 passwords recommending a password change and suggesting that a strong password be used - Perform a small MNTNER clean-up by preparing a list of unreferenced MNTNER objects and deleting those that are still unreferenced one month later. If you have not followed this discussion, we recommend that you read the RIPE Labs article to ensure that you understand the new process for maintaining MNTNER objects in the RIPE Database. A new version of Webupdates has already been deployed that asks for a password before allowing a MNTNER object with a password to be updated. But querying MNTNER objects from the RIPE Database will not change until Thursday. The full new software has been deployed on the TEST Database. So it is no longer possible to query a full MNTNER object that contains a password authentication token from the TEST Database, except by entering the password in Webupdates. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

DB email robot response and Precedence header
by Daniel Roesen 04 Jan '12

04 Jan '12

Hi, robot responses (like SUCCESS) do get sent with header From ripe-dbm(a)ripe.net, and no "Precedence: bulk" headers. So any response to those (e.g. out-of-office) will open a ticket with the ripe-dbm@ folks needlessly. For example, see NCC#2011125073. Would it make sense, to - use From: unread(a)ripe.net (like with the notification mails) and/or - add the "Precedence: bulk" header to avoid autoresponders kicking in? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

2 1

Re: [db-wg] MD5 and Password Security in the RIPE DB, Fwd: Wonder if you can help - re: PDP
by David Kessens 14 Dec '11

14 Dec '11

Emilio, Wilfried, Nigel, Emilio wrote: > My apologies for sending the previous email to the full working group. > It was intended for the Database Working Group Chairs. But now that you accidentaly mailed us, I would like to take the opportunity to mention that I believe that we don't need the PDP process invoked for these kind of changes. I hope that we as a community have not petrified that far that we cannot request the RIPE NCC to make a change to the RIPE database and be done with it. To say it in a different way, the issue at hand is much closer (but not quite the same) to a bug fix/operational issue than a public policy change. David Kessens PS And regarding the topic of shadow passwords in the RIPE database, you might be interested in the following presentation by me from 1995, page 11: ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz --- On Mon, Dec 12, 2011 at 10:55:23AM +0100, Emilio Madaio wrote: > Hi Nigel and Wilfried, > > as promised last week to Nigel, I'd like to make a short recap and > have your attention on the following. > > I have been contacted by David Freedman in regards of a couple of > policy proposals he sent you for review and possible submission to the > PDP. Below you can find, for more details, my summaries of the proposals > and what analysis we did in the NCC. > > As you will see, both cases can be tackled by the NCC with ideas that > can be discussed by the DB WG and, if approved, easily implemented. > Among the possible decisions you can take, there are also: > > -starting discussion in the mailing list now; or > -present and discuss at RIPE 64. > > Obviously we can consider, as David asked, to start the PDP if you deem > it necessary. > > In any case, David did not have a chance to hear from you, so I kindly > ask you to let him know, either your decision or that you acknowledged > his intentions. > > And please do not hesitate to let me know how I can help. > > > I included the email he sent so far and the aforementioned proposal texts. > > > Best Regards > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -----oooooooo-------- > SUMMARIES: > > 1) The first proposal's scope regards the display of the MD5 password > hashes in the "auth:" attribute. Since then the DB department published > an article recommending the technical solutions of, in short: > > -filtering out "auth:" attributes from all query results on MNTNER objects > -adjusting Webupdates to require maintainer password authorisation over > HTTPS before presenting the object to the user for updating. > > This solution can be easy and quick to implement. They only need some > discussion in the DB WG. > > 2) The second proposal's scope regards the restriction to secure > channels for all the possible mntner authentications. In this instance > as well, the NCC can provide some quick technical alternatives for the > DB WG to discuss. > > > > > > > > > > > -------- Original Message -------- > [..] > > > Date: Tue, 15 Nov 2011 09:44:31 +0000 > From: David Freedman <david.freedman(a)eu.clara.net> > To: db-wg-chairs(a)ripe.net > Subject: My proposals > > Hi there, > > On 08/11 I sent you two policy proposals for review, concerning the > publication and use of MD5 authentication > attributes in the database. > > Since then, Denis Walker has published an article on RIPE labs describing a > potential solution to one of these issues > > https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database > > Could you please tell me what happens next in the scope of both my proposals > and security community support for Denis' idea? > > Regards, > > David Freedman > > > Date: Tue, 8 Nov 2011 16:10:35 +0000 > From: David Freedman <david.freedman(a)eu.clara.net> > To: db-wg-chairs(a)ripe.net > Subject: Re: Policy Proposal "Removal of auth: MD5-PW from WHOIS > information" > > s/scheme/schemes, apologies > > On 08/11/2011 16:03, "David Freedman" <david.freedman(a)eu.clara.net> wrote: > > >Please see below: > > > >--------------------------- > > > >Number: > >(assigned by the RIPE NCC) > > > >Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information > > > >Author: > > a. David Freedman > > > >b. david.freedman(a)uk.clara.net > > > >c. Claranet > > > >Proposal Version: > >(assigned by the RIPE NCC) > > > >Submission Date: 8/11/2011 > > > >Suggested RIPE WG for discussion and publication: Database Working Group > > > >Proposal Type: > >a. new > > > >Policy Term: > >b. Indefinite > > > >Summary of proposal: > >Policy text: > >b. New policy text > > > >This is a proposal to remove the display the "auth:" attribute for auth > >type "MD5-PW" in WHOIS information, in order to increase the security of a > >number of user's mntner objects. > > > >Rationale: > >a. Arguments supporting the proposal > > > >Numerous sources have demonstrated the vulnerability of the MD5-PW to > >compromise when presented with modern compute power, a number of alternate > >"auth" scheme exist which provide far more > >security to the mntner. By allowing these attributes to be exposed in > >WHOIS information, malicious entities could direct their efforts to > >computing a plaintext input of the hash and thus > >compromise mntner objects (and hence protected resources) of their choice. > > > >b. Arguments opposing the proposal > > > >The database group state: "Since any change in the current process means > >significantly changing the behaviour of the RIPE Database* and will break > >existing use cases of the system, it is not something the RIPE NCC can > >make a decision on.", this could involve significant work for the Database > >Group. > > > >*- As an example, current Update process requires the full object > >-including the hashes for maintainer objects- to be used in the update > >message. > > > >--------------------------- > > > > > Date: Tue, 8 Nov 2011 16:10:14 +0000 > From: David Freedman <david.freedman(a)eu.clara.net> > To: db-wg-chairs(a)ripe.net > Subject: New proposal : Prevention of use of MD5-PW over insecure channels > > See below > > ----------- > > Number: > (assigned by the RIPE NCC) > > Policy Proposal Name: Prevention of use of MD5-PW over insecure channels > > Author: > a. David Freedman > > b. david.freedman(a)uk.clara.net > > c. Claranet > > Proposal Version: > (assigned by the RIPE NCC) > > Submission Date: 8/11/2011 > > Suggested RIPE WG for discussion and publication: Database Working Group > > Proposal Type: > a. new > > Policy Term: > b. Indefinite > > Summary of proposal: > Policy text: > b. New policy text > > This is a proposal to ensure that all mntner authentication which makes > use of MD5-PW for an object transaction, do so over a secure channel, in > order to increase the security of such transactions. > > Rationale: > a. Arguments supporting the proposal > > Numerous sources have demonstrated the vulnerability of the MD5-PW to > compromise when presented with modern compute power, a number of alternate > "auth" schemes exist which provide far more > security to the mntner. By allowing the plaintext password to be passed > over insecure channels, information could be intercepted and the plaintext > password obtained, potentially compromising > mntner objects (and hence protected resources). > > b. Arguments opposing the proposal > > A number of object maintainers may currently make use of such insecure > channels (for example, unencrypted SMTP), these functions may be related > to legacy systems which are costly to update. > > > ----------- > > > Date: Tue, 8 Nov 2011 16:03:30 +0000 > From: David Freedman <david.freedman(a)eu.clara.net> > To: db-wg-chairs(a)ripe.net > Subject: Policy Proposal "Removal of auth: MD5-PW from WHOIS information" > > Please see below: > > --------------------------- > > Number: > (assigned by the RIPE NCC) > > Policy Proposal Name: Removal of auth: MD5-PW from WHOIS information > > Author: > a. David Freedman > > b. david.freedman(a)uk.clara.net > > c. Claranet > > Proposal Version: > (assigned by the RIPE NCC) > > Submission Date: 8/11/2011 > > Suggested RIPE WG for discussion and publication: Database Working Group > > Proposal Type: > a. new > > Policy Term: > b. Indefinite > > Summary of proposal: > Policy text: > b. New policy text > > This is a proposal to remove the display the "auth:" attribute for auth > type "MD5-PW" in WHOIS information, in order to increase the security of a > number of user's mntner objects. > > Rationale: > a. Arguments supporting the proposal > > Numerous sources have demonstrated the vulnerability of the MD5-PW to > compromise when presented with modern compute power, a number of alternate > "auth" scheme exist which provide far more > security to the mntner. By allowing these attributes to be exposed in > WHOIS information, malicious entities could direct their efforts to > computing a plaintext input of the hash and thus > compromise mntner objects (and hence protected resources) of their choice. > > b. Arguments opposing the proposal > > The database group state: "Since any change in the current process means > significantly changing the behaviour of the RIPE Database* and will break > existing use cases of the system, it is not something the RIPE NCC can > make a decision on.", this could involve significant work for the Database > Group. > > *- As an example, current Update process requires the full object > -including the hashes for maintainer objects- to be used in the update > message. > > --------------------------- > > David Kessens ---

6 7

Re: [db-wg] MD5 and Password Security in the RIPE DB, Fwd: Wonder if you can help - re: PDP
by Emilio Madaio 12 Dec '11

12 Dec '11

Dear Colleagues, My apologies for sending the previous email to the full working group. It was intended for the Database Working Group Chairs. Best Regards Emilio Madaio Policy Development Officer On 12/12/11 10:55 AM, Emilio Madaio wrote: >

1 0

2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
by Denis Walker 30 Nov '11

30 Nov '11

Dear Colleagues The RIPE NCC Database Group has now published an article on RIPE Labs with a detailed explanation of how we propose to implement abuse handling with an "abuse-c:" attribute referencing a ROLE object. https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database This issue is currently being discussed on the Anti Abuse Working Group mailing list. Please direct any comments to that list. Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

Geolocation data prototype in the RIPE Database
by Denis Walker 07 Oct '11

07 Oct '11

Dear colleagues, At the RIPE 62 Meeting in Amsterdam the RIPE NCC Database Group was asked to investigate handling geolocation data in the RIPE Database. We now have a proof of concept prototype for discussion by the community. Based on input from a number of community sources and the subsequent presentation at RIPE 62, this prototype has two new optional attributes for storing geolocation data and language details. We have written an article about the design approach on RIPE Labs https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database This prototype references a sand-boxed TEST Database and does not have any pre-loaded geolocation or language data. But you can create your own data to see how easy it is to manage this new, optional information. We also have a prototype Geolocation Finder tool to search for this data. Another article on RIPE Labs shows how to create the new optional attributes and use the Geolocation Finder tool to search for this data. No changes in this sand-boxed TEST Database will affect the production RIPE or TEST Database services. The article is available at: https://labs.ripe.net/Members/denis/example-usage-of-ripe-database-geolocat… We invite comments or feedback on this design and suggestions for how to move forward if it is seen as a useful addition to the RIPE Database by the community. Regards Denis Walker Business Analyst RIPE NCC Database Group

7 10