- db-wg - mailman.ripe.net

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