- db-wg - mailman.ripe.net

Call for agenda items, DB-WG meeting during RIPE71, Bucharest, Romania
by Piotr Strzyzewski 03 Oct '15

03 Oct '15

Dear DB-WG participants We are reaching out to you for agenda items for the Database Working Group session during the RIPE71 meeting in Bucharest, Romania, 16-20 November 2015. The DB-WG session is currently scheduled as usual for Thursday (Nov 19th), starting at 16:00 local time, after the coffee break. The length of our timeslot is 90 minutes. Please submit your items or topic suggestions directly to the WG chairs or to the list for public discussion. The draft agenda will be published soon. Looking forward to see you all in Bucharest. All the best, Job, Nigel & Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

6 7

Re: [db-wg] PHP Client for RIPE REST Web Service
by Alexander Stranzky 25 Sep '15

25 Sep '15

Hello, I’ve written a PHP client for the REST web service and now I want to open a discussion whether this library is sufficient for people using the RIPE web service or if there are things I didn’t consider when developing it. the library is available at github: https://github.com/Dormilich/ripedb-client Best regards, Alex

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 22 Sep '15

22 Sep '15

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/support/training/learn-online/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 22 Sep '15

22 Sep '15

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 1

Re: [db-wg] This db-help list will be discontinued
by ripedenis＠yahoo.co.uk 18 Sep '15

18 Sep '15

Hi guys I don't really have any opinion either way as to whether this list is discontinued. But as it is a RIPE list and not a RIPE NCC list I think it should at least be proposed to close it with some justification rather than an announcement of a decision. I can see from the archive that it has not been used very much recently, but maybe that is because it is already shown on the web site as an inactive list. Just for some historical background, this list was intended as a self help forum on database issues. Users of the RIPE Database could ask questions about specific problems or more general issues about usage of the RIPE Database, how other members interact with the database and what tools, if any, they use. Other users could offer advice and the RIPE NCC would only contribute if any questions were left unanswered. So is it considered that there is no need now for a self help forum? Should all questions be directed straight to the RIPE NCC via ripe-dbm or should such questions now go to the DB-WG? If the latter then the description of the DB-WG mailing list should be amended to reflect this. (btw the web site still lists Wilfried as the chair :) ) cheersdenis From: Alex Band <alexb(a)ripe.net> To: db-help(a)ripe.net Sent: Wednesday, 16 September 2015, 13:27 Subject: This db-help list will be discontinued Dear colleagues, We are going to discontinue this mailing list, db-help. If you would like to discuss something related to the RIPE Database, there are several options available: 1. For support or to submit bug report, please contact the RIPE NCC by visiting https://ripe.net/contact or send a message to ripe-dbm(a)ripe.net 2. To start a public discussion about the RIPE Database, for example about suggestions for functionality changes, best practices or operational usage, please subscribe to the RIPE Database Working Group mailing list: https://www.ripe.net/mailman/listinfo/db-wg/ This list will be disabled shortly. Kind regards, Alex Band RIPE NCC

1 0

Re: [db-wg] FAILED: arak1
by ripedenis＠yahoo.co.uk 09 Sep '15

09 Sep '15

Hi Reihane I don't think anyone monitors this db-help list now. I have seen several questions go unanswered on here. But I can answer the question for you. You are trying to create the object 2.179.95.128 - 2.179.95.255 with status 'ASSIGNED PA'. The parent object is 2.179.95.96 - 2.179.96.127 and this also has status 'ASSIGNED PA'. You cannot create a hierarchy of objects all with status 'ASSIGNED PA'. The parent object range is assigned to Islamic-Azad-University-Of-Ashtian. That is part of an allocation range 2.176.0.0 - 2.191.255.255 made to Information Technology Company (ITC). If you have been assigned the sub range 2.179.95.128 - 2.179.95.255 then you need to ask ITC to split the parent object into separate assignments. Otherwise you need to ask ITC to assign you a different range. Either way as ITC controls this block you need to talk to them. cheersdenis From: Javidi <ripe(a)dci.ir> To: db-help(a)ripe.net Sent: Tuesday, 8 September 2015, 12:29 Subject: FW: FAILED: arak1 Why does this object not create? 2.179.95.128 - 2.179.95.255 Error: inetnum parent has incorrect status: ASSIGNED PA But this is not coorect Please advise me Regards Reihane -----Original Message----- From: RIPE Database Administration local [mailto:unread@ripe.net] Sent: Tuesday, September 08, 2015 11:58 AM To: ripe(a)dci.ir Subject: FAILED: arak1 > From: Javidi <ripe(a)dci.ir> > Subject: arak1 > Date: Tue, 08 Sep 2015 10:27:40 +0200 > Reply-To: Javidi <ripe(a)dci.ir> > Message-ID: <002001d0ea18$1e780080$5b680180$(a)dci.ir> SUMMARY OF UPDATE: Number of objects found: 2 Number of objects processed successfully: 1 Create: 1 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 1 Modify: 0 Delete: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: arak1 ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Create FAILED: [inetnum] 2.179.95.128 - 2.179.95.255 inetnum: 2.179.95.128 - 2.179.95.255 netname: Telecommunication-of-Markazi descr: Telecommunication Company country: IR admin-c: AUTO-1 tech-c: AUTO-1 status: ASSIGNED PA mnt-by: AS12880-MNT changed: ripe(a)dci.ir 20150908 source: RIPE ***Error: inetnum parent has incorrect status: ASSIGNED PA ***Warning: Deprecated attribute "changed". This attribute will be removed in the future. ***Warning: Referenced person object aaa159-RIPE from mntner: AS12880-MNT is missing mandatory attribute "mnt-by:" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were processed SUCCESSFULLY: --- Create SUCCEEDED: [person] SM29689-RIPE soroush mazdak ***Warning: Deprecated attribute "changed". This attribute will be removed in the future. ***Warning: Referenced person object aaa159-RIPE from mntner: AS12880-MNT is missing mandatory attribute "mnt-by:" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The RIPE Database is subject to Terms and Conditions: http://www.ripe.net/db/support/db-terms-conditions.pdf For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net> Generated by RIPE WHOIS Update version 1.80.1 on DB-2 Handled email update (RIPE, 2015-09-08 10:27:57)

1 0

Database release 1.81 deployed to RC environment
by Alex Band 08 Sep '15

08 Sep '15

Dear colleagues, We are happy to announce the deployment of RIPE Database software release 1.81 to the Release Candidate (RC) environment. This release extends and fixes some of the functionality changes that were part of the 1.80 release, especially with regards to authenticating and creating objects. This is why we urge you, again, to thoroughly test the RC environment to make sure nothing in your workflow breaks: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… Here are the most notable changes I'd like to highlight. When using the RC environment, please focus on using webupdates to test these features: - We added auto-complete for attributes such as maintainers. This means you can start typing a maintainer name and webupdates will suggest existing maintainers, along with their associated authentication. - Webupdates tries to be smarter about deleting objects. When, for example, you want to delete a person object, webupdates will suggest you also delete the associated maintainer, if it is not referenced anywhere else. - "Create a new person and maintainer pair" (previously known as the New Organisation Startup Form) has been redesigned. After logging in with your RIPE NCC Access account, you just need to enter four fields to get going. Because webupdates contains such fundamental user interface changes, gathering your feedback has been cumbersome at times. This is why we added the Usersnap feedback widget to the RC environment, so you can highlight and annotate the page you are providing feedback on. It will make it easier for us to process your comments and implement fixes and changes. From all of us at the Database team, we are looking forward to your comments and we hope you enjoy this release! Kind regards, Alex Band Product Manager RIPE NCC

1 0

[training] IP Address Space Course this November in Bucharest
by Training Services 08 Sep '15

08 Sep '15

Dear colleagues, We are happy to announce that a RIPE NCC training course will take place on the Sunday before the RIPE 71 Meeting in Bucharest this November. This course will focus on how to obtain and manage IP address space. The course is free of charge and is open to anyone interested. The course will cover the most frequently asked questions that the RIPE NCC receives about IP address space. ----------------- Course details ---------------- IPv6 Address Space Basics: How to Obtain and Manage Your IP Addresses Sunday, 15 November 2015, 10-16:00 JW Marriott Bucharest Grand Hotel ---------------- Course goals ---------------- By the end of this course, you will be able to: - Manage your IPv4 and IPv6 addresses according to current RIPE Policies - Understand how to obtain IPv4 addresses through transfers - Protect your address space from hijacking ---------------------------------------- Who will benefit from this course? ----------------------------------------- Anyone interested in the policies and procedures around address space in the RIPE NCC service region will find this course useful. No prior knowledge of the topic is necessary. ------------------------- Course outline: ------------------------- - Becoming a RIPE NCC member (why and how) - Obtaining IP addresses (IPv4 and IPv6) - IP address space transfers, mergers and acquisitions - IPv6 basics - Address space hijacking - Resource Certification (RPKI) ---------------------------- Additional information ---------------------------- - Free of charge - Coffee and lunch will be provided - Delivered by the RIPE NCC’s Training Services and Registration Services departments ----------------------------------------- Registration for RIPE NCC members ----------------------------------------- If you are a RIPE NCC member and interested in attending this course, please visit our website on the following page to register: <https://lirportal.ripe.net/training/register/courseCode/LIR20150032> ------------------------------------ Registration for non-members ------------------------------------- If you are not (yet) a member, please fill out the following information and send this to <training(a)ripe.net>: - Email: - Course name: - Full name : - Vegetarian: yes/no Be quick - we only have 45 seats available on a first come, first served basis! If there is enough interest, we will continue to offer courses on different topics of interest alongside future RIPE Meetings. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Training Courses October-December 2015
by Training Services 27 Aug '15

27 Aug '15

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Amsterdam, Athens, Odessa, Naples, Cardiff, Barcelona, Oslo, Bucharest, Budapest, Istanbul, Zagreb, Doha, Berlin. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - 2 days Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Updating maintainer objects with filtered auth lines
by Daniel Stolpe 24 Aug '15

24 Aug '15

I just had a very specific experience but this is a general problem. What I wanted to do was update a maintainer object in the database. No problems since I was authorized via a PGP key. The problem was that one of the lines looked like: auth: MD5-PW # Filtered And although I have no personal use for the md5 hash I did not want to disturb users who might have. I asked the NCC for advice and the answers were like "if you have an access account" (yes) you can add a line "auth: SSO xxxx(a)xxxx.xx" (yes). Still not a solution to my problem since adding the SSO line would just break the md5 anyway. The solution this time was that I eventually found a local copy of the object with the md5 hash unfiltered. I know the md5 hashes are a security problem and I do not recommend anyone using them but as long as they are there the filtering causes trouble. And by the way, we now see a lot of auth: SSO # Filtered What I am looking for is a way to retrieve the whole unfiltered object for anyone authorized, or, at least, a possibility to updated the object without touching the filtered lines. Maybe you could send a PGP signed request, not for updating but just for viewing the complete object? Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe(a)resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm

6 9

call for application authorisation ideas
by Job Snijders 24 Aug '15

24 Aug '15

Hi group, I know all of you have automated their interactions with the RIPE database entirely. :-) As it currently stands, there are two ways to automate interaction with the RIPE DB: a) send GPG signed emails (and wait for the dumb greylisting to clear) b) call the http://rest.db.ripe.net/{source}/{objecttype}/{key}?password=XXX restful API Option A works, but is not very nice if you want something done immediatly and require a confirmation that the operation succeeded. The advantage of option A is that you don't need any auth: MD5-PW lines in your mntner object and RIPE stores no sensitive data. Option B goes very well with modern programming paradigms, but the disadvantage is that you need to have an "auth: MD5-PW XXX" line in your maintainer, and should that pass ever leak somehow it could be used through webupdates / email / api, from any location. I think all in the group agree that it would be very nice if you can perform 100% of all operations without the need for any MD5-PW. I'll even go as far as stating that we should not be looking at successors such as SHA3-PW, let's leap forward and make the PW auth concept entirely obsolete. :-) CALL FOR IDEAS ============== Now that personalised authorisation is covered and in progress, what about our poor applications? How should they authenticate with the RIPE DB? I see value in stuff like signalling to RIPE "this token can only be used for the API from this source IP address", I've also heard that OAUTH2 is magic and populair for app2app auth. Or maybe all of this is is overkill and we just need to GPG sign the payload of the requests to rest.db.ripe.net and call it a day? DB-WG, please speak up and voice your ideas! Kind regards, Job

5 10

Re: [db-wg] [opensource-wg] Question for RPSL Parser
by Stavros Konstantaras 20 Aug '15

20 Aug '15

Shane is right, I don’t have the intention to shuffle the project with Bison and Flex because 1) I don’t have the knowledge of these technologies 2) I don’t have the time to learn them 3) I want to Pythonize as much as I can and be independent as much as possible (OK maybe a little bit dependent from other Python Libraries but this is the boundary). I am sure that you guys made a great job 14 years before but now or soon RPSL will be replaced with something else so I still want my toolset to be alive by easily and quickly replacing 1-2 Python libraries. What my prototype does now is extract the attributes and values by using Regular Expressions, a solution that has already been proposed in this discussion and I think this is the way to go. In theory, it can be an easy parser based on Python’s RE but complexity starts when -for example- RPSL says “accept as-set BLABLA” instead of “accept 10.100.200.0/16" and that as-set needs to be resolved (another query to RIPE DB). But anyway, thanks for your ideas. Crazy or not, I don’t mind everyone is welcome. If I still need to reply to Tomas last e-mail but I am quite busy today. Kind Regards Stavros > On 20 Aug 2015, at 13:05, Shane Kerr <shane(a)time-travellers.org> wrote: > > Denis, > > There are two problems with this: > > 1. Lex and YACC (actually flex and bison for the RIPE Database) are > tightly integrated into C (or C++ if you are feeling brave). > > 2. Stavros does state a goal of avoiding reuse of past or legacy > software, which surely means the RIPE Database code. (Okay, I think > it was only 12 or 14 years ago when we wrote these parts, but that > surely counts as "past"...) > > :) > > Cheers, > > -- > Shane > > On Thu, 20 Aug 2015 10:56:20 +0000 (UTC) > denis walker <dw100uk(a)yahoo.co.uk> wrote: > >> HI >> The RIPE Database I believe still uses LEX and YACC to parse the routing policy information from the RPSL attribute/value pairs. Is it possible to just 'drop' this into a python script and extend it to do any extra parsing you want? (I know nothing about python so I may be way off the mark here :) but it is just a thought) >> cheersdenis >> From: Shane Kerr <shane(a)time-travellers.org> >> To: Stavros Konstantaras <stavros(a)nlnetlabs.nl> >> Cc: db-wg(a)ripe.net >> Sent: Thursday, 20 August 2015, 5:21 >> Subject: Re: [db-wg] [opensource-wg] Question for RPSL Parser >> >> Stavros, >> >> On Wed, 19 Aug 2015 16:00:59 +0200 >> Stavros Konstantaras <stavros(a)nlnetlabs.nl> wrote: >> >>> To make things more clear, our project at NLnet Labs is the >>> development of "a modern IRRtoolset" written in Python and targeting >>> any operator, not just another homemade tool for our own needs. Or to >>> say in more detail the creation of a tool that is able to configure >>> BGP routers directly+automatically by extracting the policies from >>> RIPE DB. This means that I am struggling to avoid the (re)use of any >>> past or legacy software that exists, otherwise we loose independency >>> and inherit restrictions from the past. >> >> I don't know of any Python RPSL parser you can use. >> >> Your goals make a certain amount of sense. Unfortunately RPSL is an >> ugly language... it's actually more like several languages in one, all >> bad. :P >> >> * Start with simple attribute/value, one per line >> >> * Oh, but then "RPSL-ize", which allows line continuation and >> end-of-line comments >> >> * Oh, actually we want to make a separate grammar for each attribute >> >> * But be sure to make all of this "extensible", to insure maximum >> confusion! >> >> My approach in the past has been to start with a simple generic parser >> that split text into objects, objects into attributes, extracts >> attribute name & values (handling line continuation and end-of-line >> comments). You can do all of this with Python regular expressions, >> something like r"\n(?![ \t+])" to split objects into attributes; >> cleaning end-of-line comments & line continuation characters is >> straightforward. Then you can deal with the grammar for the attributes >> you know, and ignore the rest. You can extend the parsing to be more >> and more comprehensive until you are able to parse the data set you >> worry about. >> >> I'm not sure this is worth doing... but if there was a good, >> easy-to-use Python library then maybe interesting things would result? >> >> >> >> Cheers, >> >> -- >> Shane >> >> >> >> >

2 1

Re: [db-wg] [opensource-wg] Question for RPSL Parser
by Stavros Konstantaras 20 Aug '15

20 Aug '15

Hi Thomas and others, thanks for your quick replies. To make things more clear, our project at NLnet Labs is the development of "a modern IRRtoolset" written in Python and targeting any operator, not just another homemade tool for our own needs. Or to say in more detail the creation of a tool that is able to configure BGP routers directly+automatically by extracting the policies from RIPE DB. This means that I am struggling to avoid the (re)use of any past or legacy software that exists, otherwise we loose independency and inherit restrictions from the past. Currently, I do have a working proof of concept with a simple RPSL parser written in Python which is able to parse simple policies with (v6)import(s)-(v6)export(s)-accept-announce-action-pref-med-coomunity attributes. Convenient I would say for many existing policies like KPN’s, RIPE’s etc. but definitely it will crash in complex policy files like GRNET’s. My current solution uses also BGPq3 to translate AS, AS-SET and ROUTE-SET and this is also something that I want to ged rid of. So I was looking for the existence of a Python Library which can do a complete job and translate any existing policy in an intermediate data structure like XML (this is what I do now). I was hoping to find one, adopt it and present our (completed) work in the next RIPE meeting (yes I know I am very ambitious, I need to slow down). * Masimo, I already checked rpsltool and discarded it. But thanks for your super-fast reply. * Tomas, thanks for pointing me to your library. I will have a look at it and check if it is convenient for our project. * George, yes you are right. This should be the #1 step, take corresponding RPSL RFCs and implement them in Python. However, that would take too much time and will not allow us to work on other missing functionalities of the prototype. And we would like to have something ready at the beginning of November. However, I will check your solution as well. I hope now that I made myself more clear. Big thanks to everyone, every help, info or idea is kindly appreciated. Kind Regards Stavros ---- Stavros Konstantaras Internet Research Engineer, NLnet Labs Science Park 400, 1098 XH, Amsterdam Fingerprint: 4502 7D16 2DF8 ADB0 4AA6 21A9 BF9E EFFF 2744 FE5D > On 19 Aug 2015, at 14:39, Tomas Hlavacek <tomas.hlavacek(a)nic.cz> wrote: > > Hi Stavros! > > On 08/19/2015 02:15 PM, Ondrej Filip wrote: >> >> Vis o necem? >> >> -------- Forwarded Message -------- >> Subject: [opensource-wg] Question for RPSL Parser >> Date: Wed, 19 Aug 2015 14:13:58 +0200 >> From: Stavros Konstantaras <stavros(a)nlnetlabs.nl> >> To: db-wg(a)ripe.net >> CC: opensource-wg(a)ripe.net >> >> >> >> >> Hi all WG members, >> >> For my project at NLnet Labs I would like to ask you if you know any >> (relatively) complete RPSL parser written in *Python*. I searched >> around and I didnât find anything. Does someone know any repository >> where I can get one or maybe contact someone who has written one? > > It depends on what you need... I wrote one - > https://github.com/tmshlvck/bgpcrunch , but the aim was rather data > analysis than "authoritative" RPSL translation. When it comes to filter > interpretation my approach is quite "heuristic" and it is focused on > speed and ability to take short-cuts which wouldn't be possible with > full parsing the RPSL objects according to EBNF metasyntax. > > Have you considered creating simple Python interface for peval from > IRRToolSet? It might do the job if you don't need any special features. > > Cheers, > Tomas

4 4

Question for RPSL Parser
by Stavros Konstantaras 19 Aug '15

19 Aug '15

Hi all WG members, For my project at NLnet Labs I would like to ask you if you know any (relatively) complete RPSL parser written in Python. I searched around and I didn’t find anything. Does someone know any repository where I can get one or maybe contact someone who has written one? Thanks in advance. Kind Regards Stavros ---- Stavros Konstantaras Internet Research Engineer, NLnet Labs Science Park 400, 1098 XH, Amsterdam Fingerprint: 4502 7D16 2DF8 ADB0 4AA6 21A9 BF9E EFFF 2744 FE5D

3 2

NCC still enforcing descr: content
by Jan Saner 15 Aug '15

15 Aug '15

Hello Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is: https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html Quote: ----------------------------------------------------------- "> When will this change go into effect? We were thinking of mid April, for two reasons: 1) This gives the working group enough time to comment. 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." ----------------------------------------------------------- I personally know a case where the NCC went as far as to ignore German “umlauts” in the name and deliberately spell it wrong in the descr: field of the guy’s AUT-NUM object. When he tried to set it right (ae (ä) instead of a), the NCC reverted the change. Then there’s a case where someone tried to remove his middle name from the descr: field —> reverted. Another post on the same subject: https://www.ripe.net/ripe/mail/archives/members-discuss/2015-June/001737.ht… Looks like there’s still a lot of energy wasted in those descr fields now that the org pointer is mandatory. Cheers

10 17

Upcoming work by the RIPE NCC Database team
by Tim Bruijnzeels 14 Aug '15

14 Aug '15

Dear working group, Following working group discussions in different threads we would like to give you a quick overview of current and planned work. 1= SSO integration in Webupdates As you may know we have been working on this in the background for a while. The objective of this effort is to improve the integration of SSO with Webupdates. Where previously we were asking users to provide plain text (MD5) passwords, and storing them in the session, we now want to encourage everyone to use their SSO account instead. We expect that we will finish this work 2-3 weeks from now, and plan to deploy a new release 1.81 to the RC environment then. 2= Changed phase 3 - deprecating "changed:" We plan to work on this as soon as the SSO release is deployed to the RC environment. We we expect that we can have a release 1.82 for this ready for testing in the RC environment by the end of September. As mentioned before, because the impact of this change can be bigger than usual, we plan to have this release in RC for testing for 6 weeks before deploying it to production. 3= Descr We don't foresee major technical issues with the options being discussed currently, but can only present a definite implementation plan when consensus is reached on this. If consensus is reached in time, it may be an option to postpone the release of 1.82 above and have a bigger release that also includes this work - to avoid delays because of the long RC period required for that release. 4= Personalized Authorization We are very happy to have a mandate from the chairs to work on a proof of concept for personalised authentication. We look forward to implementing this as soon as we have the opportunity and working closely with the working group using the RC environment. In addition to core whois changes we will also deploy improvements to Webupdates in the RC environment when we work on this - to exemplify how we can make use of this to improve usability. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

1 0

Proposal about personalised authorisation
by Tim Bruijnzeels 12 Aug '15

12 Aug '15

The RIPE NCC has discussed the concept of personalised authorisation on various occasions, most recently at the DB WG session at RIPE 69. Following discussions and input from the working group we would now like to propose the following additions to the RIPE Database: = Extend the person object template with "auth:" as an optional, multiple attribute, with all current authentication methods. = Extend the mntner object "auth:" attribute with a new method that allows a reference to a person object that has at least one "auth:" attribute. There is no requirement to use these extensions, but users that choose to do so can benefit from the following advantages: = Currently it is is not always clear who uses the credentials in each "auth:" attribute on a mntner. There are two main problems with this. First of all this can result in authorisation being given to the wrong users, and second this makes it difficult to keep these objects up to date. For example it is not easy to remove the password for a specific user from a mntner without knowing, or deducing, which password hash is theirs. Having explicit references to person objects will make this clear. = Users who are authorised for multiple mntners will be able to maintain their own credentials in one place. = Audit logging can be improved. It will become possible to show to authorised users of the database which person made which change to their object. = The security of regaining lost access to a maintainer can be improved by letting users of the database reset the credentials on their own person object, rather than on a maintainer. Especially when the person object is linked with a Single Sign-On account. Allowing "auth:" attributes on person objects also allows us to make it easier for users to manage their person object in the RIPE Database in combination with their Single Sign-On (SSO) account on RIPE NCC Access as a single identity. To facilitate this we propose the following: = Being they are part of the same identity, person objects can only be associated with one SSO account, and vice versa. = Associated person objects and SSO accounts are automatically kept in sync. = SSO accounts can associated with new person objects, or existing person objects, provided that the user has access to both the SSO account and at least one maintainer of the person object. = Users will be able to decouple their own SSO account and person object.

4 4

Help needed to delete an object via email
by Hank Nussbacher 07 Aug '15

07 Aug '15

I believe I have encountered a bug with email processing of updates via auto-dbm@ripe and have not been able to engage the people there via ticket NCC#2015080034. I reported it and the ticket was quickly closed without being solved. I therefore ask for help from the hive-mind. The recently added "remarks:" line is causing parsing problems. The line looks like this: remarks: For information on "status:" attribute read https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources First I tried editing an object but the parser kept chopping the line as follows: >remarks: For information on "status:" attribute read >https: >//www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources >***Error: "https" is not a known RPSL attribute So I just deleted the line and was able to update the object. But now I want to delete an intenum object with the "remarks" line. When I do that I get: >remarks: For information on "status:" attribute read >https: >//www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources >... >created: 1970-01-01T00:00:00Z >last-modified: 2014-05-27T13:18:49Z >source: RIPE > >***Error: Object [inetnum] 192.114.48.0 - 192.114.63.255 doesn't match >version > in database The parser again chops the line at https and auto-starts a new line and therefore flags the entry as not macthing the version in the DB. Is there a workaround for this? Some escape character that will cause it not to break the line? Thanks, Hank

5 11

RIPE DB syntax check for mp-import
by Tomas Hlavacek 06 Aug '15

06 Aug '15

Hello! I just noticed that aut-num object for AS2852 in RIPE DB contains line mp-import: afi ipv6.unicastfrom AS39790 with 'afi ipv6.unicast' and 'from' keywords merged, which causs some confusion of my parsing scripts. Maybe I am missing something but I think this is not syntactically valid, is it? And if it is not, how could that get into RIPE DB? Tomas

3 2

ad-hoc RIPE db-wg meeting at IETF93
by Job Snijders 27 Jul '15

27 Jul '15

Dear best-db-working-group-in-the-world! I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-) I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage. Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details. Let me know if you are interested in attending this ad-hoc db-wg meeting. No worries if you aren't around this time, we'll see each other at RIPE71 in Budapest. Kind regards, Job

6 13

Release 1.80.1 deployed: warning users on failed update/delete, if maintainers had passwords removed
by Tim Bruijnzeels 16 Jul '15

16 Jul '15

Dear working group, We have just deployed whois release 1.80.1 to production. We have seen some cases where users were not aware that passwords had been removed from their maintainer, and they would only get an "authorisation failed" error. To help these users debug this issue better we now also include the following warning in case one or more of the maintainers had any passwords removed: "MD5 passwords older than November 2011 were removed for one or more maintainers of this object, see: https://www.ripe.net/removed2011pw" Example case (used by us for testing): > The following object(s) were found to have ERRORS: > > --- > Create FAILED: [person] AP1-TEST Another Person > > person: Another Person > address: Some Address > phone: +12 345 678 90 > nic-hdl: AP1-TEST > mnt-by: OWNER-MNT > source: TEST > > ***Error: Authorisation for [person] AP1-TEST failed > using "mnt-by:" > not authenticated by: OWNER-MNT > > ***Warning: MD5 passwords older than November 2011 were removed for one or more > maintainers of this object, see: https://www.ripe.net/removed2011pw Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team

1 0

MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
by Pierre Kim 14 Jul '15

14 Jul '15

Dear Database Working Group Members, I am contacting you to share the thoughts on the usage of MD5 in the RIPE database. I already discussed the problems concerning MD5 authentication with RIPE NCC Security<security(a)ripe.net> on 2 Apr 2015 and RIPE NCC Security officer encouraged me to contact your group to work together on this issue. In 2011, I had grabbed all the MD5s of the RIPE database before they were taken out from the public view and I don't think I was the only security researcher who downloaded all the hashes. This john-compatible file (containing MNT logins and MD5 hashs) was never exposed to public but the hashs can be (VERY) easily cracked. From the discussion with RIPE Security (who received a copy of this file), 27.000 usable hashes (on a total of 36.000) appeared to be valid til now. By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database , I see : "The MD5 hash is public, when running a single query (not for bulk queries)." I assume this was a known problem but the RIPE didn't alert that all the hashs have been retrieved, although there were some urgency to change the passwords or to use a safer authentication method. When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015. The 90 day period can be adjusted by adding more days at the end if RIPE shows a good progress of the migration. I wanted to do responsible disclosure when I saw the RIPE Responsible Disclosure Policy which is a Really Good Thing, I think. According to the RIPE transparency, as recommended by RIPE NCC Security, therefore I am now contacting this working group to work together because deprecation of MD5 is an important change in the RIPE database and it must be debated in a democratic manner. My analysis is simple: The MD5 authentication is broken for years and it's time to change to a more secure method. I think people needs to be encouraged to move to SSO authentication. Using MD5 now is unsafe and dangerous, especially with unchanged 4 year-old passwords. Please share your thoughts about this situation. I will be happy to debate with you. I want to thank Ivo Dijkhuis, RIPE NCC Information Security Officer, for the quality of the exchanges we had. Regards, -- Pierre Kim pierre.kim.sec(a)gmail.com @PierreKimSec https://pierrekim.github.io/

13 25

Release 1.80 deployed to production
by Tim Bruijnzeels 13 Jul '15

13 Jul '15

Dear working group, Release 1.80 was just deployed to production, introducing the following changes: = The “changed:” attribute is now optional, marking phase 2 of deprecating changed. = The "referral-by" attribute in maintainer objects is now deprecated. Update on upcoming releases: Over the past weeks we have been making good progress on improving the integration of web updates with the Single Sign-On system. This will help improve the usability of web updates, but it will also help to reduce the dependency of incidental users of the database on MD5 passwords. Considering the recent trouble with old MD5 passwords on maintainers we believe that there is a lot of value in finishing this work as soon as possible. We are close to a working solution and we will deploy it to the RC environment over the coming weeks, before releasing this to the production environment. As soon as this is done we will get back to implementing phase 3 of deprecating changed (deprecate the "changed:" attribute itself), which we expect to be ready to be deployed to the RC environment by the end of August. Please let us know if you have any questions or comments, Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team

1 0

Re: [db-wg] Temporary origins
by George Michaelson 09 Jul '15

09 Jul '15

On 25 June 2015 at 21:42, Job Snijders <job(a)instituut.net> wrote: > On Thu, Jun 25, 2015 at 09:33:44PM +0200, George Michaelson wrote: > > For your information, APNIC Hostmasters have moved to a mode of > > operation where for inetnum owners where the AS holder is not the same > > person, and a request is lodged with helpdesk for assistance, the > > hostmasters manually override and create the object for the inetnum > > holder, only removing it if an AS holder objects. The inetnum holder > > needs to be recognised in our systems. > > > > Its a hand-mediated inetnum-only route object. Previous practice was > > to wait for explicit approval from the AS holder. Now, its created > > first, and withdrawn if there is an objection. > > > > There have been no complaints. APNIC HM are considering portal changes > > and other process work to automate this. > > What is the benefit of the hand-mediation? Or is that just an artifact > of the software implementation? Its an artefact of the s/w implementation. I imagine once they work out how to do this in the portal, this will be changed. > Does APNIC send a notification to the AS > holder that an object was created in which they were referenced? > Yes. The following template is used: ====== Dear (ASN custodian), This is to inform you that the following route/route6 object has been registered in the APNIC Whois Database with your AS number referenced in the "origin" attribute. --- insert route object --- The IP addresses holder has asked that APNIC help register this route object in the APNIC Whois database. If you believe your AS number should not be referenced as the "origin" in this route object, please contact us by replying to this email. Kind Regards, ====== cheers -George > > Kind regards, > > Job >

9 9

Deal with "non-breaking-space"-characters in updates
by Marc Grol 09 Jul '15

09 Jul '15

Summary: Currently the whois database accepts “non-breaking-space”-characters in updates. We propose that whois replaces these “non-breaking-space”-characters with regular spaces before storing the object. Context: Currently the whois database accepts updates with "non-breaking-space”-characters as part of attribute values. This behaviour is fairly acceptable, since the "non-breaking-space”-character is part of the “latin1”-character-set which is supported by whois. The whois database treats these "non-breaking-spaces”-characters as regular spaces and considers the object to be syntactically correct. However, the object is stored exactly as it was received from the client: including non-breaking-spaces Problem: We think most of these "non-breaking-spaces” where intended to be regular spaces, but ended up mangled due to copy and paste. So, when such an object is being queried for, the original object (including non-breaking-spaces) is being returned. This is inconvenient. since most clients cannot handle this “exceptional” character. It many clients it will end up as something like a “?’-character. Alternative solutions: -1- Let whois software accept the update but convert "non-breaking-spaces” into regular spaces before storing -2- Consider requests containing "non-breaking-space”-characters as syntactically incorrect, and do not accept updates containing them. -3- Keep current solution: You get what you asked for. Some additional statistics that can be used to understand the size of the problem: Approximately 3.000 objects (out of 8.000.000) contain "non-breaking-space”-characters. Mostly in “remarks"-, “description"- and “address"-attributes? Marc Grol member of ripe’s whois database team mgrol(a)ripe.net <mailto:mgrol@ripe.net> +31648928856

5 5