- db-wg - mailman.ripe.net

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