- db-wg - mailman.ripe.net

Database release 1.80 deployed to RC environment
by Alex Band 01 Jun '15

01 Jun '15

Dear colleagues, We are happy to announce the deployment of RIPE Database software release 1.80 to the Release Candidate (RC) environment. This release contains quite significant changes to long-standing RIPE Database functionality. This is why we urge you to thoroughly test your tools and scripts against the RC environment to make sure nothing in your workflow breaks: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… 1. This release continues to gradually phase out the "changed" attribute. We're now in phase 2, where the attribute is marked as optional. For details on this functionality change, please refer to the implementation plan: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… 2. Also according to plan, the "referral-by" attribute has now been completely removed. It is no longer mandatory when creating or updating maintainers. We will perform a data cleanup following the release, to remove this attribute from current maintainer objects. Documentation for this release is published here: https://www.ripe.net/data-tools/support/documentation/ripe-database-documen… Please contact us if you find any issues with this release, or in case you have any questions or comments. We plan to deploy this release to the production environment on Monday, 13 July. Kind regards, Alex Band Product Manager (standing in for Tim, who is enjoying being a proud father)

1 0

abuse-c on legacy resources
by denis walker 29 May '15

29 May '15

Hi Piotr During the RIPE Meeting you suggested the idea of legacy resource holders adopting the practice of referencing an abuse contact using the one accepted method currently in use in the RIPE Database with "abuse-c:". In terms of responsible management of internet resources I don't think anyone could argue against all resources documented in the RIPE Database making reference to an abuse contact via an ORGANISATION object showing who is responsible for a resource. Many ideas raised at RIPE Meetings are quickly forgotten after the meeting. How can we move this idea forward so it does not become another of those 'good idea, but never implemented'? cheersDenisIndependent Netizen

3 5

History lost ...
by Erik Bais 21 May '15

21 May '15

Hi, With the IP transfers going in full swing, it is quite common these days that the larger prefix size is broken up in to multiple smaller prefixes.. As the original prefix is split up, the IPRAs remove the original prefix from the database .. and with it .. the history Is there a way to preserve that data to be able to still lookup the data using list-versions or show-version # Regards, Erik Bais

13 24

Prevent use of RIPE-NCC-RPSL-MNT in a mnt-by
by denis 18 May '15

18 May '15

6 6

created, last-modified mandatory?
by Daniel Zepeda 15 May '15

15 May '15

It wasn't clear to me from the provided documentation here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… if or when the 'created' and 'last-modified' attributes would be mandatory? Thanks! DZ

1 1

Cancel
by Luciano Panza 15 May '15

15 May '15

1 0

Minutes from RIPE 70
by Nigel Titley 14 May '15

14 May '15

Folks Here is the first cut at the minutes. Additions and corrections to me, please Nigel

1 0

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

14 May '15

I am from out of region, and I do not maintain data in the RIPE DB with a view to configuring routing, or to have my prefix originated. I am associated with an agency (another RIR) which is not able to be fully represented inside RIPE DB for logistical reasons but instead operates as an autonomous, un-related space of IRR/WHOIS in the same format (RPSL). Users of that service have come to expect that they can lodge IRR data inside my service, in respect of their prefixes. This seems reasonable. And so we enter the problem of 'which DB, which resources, which region, which authorization, why, how' I too prefer, that for route: objects, we move to an acceptance that the ASN holder is not materially bound to announce simply because there is a route object, the ASN holder is not inherently attacked because they were not asked, and instead we should be accepting the INFORMATION that a route object asserts, first class from SIGNED DATA in a ROA. (sorry for shouting) I understand there is a hypothetical risk that FILTER OWNERS are spammed into a ddos wall of death from the creation of huge numbers of route: objects not referring to them. But, this is not significantly different in my mind, to the risk that I take a valid /32 in IPv6, which I have in eg RIPE and then use the public maintainer to add 2^32-1 sub instances of data which refer to any ASN outside of RIPE, thus killing the entire WHOIS anyway for anyone. Not a hypothetical attack. Its a real one. And, by virtue of the maintainer, it exists now. I believe that transitionally, moving to prevent the out-of-region AS thing in RIPE will impact around 350-400 people who currently assert route: objects depending on this. I believe that is a tractable problem. I believe the addition of a tool to emit route: objects from RIPE RPKI Validator, and possibly the dragon s/w makes this a moot point, because those prefix holders can create objects in RPKI which replace that function, trivially. If the RIPE S/W is modified to stop needing ASN to approve route objects, then users in my region using my WHOIS will be able to create route: objects, while we work on persuading them to create ROA instead. I know APNIC Helpdesk staff would like to be able to stop recommending use of un-secured IRR, and having to mediate the conversation between ASN and INetnum maintainer by hand. They wish to ask if this can be considered as an operational problem. -George On 14 May 2015 at 11:47, Randy Bush <randy(a)psg.com> wrote: >>> some folk at euro ixen require route objects in ripe's irr. some >>> folk who get address space from other rirs appear at those euro ixen >>> and wish to peer. >> >> ixps which build route server configurations using ixp manager can >> apply arbitrary IRR source tags (or combinations) on a per-customer >> basis. > > yes, and peval() and other tools take an IRR instance list. but i have > enough windmills without tilting at this one. you wanna peer with > brunhilde, you play by her rules. > > when i saddle up rosenantes, it is to get all this to be rpki-based > origin validation instead. > > randy >

1 0

RIPE 70 DB-WG agenda V3
by Piotr Strzyzewski 14 May '15

14 May '15

Dear DB-WG Members This is the 3rd draft of an agenda for the DB-WG Meeting at RIPE70 at the Hotel Okura in Amsterdam, Netherlands. This version includes new proposal made by Denis Walker. The DB-WG Meeting is scheduled as usual for Thursday, May 14th, starting at 16:00 local time, after the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 70 meeting plan please refer to its most up-to-date version at https://ripe70.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Amsterdam. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. Data Base Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~20 min] (proposed, test, deployment) . referral-by deprecation - where are we now? - what are next steps (timeline) . from "changed:" to "last-modified:" / "created:" - where are we now? - what are next steps (timeline) . RIPE NCC to stop enforcing accurate organisation names in "descr:" attribute . restrict usage of RIPE-NCC-RPSL-MNT . new MNTNER - RIPE-NCC-LEGACY-MNT . other aspects D. Personalised authentication (Tim Bruijnzeels, RIPE NCC) [~10 min] E. New proposals (Piotr Strzyżewski) [~10 min] . UTF-8 in the DB . same INET(6)NUM objects with different status . cleanup some hacks with status values . make phone number optional in person objects . clean up historical "abuse-mailbox:" attributes F. Orphaned Objects (William Sylvester) [~5 min] G. Using RPKI for signing RPSL objects (Robert Kisteleki, RIPE NCC) [~5 min] H. "source: field for non RIPE address space" (Job Snijders) [~10 min] I. continue promotion of the the new Afrinic RR (Job Snijders) [~5 min] Y. Input from other Working Groups and/or Task Forces . Cross-registry Authentication for IRR Data BoF (Job Snijders) [~10 min] Z. AOB __________________________________________ -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

re-evaluate route-object authorisation model
by Job Snijders 14 May '15

14 May '15

Dear working group, Yesterday during the birds of a feather session about "cross-registry authorisation" the idea to relax the authorisation requirements for route-object creation was brought up (again). I ask this group to further explore. Today, to create a route-object, BOTH the inetnum mntner, and the autnum mntner need to approve the creation of the route-object. One could argue that it is sufficient to require only authorisation from the inetnum owner to create a route-object. This would simplify the process, especially if the autnum is managed in a non-RIPE RIR. No longer would ARIN autnum owners be required to create a superfluous autnum object in the RIPE database. Questions: - 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? - 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? - 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? - 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. - ... ? Kind regards, Job

7 9