- db-wg - mailman.ripe.net

Deprecation of DBConstat service
by Denis Walker 06 Jul '12

06 Jul '12

Dear colleagues, The RIPE NCC has carried out a thorough review of DBConstat, a service to check consistency of data in the RIPE Database and produce statistics. It was written over ten years ago and has changed little over that period. The current software is unmaintainable now. The results of this review are published on RIPE Labs: https://labs.ripe.net/Members/denis/review-of-dbconstat The review showed that this service produces a series of almost flat line graphs and provides an interactive service barely used by anyone and resulting in no significant improvement in data quality in the RIPE Database. The RIPE NCC believes this is not the way to address the few outstanding inconsistencies reported by this service. We therefore intend to deprecate this service, then investigate and address the remaining inconsistencies using other methods, as discussed in the article on RIPE Labs. If anyone has any concerns about this service, please reply to the mailing list within the next two weeks. Regards, Denis Walker Business Analyst RIPE NCC Database Group

2 2

Database Updates service recovery
by Kaveh Ranjbar 03 Jul '12

03 Jul '12

Dear Colleagues, The issues with our RIPE Database update services is resolved. All mail sent during the downtime is now processed and sync updates, web updates and API updates are back to normal. If you experience any problems, please contact ripe-dbm(a)ripe.net. The update service was down between 07:58 CET (05:58 UTC) until 9:55 CET (07:55 UTC) due to hardware issues. Further details on this issue will be posted to RIPE Database Working Group mailing list at db-wg(a)ripe.net. Kind Regards, Kaveh Ranjbar RIPE NCC Database Group Manager

2 1

Database Updates service disruptions
by Kaveh Ranjbar 30 Jun '12

30 Jun '12

Dear Colleagues, RIPE Database sync updates, web-updates and API updates are not responding at the moment. We are dealing with hardware problems on the machines used for the database update cluster. The service was affected from from 07:58 CET (05:58 UTC) and we are working to recover it as soon as possible. Queries will keep working and updates via emails are queued and will be processed as soon as the service is up. We will send an update message as soon as the service is up or when we have an estimate on how long it takes to fix the problem. Kind Regards, Kaveh Ranjbar RIPE NCC Database Group Manager

1 0

MD5 Hashes in the RIPE Database
by Denis Walker 23 May '12

23 May '12

Dear colleagues, It was clear from the discussions at RIPE 64 that we need to change the initial implementation of hiding the hashes for MD5 passwords in MNTNER objects. A suggestion was made to keep the "auth:" attributes in place. If the authentication token is an MD5 password we will remove the hash value. All PGP and X.509 values will remain unchanged. We have already worked on this and a sample MNTNER object would look like the object below. We can deploy this change within the next two weeks. Regards, Denis Walker Business Analyst RIPE NCC Database Group $whois -B DEV-ROOT-MNT % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf [Open URL] % Information related to 'DEV-ROOT-MNT' mntner: DEV-ROOT-MNT descr: Mntner for DEV-DBM-MNT admin-c: AA1-DEV tech-c: AA2-DEV upd-to: bitbucket(a)ripe.net mnt-nfy: bitbucket(a)ripe.net auth: MD5-PW # Filtered auth: PGPKEY-1290F9D2 notify: bitbucket(a)ripe.net mnt-by: DEV-ROOT-MNT referral-by: DEV-ROOT-MNT remarks: This is an automatically created object. changed: bitbucket(a)ripe.net 20051031 source: DEV # Filtered role: DEV ROLE nic-hdl: AA2-DEV address: Somewhere in nowhere phone: +12 34 567 8900 fax-no: +12 34 567 8900 e-mail: bitbucket(a)ripe.net abuse-mailbox: bitbucket(a)ripe.net admin-c: AA1-DEV tech-c: AA2-DEV mnt-by: DEV-ROOT-MNT remarks: This is an automatically created object. changed: bitbucket(a)ripe.net 20051031 source: DEV person: Test Person mnt-by: DEV-ROOT-MNT address: Somewhere in nowhere phone: +12 34 5678900 fax-no: +12 34 5678900 e-mail: bitbucket(a)ripe.net nic-hdl: AA1-DEV remarks: This is an automatically created object. changed: bitbucket(a)ripe.net 20051031 source: DEV % This query was served by the RIPE Database Query Service version 1.9-SNAPSHOT (UNDEFINED)

8 8

Fwd: WG Action: Web Extensible Internet Registration Data Service (weirds)
by Kaveh Ranjbar 16 May '12

16 May '12

Hello all, Below you can find the announcement from the IESG on the formation of the IETF Web Extensible Internet Registration Data Service (WEIRDS) Working Group. The aim of the working group is to work on a unified whois request-and-response format based on the web technologies. If you find the subject interesting, please kindly participate in discussions using the pointers in the original announcement. The RIPE NCC will do its best to make sure requirements and current practices of our community are reflected in the discussions but your direct participation is really appreciated. Kind regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager Begin forwarded message: > From: IESG Secretary <iesg-secretary(a)ietf.org> > Subject: [weirds] WG Action: Web Extensible Internet Registration Data Service (weirds) > Date: May 15, 2012 6:58:40 PM GMT+02:00 > To: IETF Announcement List <ietf-announce(a)ietf.org> > Cc: weirds(a)ietf.org > > A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. > > Web Extensible Internet Registration Data Service (weirds) > ---------------------------------------------------------- > Status: Proposed Working Group > Last updated: 2012-04-24 > > Chairs: > Olaf Kolkman <olaf(a)nlnetlabs.nl> > Murray Kucherawy <msk(a)cloudmark.com> > > Applications Area Directors: > Barry Leiba<barryleiba(a)computer.org> > Pete Resnick<presnick(a)qualcomm.com> > > Applications Area Advisor: > Pete Resnick<presnick(a)qualcomm.com> > > Mailing List: > Address: weirds(a)ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/weirds > Archive: http://www.ietf.org/mail-archive/web/weirds/ > > Description of Working Group: > > Internet registries for both number resources and names have > historically maintained a lookup service to permit public access > to some portion of the registry database. Most registries offer > the service via WHOIS (RFC 3912), with additional services being > offered via world wide web pages, bulk downloads, and other > services, such as RPSL (RFC 2622). > > WHOIS has never been internationalized. In the absence of formal > specification, ad hoc solutions to signal internationalized > registration data have been adopted and deployed. Providing a > standards-based solution that scales well could minimize further > proliferation of ad hoc solutions. > > WHOIS also has no data model: replies are basically just free-form > text. This means that processing of WHOIS output amounts to > "screen scraping", with specialized handlers for every service. > While many of the domain name registries share a basic common output > format, the addition of data elements changes the output > and causes problems for parsers of the data. > > The WHOIS protocol does not offer any differential service; it > cannot differentiate among clients to offer different subsets of > information or to allow different access rates to it. > > Various attempts to solve the limitations of WHOIS have met with > mixed success. The most recent of these was IRIS (RFC 3891). > IRIS has not been a successful replacement for WHOIS. The primary > technical reason for this appears to be the complexity of IRIS, the fact > that it builds upon many available technologies that in the aggregate > form a complex system. There may also exist non-technical reasons, > but they lie in areas upon which the IETF does not pass judgement. > > In recent years, ARIN and RIPE NCC have fielded production RESTful > web services to serve WHOIS data, and each has met with success. > It is widely believed that this simpler re-use of Web technologies > familiar to modern web developers has enabled this success. The > purpose of this working group is to broaden the use of RESTful web > services by achieving simple and common URI patterns and responses > amenable to all number resource and domain name registries. > > This Working Group shall determine the general needs of such a > service, and standardize a single data framework. That framework > shall be used to encapsulate objects that could form part of an > answer. The framework shall be for data to be delivered via a > RESTful data service using HTTP (optionally using TLS), and may use > standard features of HTTP to support differential service levels > to different classes of user. The data shall have one mandatory > format, though the working group may consider other optional formats. > The overall effort will be broadly aligned with > a subset of the Cross Registry Internet Service Protocol (CRISP) > Requirements (RFC 3707), but with the explicit additional goals of > producing a simple, easy-to-implement protocol, supporting > internationalized registration data and, specifically for > name registries, capturing the needs of internationalized > domain names in the data model. > > As the number registries have more experience with these services > and have found common ground, with their dissimilarities resulting in > more complete working group input documents, the goals of the working > group are to produce standards-track specifications for both number > and name registries using the fashion and pattern of the number registry > input documents, draft-newton-et-al-weirds-rir-query and > draft-newton-et-al-weirds-rir-json-response, as an initial basis. > > Work to specify the query for domain name registration data will be > based on draft-sheng-weirds-icann-rws-dnrd. > > The Working Group shall determine the general requirements of such a > service, using draft-kucherawy-weirds-requirements as an input document, > and standardize a single data framework. The working group will likely > not seek publication of this draft. > > Should the Working Group reach a point where it determines that the > problem of producing a grand unified specification for both numbers and > names appears to be intractable, it will be permitted to divide the > problem into separate tasks and amend its milestones accordingly. > > Milestones: > > Nov 2012 Draft specifying the common infrastructure document to the > IESG for approval as a Proposed Standard. > > Feb 2013 Draft specifying the RESTful URL query format for RIRs to the > IESG for approval as a Proposed Standard. > > Mar 2013 Draft specifying the format for responses to RIR queries > to the IESG for approval as a Proposed Standard. > > Jul 2013 Draft specifying the RESTful URL query format for domain name > registration data to the IESG for approval as a Proposed > Standard. > > Aug 2013 Draft(s) specifying the format(s) for responses to domain name > registration data queries to the IESG for approval as a > Proposed Standard. > _______________________________________________ > weirds mailing list > weirds(a)ietf.org > https://www.ietf.org/mailman/listinfo/weirds

1 0

Scheduled Maintenance on RIPE Database Update Server - successful
by Denis Walker 10 May '12

10 May '12

[Apologies for duplicate emails] Dear Colleagues, The migration of the RIPE Database update service, and the content of the RIPE and TEST Databases, to a new server has been successful. If you experience any issues with the new update service please contact our Customer Services on ripe-dbm(a)ripe.net. Any update sent to the email interface during the migration should have been completed. We suggest you check the database to confirm the success of those updates in case you did not get an acknowledgement message. We appreciate your cooperation and apologise for any inconvenience this may have caused. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Re: [db-wg] Problems with Albanian Domains
by Nikolin hajj 10 May '12

10 May '12

You can check for Albania domain in host.al is the best that offer .al domain database whois for 4000 Domain name .al not .com.al

1 0

Scheduled Maintenance on RIPE Database Update Server - 10 May, at 14:00 UTC
by Denis Walker 08 May '12

08 May '12

[Apologies for duplicate emails] Dear colleagues, On Thursday, 10 May at 14:00 UTC (16:00 CEST), we will migrate the update service to a new server as part of our RIPE Database infrastructure upgrade. We expect the migration to take up to four hours. Part of this migration requires us to reload both the live and test database contents onto the new server. ----------------------------------- No changes during migration window ----------------------------------- No changes can be made to the RIPE Database or TEST Database during the migration. This includes the use of Syncupdates, Webupdates, RESTful API and the use of object editors provided through the LIR Portal. ----------------------------------- Hold off on sending email updates ----------------------------------- We also kindly request that you hold off on sending updates to the email update service (<auto-dbm(a)ripe.net>, <test-dbm(a)ripe.net>) during the migration window to allow us to make a clean restart of the new server and perform significant testing before processing any live updates. If any updates are sent to the email update service, they will be queued and run following the migration. If you do submit email updates during this time we recommend that you check the results later. ---------------------------------- RIPE Database queries unaffected ---------------------------------- Querying the RIPE Database will not be affected as this service is completely separated from the update service. However it will not be possible to query the TEST Database. We appreciate your cooperation and apologise for any inconvenience this may cause. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

rpsltool & odd prefixes in the RIPE db
by Erik Romijn 07 May '12

07 May '12

Hello, Running rpsltool[1] against the RIPE database, it broke on a rather odd object in the RIPE database: > inet6num: 2a02:4c8::1/64 > netname: ITDNET > descr: ITD Network, AD > country: BG > ........ > route6: 2a02:4c8::1/64 > descr: ITD Network AD > origin: AS9070 > ......... That doesn't seem right - the correct prefix would be 2a02:4c8::/64. I've asked the RIPE NCC about this, and they explained that internally, the database silently discards the host bits. So for the database, this is 2a02:4c8::/64. This is also visible in whois queries: searching for 2a02:4c8::1/64 yields no results, you have to search for 2a02:4c8::/64. Upon asking, the RIPE NCC responded that this is technically valid according to the relevant RFCs. But, they acknowledged that this behaviour can be confusing, and say they intend to disallow it at a later time. Down to my specific question: has anyone made the appropriate modifications to rpsltool to handle these kind of objects, and also silently discard the host bits in the address? I imagine we can't be the first people running into this. [1] http://www.linux.it/~md/software/ cheers, Erik Romijn

2 1

Re: [db-wg] Reverse aut-num queries in the database
by Wilfried Woeber, UniVie/ACOnet 20 Apr '12

20 Apr '12

David Freedman wrote: > After the feedback from the DB-WG Meeting in Vienna last week, I'd like > to bring this back to the list. > > I'd been trying to clean up an Aut-Num to return it to the NCC. I wanted > to know if there was a way of undertaking an inverse search against the > RPSL policies of my peers' Aut-Num objects to ensure they could remove all > references to be before handing the resource back. So - do I understand this correctly, you would like to have a query that lists all route[6]: objects with a particular origin: AS number in it? Or do you think about the Routing Policy analysis, e.g. the use of a particular AS number in a "macro"? > I'm currently doing this with a free-text search, since the database doesn't hold references to the tokens in the RPSL policy (or does it?) > > Any better ideas? > > Dave. Sorry for not responding to this message for so long. Blush :-( Wilfried

2 1

The WEIRDS effort at the IETF mentioned during the meeting
by Peter Koch 19 Apr '12

19 Apr '12

Dear all, the effort mentioned at the mike in the DB WG session few minutes ago is named "WHOIS-based Extensible Internet Registration Data Service" (WEIRDS). There have been two BOFs, which is the maximum number of official pre-WG meetings the IETF rules allow and the proponents are now working towards becoming an IETF working group. Absent that state, the full extent of nice tools is not yet available, but you will find the drafts relevant to the initiative at <https://datatracker.ietf.org/doc/search/?name=-weirds-&activeDrafts=on&sear…> There is also a mailing list in the archive of which you can find the latest proposed charter: <https://www.ietf.org/mailman/listinfo/weirds>. Various participants have blogged or otherwise shared their enthusiasm to eventually solve the "whois problem". Please use a search engine of your liking or start at <http://www.internetsociety.org/articles/something-weirds-way-comes>, noting that the IETF journal is always a nice source of overview information on what's up in the IETF. -Peter

1 0

New on RIPE Labs: Two new RIPE DB Related RIPEstat widgets
by Mirjam Kuehne 19 Apr '12

19 Apr '12

Dear colleagues, Please find two articles on RIPE Labs that describe two new RIPEstat widgets: 1. The object browser for RIPE database objects: https://labs.ripe.net/Members/becha/ripestat-objects-browser-for-ripe-datab… 2. The Address Space Hierarchy widget: https://labs.ripe.net/Members/becha/ripestat-address-space-hierarchy-widget Kind Regards, Mirjam Kuehne RIPE NCC

2 1

Re: [db-wg] RIPE64 DB-WG Draft Agenda V1 --> V2
by Wilfried Woeber, UniVie/ACOnet 19 Apr '12

19 Apr '12

This is a very late update/addition to the V1 draft agenda, bumping the version to V2 :-) Wilfried Wilfried Woeber, UniVie/ACOnet wrote: > Dear DB-WG folks, Chairpersons, "Meeting"! > > This is the 1st draft of an agenda for the DB-WG at RIPE64 in Ljubljana, > during CW16, April 2012. > > For time slot allocations please refer to the most up-to-date meeting > plan at http://ripe64.ripe.net/programme/meeting-plan > > The DB-WG Meeting is scheduled for *Thursday*, April 16th, starting > at 14:00 in the afternoon (in parallel with the meeting of the IPv6-WG). > The length of our timeslot is 90 Minutes. > > Please feel free to propose additional topics to be discussed! > > I'd also suggest that you submit your points of view regarding the > topics on the proposed agenda on the mailing list, preferably before > the WG meeting's start :-) > > > Best regards, > hope to see you soon in Slovenia, > Wilfried. > > ________________________________________________________________________ > > A. Administrative Matters > . Welcome > . select scribe > . finalise agenda > . approval of minutes from previous WG meeting(s) > . review of action list > > > B. Data Base Update (N.N., RIPE NCC) [~20 min] > - general update > - geolocation status/implementation > - internationalisation > > > C. RIPEstat (Daniel K., RIPE NCC) [~20 min] > - new way of accessing database content > - discussion about access control D. Review of implementation of auth: filtering - filtering of public key information - lack of hint about type/number of attributes omitted > Y. Input from other WGs and/or TFs > > > Z. AOB > ________________________________________________________________________ > > > > >

2 2

Geolocation beta functionality now in the RIPE DB
by Alex Band 18 Apr '12

18 Apr '12

Dear colleagues, We are happy to announce that geolocation functionality now is available as a beta in the RIPE Database. It can be optionally included in the INETNUM and INET6NUM objects. With the operational experience we gain with this beta, we will continue to develop it to a production service. Two attributes have been added: - "geoloc:" - "language:" The first attribute stores the geolocation data as longitude and latitude, specifying the area where the address space is used. The second attribute sets the preferred language that users of the address space wish to see content in. In addition, we are launching the Geolocation Finder: https://apps.db.ripe.net/search/geolocation-finder.html This tool helps you find geolocation data in the RIPE Database, by simply entering an IP address in the form. If the address is covered by either location or language data, the results are shown as text and on a Google map. Kind regards, Alex Band Product Manager RIPE NCC

1 0

Draft Minutes RIPE 63
by Nigel Titley 20 Mar '12

20 Mar '12

Folks, It looks to me as though I didn't send out the minutes for the DB-WG last November. Apologies for this. Please find them attached. Nigel

1 0

RIPE Database Access Control
by Denis Walker 09 Mar '12

09 Mar '12

Dear Colleagues As part of the redevelopment project for the RIPE Database, we re-implemented the Access Control List (ACL) mechanism. We simplified the process and have some questions to ask the community. 1/ Should we change the default query behaviour so personal data must be explicitly requested? 2/ Should we block access to personal data only and still allow access to operational data? 3/ Should there be more transparency of limits with some user options? More details about the new ACL and these three questions are provided below. As the RIPE NCC continues to progress with the redevelopment project, we will have more of these questions. The wider the community feedback on these questions, the easier it will be for us to build a RIPE Database service that satisfies your needs. Regards, Denis Walker Business Analyst RIPE NCC Database Group Overview of new ACL To make it very easy to understand what is happening, we have redefined the algorithm for blocking and unblocking. Now, when you hit a set limit for accessing personal data sets within a day, you will be temporarily blocked from accessing the RIPE Database. This temporary block will be removed at midnight (UTC). If you are temporarily blocked 10 times in a rolling 30 day period, you will be permanently blocked. A permanent block can only be removed by contacting Customer Services at <ripe-dbm(a)ripe.net> and discussing the situation. This is, in principle, the same as the current behaviour but with simplified time periods and reset points. Background to questions 1/ The current default behaviour on any query is to always return personal data referenced in any other data that is returned by the query. This is one of the main causes for temporary blocking of access to the RIPE Database. Personal data is often returned when it was not needed. To prevent the personal data being accounted, a query must include the '-r' option. Many users think an option like '-T INETNUM' will only return the INETNUM objects and no personal data will be involved. Unfortunately, '-T' is not a true query option. It is a filter. So the personal data is still queried and then filtered out of the results set. This causes the personal data to still be accounted for as if you had received it. We would like to suggest reversing the default query behaviour. This way no personal data will be returned unless you include a new query flag explicitly requesting it. 2/ The current blocking mechanism works on the basis of all or nothing. If you are not blocked, you can successfully query for any data in the RIPE Database. If you are blocked (either temporarily or permanently), any query from you is rejected with a "Denied access" error message. We would like to propose a middle road. Blocking can be set to only apply to personal data. So, after being blocked, you can still query for any operational data in the RIPE Database. But all personal data will be filtered out of the results set, even if you explicitly request it. If the community likes this idea, a further choice is possible. One option is to apply this middle road to both temporary and permanent blocks. Another is to only apply this to temporary blocks and keep a permanent block as a complete "Denied access" error. 3/ A final question regards information about the limits. In the past, details of limits and when they were reset were not clearly published in any document. But it is not difficult to determine them with a little trial and error. Perhaps the community would prefer complete transparency on this. We can publish all the limits in a revised Acceptable Use Policy (AUP) document and even provide a query option to let a user know how much of their daily limit they have already used.

6 8

Forward DOMAIN Object Cleanup and Syntax Changes
by Denis Walker 08 Mar '12

08 Mar '12

[Apologies for duplicate emails] Dear colleagues, At RIPE 57, the RIPE NCC was asked to remove all forward domain data from the RIPE Database. The last two ccTLD operators' data was removed today, 31 January 2011. The RIPE NCC can now confirm the completion of action point AP57.2 from the RIPE Database Working Group. At RIPE 62, the RIPE NCC was asked to look at the attributes in DOMAIN objects. With the removal of any hierarchy in reverse delegations and the removal of forward domain data, we no longer see any use case for the "mnt-lower:" attribute. Other attributes that it has been suggested were used only for forward domains are: - "refer:" - "sub-dom:" - "dom-net:" The statistics listed at the bottom of this email show how many of these attributes have been added to ENUM and reverse delegation DOMAIN objects. It has also been suggested that the "nserver:" optional attribute could be made a "required" attribute in reverse delegation DOMAIN objects. It could remain optional in ENUM DOMAIN objects or it could be disallowed. The RIPE NCC asked the community in July 2011 if anyone saw any justification for the use of these attributes in ENUM or reverse delegation DOMAIN objects. We did not receive any feedback on this. If there is no justification, the syntax of the DOMAIN object can be adjusted to deprecate these attributes. Then all current DOMAIN objects in the RIPE Database can be "cleaned" to remove this data. Business rules can be added to make the "nserver:" attribute required or disallowed in different types of DOMAIN objects, if this is considered useful. To keep the discussion focused, please send any comments or feedback to the DNS Working Group mailing list. Regards, Denis Walker Business Analyst RIPE NCC Database Group Statistics (as at July 2011) ---------- Number of each attribute used in reverse delegations or ENUMs and the number of unique maintainers who manage these objects. "refer:" = 6 unique maintainers = 1 "sub-dom:" = 271 unique maintainers = 23 "dom-net:" = 2,219 unique maintainers = 140 "mnt-lower:" = 46,485 unique maintainers = 4,208

9 11

Plain text passwords in email updates
by Denis Walker 22 Feb '12

22 Feb '12

Dear Colleagues, The RIPE NCC recently announced completion of an action point from the RIPE Database Working Group to hide the password hashes in MNTNER objects from public view. As a follow up to that, we agreed to contact all maintainers and advise them to update their passwords. This was also completed last week. At RIPE 64 we will provide some statistics on the outcome of that advice. The next issue that was raised in the Database Working group session at RIPE 63 was the use of plain text passwords in emails to update data in the RIPE Database. The RIPE NCC would like to invite members of the community to put forward and discuss ideas on resolving this matter. Note that there are now many ways to update objects in the RIPE Database. As well as the traditional email service, there is also Webupdates for single or small numbers of objects to be updated. For scripting of automated updates, there are Syncupdates and the RESTful API. Some ideas that have been suggested during discussions in the past are to disallow the use of passwords in email updates and also the option to drop email updates completely. There may also be other options. As usual, the RIPE NCC will follow any discussions and provide technical input where necessary. Regards, Denis Walker Business Analyst RIPE NCC Database Group

3 4

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