June 2015 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 16 May '18

16 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

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

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

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

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

Temporary origins
by snash 24 Jun '15

24 Jun '15

Thanks for comments. My interest was to continue the discussion that Job hosted at RIPE70, and to get to some guidelines for those that need to exploit temporary redirection with BGP; whether customers or providers of services. Job, thanks for your observation that "the RIPE database supports this, you can create multiple route-objects covering the same prefix but with different "origin:" values.". Randy states agreement. However, this does conflict with some other Internet documents, like BCP-6. That can only be confusing and may inhibit global consensus. If IETF BCP documents are inaccurate then the RIPE community has some responsibility to point it out. The dual authorisation that RIPE requires on a ROUTE object seems an unnecessary hurdle, and gives rise to the cross-border concern that Job raised in the BoF. The consensus from RPKI seems to be that the inetnum maintainer has the authority to grant ROA. I do not know the history of why RIPE asks for AS maintainer also. Is there still some good reason? (If so, I am puzzled that it does not apply to RPKI, but that is a separate discussion). Removing the AS maintainer from the route object Creation authorisation seems to solve the cross-region problem. Are there reasons not to do this? Job mentioned that RaDB seems to have neither authorisation requirement, so creating a global view of the IRR is challenging without policy agreement leading to trust on these things. Summary: 1/ ask IETF to update BCP-6. Is this something RIPE NCC should do? 2/ discuss why AS maintainer authorisation is required for RIPE ROUTE object Creation. I subsequently read the article by Den Is May 2015, which comments that there is no written policy for IRR. Steve

3 2