May 2016 - db-wg - mailman.ripe.net

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

17 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

WG Chairs Selection
by Piotr Strzyzewski 16 Nov '16

16 Nov '16

Dear DB-WG Members As agreed during DB-WG session at RIPE69 Meeting in London on 06.11.2014, the WG Chair Selection procedure is executed at yearly intervals. This means that it is about time to run it for the very first time. This is the call for interested parties. Interested parties have 2 weeks to make their interest known on this mailing list. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. After two weeks the chairs will declare consensus. Since there is a limit of 3 co-chairs, if at the end of the discussion phase there will be more than 3 proposed co-chairs then a call will be made for any of the candidates to withdraw. If there still will be more than 3 candidates then names will be put into a hat and the first three names drawn from the hat will take on the role of chairs for the next 12 months. All three of present co-chairs expressed their interest in being co-chairs for another term. All the best, Job, Nigel & Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

9 11

Locking unmaintained PERSON and ROLE objects in the RIPE Database
by Trudy Prins 02 Sep '16

02 Sep '16

Dear colleagues, The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal with a vulnerability for RIPE Database users. Following their advice, the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016. Since reaching the last /8, IPv4 address space has become more susceptible to hijacking. Unmaintained PERSON and ROLE objects are highly at risk of being found and hijacked. In addition, unmaintained PERSON and ROLE objects are an issue with regards to data protection obligations. The potential impact of abuse led us to consult with the EB on this intermediary solution before engaging with the community on the next steps. Exposing this issue without taking adequate measures would have left the RIPE NCC liable to third party damages. The proposed solution we outline below is a starting point, to be discussed by the community. Background: =========== Since 2010 it has been mandatory to protect PERSON and ROLE objects in the RIPE Database using a maintainer on "mnt-by:". A large number of PERSON and ROLE objects dating from before 2010 are still not protected in this way. Objects can be created that reference these unmaintained objects, but doing so will generate a warning. In recent years, given the scarcity of IPv4 address space, there is a higher risk of people searching for unmaintained PERSON or ROLE objects in order to pose as a resource holder to sell IPv4 space. In the case of legacy space, this could take place outside the view of the RIPE NCC if the address space is not registered with the RIPE NCC. Proposal: ========= 1) All unmaintained ROLE and PERSON objects are now locked. As the RIPE NCC will not be able to correctly check all claims on unmaintained database objects, unlocking is not available. Offering to unlock these objects could leave the RIPE NCC liable to third party damages if due diligence is not followed. 2) Furthermore, the RIPE NCC modifies the existing warning about referencing unmaintained persons/roles to a similar warning about referencing locked persons/roles. 3a) The locked objects can remain as they are. In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted: the current thinking is a 180-day deletion timeout for these locked, unreferenced objects. 3b) If there is an operational need, new PERSON or ROLE objects should be created by the object owners. This solution puts control back into the hands of the object owners. The user can follow the existing process for creating and referencing new objects. If there is a use case for supporting bulk migrations where a reference to a locked PERSON or ROLE object should be replaced, the RIPE NCC can create a wizard in the RIPE Database webupdates section of www.ripe.net <http://www.ripe.net/>. We look forward to your feedback. Kind regards, Trudy Prins Manager Software Engineering RIPE NCC

13 24

NWI-3 - AFRINIC IRR Homing
by Job Snijders 16 Aug '16

16 Aug '16

Dear Working Group, (You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.) NWI-3 - Afrinic IRR Homing -------- In recent years Afrinic set up an IRR instance that enforces authorisation for ROUTE(6) objects at rr.afrinic.net And while the general problem of out-of-region ROUTE(6) and AUT-NUM objects in the RIPE Database IRR, and the problem where the prefix and the ASN belong to different regions is not trivial to resolve, there seems to be a general consensus that simple cases where ROUTE(6) objects have both an ASN and prefix in Afrinic (~34k objects), should appear in the Afrinic IRR where authorisation can be done and not in the RIPE DB. Complicated cases where the prefix is in Afrinic, but the ASN is another region -or- where the ASN in Afrinic, but the prefix is out of region are out of scope for this NWI. -------- Some of you might wonder why this topic is back on the table. The chairs felt that it would be most appropiate to follow our new NWI formal process to help progress this work. Working group participants, if you agree/disagree with the above problem statement please voice your opinion. If you have suggestions to refine the text that is welcome too. Kind regards, Job

12 28

NWI-5 - Out of region ROUTE(6) / AUT-NUM objects
by Job Snijders 28 Jul '16

28 Jul '16

Dear Working Group, This is a slighly longer problem statement, please bear with us. There has been a LOT of discussion about the problems related to out-of-region ROUTE(6) and AUT-NUM objects in the RIPE Database. We would like to provide a starting point of the problem definition here, and ask the community to discuss it further. NWI-5 - Out of region ROUTE(6) / AUT-NUM objects ---------- The RIPE Database Internet Routing Registry (IRR) requires authorisation to create ROUTE(6) objects, by the appropriate maintainer for the covering inet(6)num object - or an existing covering ROUTE(6) object for the prefix in the "route(6):" attribute, as well as the appropriate maintainer for aut-num object matching the "origin:". For resources within the RIPE region this authorisation is covered by either: * Objects that RIPE NCC creates upon assigning or allocating resources to LIRs or end-users with a sponsoring LIR * Objects held by legacy resource holders (authorisation may be delegated to others by holders of these objects) However for out-of-region space the authorisation is different. Because out-of-region resources are not maintained in the RIPE Database there are no proper maintainers in the RIPE Database to authorise the creation of such objects. Because there is a need for having ROUTE(6) objects for these routes, and there were no authoritative alternative IRRs available, the RIPE community decided to support the creation of these objects in the RIPE Database IRR through the use of placeholder objects for out-of-region IP resources and ASNs. In case of IP resources the INET(6)NUM objects delegate authorisation to create route objects through "mnt-routes:" to a special use maintainer with a well-known password: RIPE-NCC-RPSL-MNT. In case of out-of-region ASNs the RIPE NCC maintains placeholder AS-BLOCK objects. Since "mnt-routes:" does not exist on AS-BLOCK objects the RIPE-NCC-RPSL-MNT is added to "mnt-lower:" here instead. Any user of the database can therefore create a AUT-NUM object for an out-of-region ASN, and use it to authorise ROUTE(6) objects. There are a number of problems resulting from this approach: * Authorisation for out-of-region objects is anecdotal * Globally duplicate AUT-NUM objects are required for out-of-region ASNs, confusing contact information, policy etc * This facilitates hijacking for out-of-region resources and RIPE NCC is neither mandated nor staffed to deal with these issues. * Detailed placeholders need to be maintained, which causes overhead especially w.r.t. inter-RIR transfers --------- We invite the working group to better define this problem definition so that a structured discussion about (partial) solutions can follow. Kind regards, Job

3 2

NWI-2 - displaying history for DB objects where available
by Job Snijders 12 Jul '16

12 Jul '16

Dear Working Group, This is the second Numbered Work Item. (You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.) --------- NWI-2: The RIPE NCC was tasked with the following action point: AP69.2 [RIPE NCC] Come up with some straw man proposals for displaying history for objects where available. The RIPE Database already provides a mechanism for object history. In our understanding the problem statement that motivated the action point is that some people are interested in seeing the history of *deleted* objects. It is our understanding that this interest is mainly focussed on primary (resource) objects. However, it is not entirely clear to the RIPE NCC why this is useful. We also have some concerns, mainly non-technical, and therefore we believe that the problem statement and motivation needs to be better defined in the working group. --------- The next step is to help refine the problem statement. I would appreciate it if working group participants with an interest in the history of objects speak up and elaborate on the issue. Kind regards, Job

7 9

NWI-4 - role of status: field in multivalued status context
by Job Snijders 27 Jun '16

27 Jun '16

Dear Working Group, (You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.) NWI-4 --------- The RIPE NCC was tasked with the following action point: AP70.2 [RIPE NCC] Come up with a proposal for the status: field to fix the requirement that certain objects may need multivalued status. Some believe that the main underlying issue here is that it is currently not possible to create an assignment that is the same size as an allocation in the RIPE Database. And resource holders are of course supposed to create an assignment for the address space in an allocation that is in use, by address policy. The main reason for this limitation is that the INET(6)NUM attribute is a primary key. There is a work-around for this problem. Instead of creating an assignment of the same size it's possible to create two smaller assignments instead. In our (red: RIPE NCC) experience this work-around has always been accepted. Still if the allocation is used as a whole, having a single assignment for the whole block is a more accurate reflection of reality, and it reduces the amount of objects to maintain. ---------- The AP70.2 action point refers to a suggest solution, following earlier discussion. But the chairs believe it would be good to bring this back to a clear problem statement first, and then suggest different solutions and their respective benefits and/or problems. Furthermore address-policy wg policies mention the different statuses and what the different statusses reflect. Therefore we'll need to inform the address policy working group as well. If you agree or disagree with this problem statement, please indicate your opinion on this mailinglist. Refinements to the text are welcome too. Kind regards, Job

3 3

NWI-1 - staying on top of abuse contact changes
by Job Snijders 27 Jun '16

27 Jun '16

Dear WG, This is our first Numbered Work Item! We are now in phase 1. (You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.) The following preliminary problem statement has been put forth by Denis & Piotr: "The resource holder could be unaware of changes made to the abuse contact details for his/her resources. This could happen as a result of any addition, change or deletion of any part of the abuse contact details put in his/her ORGANISATION object ("abuse-c: attribute, referenced ROLE object, "abuse-mailbox:" attribute)." I ask the working group whether they agree with this problem statement, they can identify with the problem, whether the statement needs amendments. Kind regards, Job

3 3

Faked entries in the RIPE db
by Dickinson, Ian 02 Jun '16

02 Jun '16

There appears to be abuse happening in the RIPE db - presumably to allow other online activity to be done with abuse indirection to an innocent bystander (e.g. my employer) - all over the last day or two... The specific items I noticed are all inet6num maintained by BSKYB-BROADBAND44-MNT, along with BSKYB-BROADBAND44-MNT itself, and ORG-BBH4-RIPE and ACRO772-RIPE This was due to the fake objects referring to our real role/person objects. It appears that there are many other faked entries under 2a07:7ec0::/29 - pretending to be Deutsche Telekom or Time Warner Cable for example. Either that LIR is a bad actor, or their maintainer credentials have been 0wned. This needs to be killed off. Cheers, -- Ian Dickinson Network Architect Sky Network Services ian.dickinson(a)sky.uk Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

3 4

Deployed 1.87.1 to RC - supporting business rules that allow phasing out object editors
by Tim Bruijnzeels 27 May '16

27 May '16

Dear working group, We deployed release 1.87.1* to RC today. This new Database release introduces several business rules that allow us to phase out object editors for LIRs in the near future. As announced by Alex Band to the services working group on 21 April: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2016-April/002999.h… Since this release does not introduce any other functional changes, we believe that a one week RC test period should be enough. And we propose to deploy this release to production next Wednesday 11 May, unless of course issues are found or concerns are raised. The new business rules ensure that once an LIR maintainer is added to "mnt-by:" of an LIR ORGANISATION object and/or INET(6)NUM objects for LIR allocations, attributes that are maintained by RIPE NCC remain maintainable by RIPE NCC only. For organisation objects the following attributes will not be modifiable by the LIR: "organisation:"**, "org-name:", "org-type:", "address:" ***, "phone:" ***, "fax-no:" ***, "email:" ***, "mnt-by:" **** For inet(6)num objects the following attributes will not be modifiable by the LIR: "inetnum:"**, "netname:", "org:", "sponsoring-org:" (on assignments, included here for completeness), "status:", "mnt-by:" **** Please note that these changes only come into real effect after we deploy changes to the LIR Portal that allow LIRs to select a maintainer to use. We are working hard on this at this moment, but we are not sure whether we can have these changes ready before the RIPE Meeting, or that we will have to wait a bit longer. Of course we will communicate how this changes the way that LIRs can maintain their objects before that time. Please let us know if you find any issues or have any concerns or questions, Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group *: Note that we caught a small issue internally before we planned to deploy 1.87, hence the version currently deployed is 1.87.1. **: primary key, so not modifiable - included here to make it clear that these objects are created by RIPE NCC ***: These fields will remain modifiable through the LIR Portal only for now, since they are stored both in the RIPE NCC internal member database and the RIPE Database ****: During the first phase of this effort the LIR can only choose one MNTNER to use, through the LIR Portal

2 2