- db-wg - mailman.ripe.net

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 27 Jun '15

27 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