- db-wg - mailman.ripe.net

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 19 Aug '15

19 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

Re: [db-wg] Temporary origins
by snash 02 Jul '15

02 Jul '15

Alex I think the notification to the ASN holder is a good thing. The notification could include a reference to the inetnum holder so that the ASN holder could make contact more easily, if necessary. If we accept that the inetnum holder has the authority to create, then it is not clear to me why the ASN holder should have the right to delete. If there has been a mistake it is to the detriment only of the inetnum holder's organisation, and they can remove the Route Object and correct it. For clarity - By "ASN holder" we are referring to the origin ASN in the new Route Object, not any other. This policy change would enable a clear and simplified instruction for organisations needing authority to originate temporarily. Thanks Steve > On 26 Jun 2015, at 06:43, George Michaelson <ggm(a)apnic.net> wrote: > > > > 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 > End of db-wg Digest, Vol 47, Issue 1 ************************************

1 0

Re: [db-wg] re-evaluate route-object authorisation model
by George Michaelson 27 Jun '15

27 Jun '15

On 27 June 2015 at 09:17, Job Snijders <job(a)ntt.net> wrote: > On Sat, Jun 27, 2015 at 06:32:10AM +0200, George Michaelson wrote: > > > > and note that, with one mouth, job has said that the ripe irr is the > > > > only one he will trust. > > > > > > Unsure if i follow you exactly, but indeed, I only trust the RIPE IRR > > > when it comes to RIPE managed space. > > > > Why then, do you expect anyone to trust RIPE IRR for all the un-RIPE > > managed space which can be freely added, to permit RIPE managed space > > related objects to be made? > > I don't recall expecting that? Did i in some earlier email forget to > insert a criticial 'not' in a sentence or something? > So those route objects which refer to RIPE managed space, and non-RIPE managed space. Do you filter them out? The ones which have non-RIPE objects inserted? I thought you meant that if it was in the RIPE IRR you trusted it. I didn't realize you were performing a post-check on the origination of the referred elements in route and other objects. Sorry _G > > > Surely from a consistency point of view (and yes, its reductionist, > > but so is software) this means we shouldn't be trusting all the > > additional objects added 'for your convenience' under the open > > password maintainer? > > Yes, the open password maintainer is a thorn in our side. Relevant to > the discussion: https://ripe70.ripe.net/archives/video/132/ (Title is > actually 'IRR Homing project') > If we're clear that a goal is to stop having it, and by implication stop having out-of-region data inserted into the RIPE IRR Thats good!

2 1

Re: [db-wg] re-evaluate route-object authorisation model
by George Michaelson 27 Jun '15

27 Jun '15

> > > > and note that, with one mouth, job has said that the ripe irr is the > > only one he will trust. > > Unsure if i follow you exactly, but indeed, I only trust the RIPE IRR > when it comes to RIPE managed space. > Why then, do you expect anyone to trust RIPE IRR for all the un-RIPE managed space which can be freely added, to permit RIPE managed space related objects to be made? Surely from a consistency point of view (and yes, its reductionist, but so is software) this means we shouldn't be trusting all the additional objects added 'for your convenience' under the open password maintainer? -G > > Kind regards, > > Job > >

2 1

Re: [db-wg] re-evaluate route-object authorisation model
by snash 26 Jun '15

26 Jun '15

Job Responding to the Questions in your 13 May email, thanks for helping me get up to speed. | - should the authorisation model work differently for RIPE managed | space versus non-RIPE managed space? Should we even continue to | allow route-objects covering non-RIPE managed space? No. Authorisation for an AS to originate a route needs to come from the maintainer of the address space. If the address space is assigned by a different RIR then Creating a Route Object in RIPE should be disallowed. Legacy v4 may need special case, I do not know. However, a global routing information database will need to contain copies of information from other regions, but it would support no modification of the copied records. Mirror only. | - should the authorisation model work differently when creating a | route-object for RIPE managed space with a non-RIPE managed | autnum? If yes, how so? No. We should follow the more recent thinking behind RPKI: "the design of the rpki is that an address resource holder is the sole authority over what ASs may announce that resource", Randy Bush | - although in this idea the autnum owner is no longer required to | approve /creation/ of a route-object, would it be a good idea to | allow the autnum owner to /delete/ any route-object in which their | autnum is referenced as origin? I see no need, since the AS still has the choice whether or not to announce the route. The database grants authority, not compulsion, to announce. | - Is RFC 2725 the only reason why the authorisation model was | implemented as it was implemented, can someone remember practical | reasons for doing it this way? During the BoF it was pointed out | that any potential DoS vector already exists today. Wilfried Woeber's concerns in 2006 seem largely to be about accreditation and authority of what is now the inetnum maintainer. Those concerns may still be valid, and may need addressing, but are not directly related to this discussion. The worst examples of IRR seem to have many exploitable faults independently of this. Our objective is to inspire confidence in RIPE's routing database for use in routing policy, to facilitate the completeness of the routing database by reducing a hindrance to maintaining its correctness, whilst retaining the higher standards adopted in RIPE. Steve Nash

4 5

Re: [db-wg] Temporary origins
by George Michaelson 25 Jun '15

25 Jun '15

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. -George On 25 June 2015 at 21:24, Gert Doering <gert(a)space.net> wrote: > Hi, > > On Thu, Jun 25, 2015 at 09:17:12PM +0200, Havard Eidnes wrote: > > Think of the "route" objects in the IRR as "these may be > > announced", not "these *are* being announced", and in a > > transition phase for a prefix (re-homing to another ISP), two > > route objects for the same route will be required. > > ... and there is nothing wrong with that. > > Just to spell it out again very explicitely. > > gert > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >

2 1

Temporary origins
by snash 25 Jun '15

25 Jun '15

At RIPE70, in the DB Workgroup and the Cross Region BoF, there was some discussion of authority to originate a route. There was indication of one major operator's intent to look to the RIPE IRR for validation of OriginAS. In addition to Cross Regional concerns about the correctness and authority to originate, there was also a need to support temporary redirection (change of originAS) mentioned. Temporary redirection is often accomplished by BGP announcement. There was some discussion of the ownership of address-blocks by an AS. RPKI has answered these in ways that are not universally adopted, but do place the authority to originate (ROA) in the responsibility of the "prefix holder" (4), not an AS with which it might normally be associated. rfc 2725 also says, in section 9.4 route objects: "There is a legitimate reason to be in more than one origin AS." I propose that we aim to validate that the IRR database model is consistent with the RPKI model in requiring the authority of the maintainer of the inetnum to originate a route. However RIPE current documentation opposes this, "authorisation for creation of route(6) objects can and must be provided by both the address space holder and the holder of the AS number" (5) . We need to allow for more than one AS to be authorised to announce an origin for a prefix, even though we expect only one originator to announce normally. Multiple Origin AS (MOAS) conflicts occur today and do not appear to cause problems in their own right, as discussed in reference (1). Indeed the motivation for this discussion was to create policy for selecting routes in MOAS cases. I would like to propose for discussion that a basic set of objectives might be: 1. An inetnum is globally unique and has a maintainer that is at least unique to each RIR (perhaps legacy address space may show different maintainers in different RIRs); that maintainer has the responsibility to identify which ASNs are entitled to announce an origin for that inetnum, and to register allowed ASNs in the IRR of that RIR. In this way the authentication of the person and their right to make changes stays within the one RIR. It is of no significance whether the ASNs identified are registered in the same RIR, or not. 2. Clarification, if necessary, that more than one route object for a subnet is permitted, where each RO has a different originAS. I have found no prohibition of multiple route objects for the same subnet. If one exists we should review its merit. 2. Each RIR should feed up its IRR to a global 'read-only' IRR. Alternatively each RIR should provide its IRR to all other RIR so that each may maintain an independent global view. Data structures may also need to be adjusted to accommodate more than one authorised originator. 3. The routing announcements actually made by an AS are the responsibility of the AS-maintainer, and that AS-maintainer should be accountable in cases where the AS announces origin for a subnet for which the AS does not have the authority. If this is useful. Notes: a. More than one route object record with different originAS may be appropriate: - where there is multi-homing without BGP or - where organisations make use of BGP redirection for temporary third-party services, like DDoS mitigation b. rfc 1930 (BCP-6) section 7 says: "Generally, a prefix can should belong to only one AS". The first word indicates that there should be allowance for exceptions. The rfc was written at a time when the relationship between AS number and IP block was much more stable than it is today. c. There seems to me to be some ambiguity about route objects and Origin. rfc 2725, section 9.4 route objects (3) says: "There is a legitimate reason to be in more than one origin AS." But route objects have only one origin field. If multiple route objects pointing to exactly the same subnet are allowed then who has the authority to create route objects? I suggest that the authority should reside with the inetnum maintainer. This makes the origin part of a route object rather than an attribute of inetnum. d. An alternative, might be to require (best practice) that temporary route announcements should prepend the ASN of the owner's AS. But this has an impact on the effectiveness of the announcement in the case of hop-count tie-breaks. References: (1) http://www.cs.colostate.edu/~massey/pubs/conf/massey_imw01.pdf An Analysis of BGP Multiple Origin AS (MOAS) Conflicts {Xiaoliang Zhao, Dan Pei, Lan Wang, Dan Massey, Allison Mankin, S. Felix Wu,Lixia Zhang} (2) https://tools.ietf.org/html/rfc1930 BCP-6 (3) https://tools.ietf.org/html/rfc2725#page-12 (4) http://www.potaroo.net/ispcol/2011-07/bgpsec.html {Bush & Huston} (5) https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 http://www.arbornetworks.com/ ________________________

7 7