May 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

Personalised authorisation
by Tim Bruijnzeels 02 Jun '15

02 Jun '15

Dear working group, Yesterday during the WG session we presented a proposal for implementing personalised authorisation: https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-au… <https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-au…> https://ripe70.ripe.net/archives/video/123 <https://ripe70.ripe.net/archives/video/123> As recorded in the first cut of the minutes: > D. Personalised authentication (Tim Bruijnzeels, RIPE NCC) > (See presentation) > This will allow one click creation of person objects > Maintain credentials in one place. > Allow better auditing. > Done by extending person object to have multiple optional auth: attribute > This will ultimately allow existing auth: sso references to be cleaned up > Last auth: attribute should not be removed from a person object that is used in an authorisation context. Apart from questions about possible additions below, there seemed to be general approval for the above as an addition to the existing maintainer mechanism. We would very much like to implement this soon. We are already working on improving the way users can log in and use the web updates, and manage maintainers (and who is authorised for them), so having this would be extremely useful for that effort. Technically I don't think the above has to depend on further extensions below. Roles can be added at any time that we consensus on them, and showing audit logs is a separate effort - building on this. > Should this be extended to the role object as well? This would involve additional business rules but is technically possible. I understand and fully agree that there is a need to maintain a list of authorised persons centrally. But in effect a maintainer can be used for this purpose. Multiple objects can be maintained by the same maintainer, and the list of persons authorised can then be managed on this single maintainer: obj1 ---\ ---> mnt1 ---> pers1 obj2 ---/ \--> pers2 In other words, just like role objects can group persons in a 'contact' context, 'maintainers' could group persons in a 'authorisation' context, where also other things such as "upd-to:" etc can find a home. So, technically I don't think there is a need to have another role object here: obj1 ---\ ---> mnt1 ---> role1 ---> pers1 obj2 ---/ \--> pers2 Conceptually this can work of course, but it adds some complexity, and things to resolve: a) referencing roles from maintainers, and authorised persons from roles The proposal was to refer to authorised persons from maintainers like this: auth: person-<nichandle> Can we resolve this by allowing: = auth: role-<nichdl> on maintainers = auth: person-<nichdl> on roles But no other auth: flavours for now. Also note that this person is not necessarily an authorisation *contact* for others. If we follow current practice consistently we would filter this value for security purpose. b) business rules regarding auth->role Suggestion: - A role can only be added to a maintainer as "auth: role-<nichdl>" if it has at least one "auth: person-<nichdl>" - The last "auth: person" can not be removed from a role if it's referenced anywhere as "auth: role-" - As before: "auth: person-<nichl>" can only be added if the person has at least one "auth: <something>" - As before: the last "auth:" can not be removed from a person if it's referenced anywhere as "auth: person-" > It would be useful to record what credential (maintainer) was used to make a particular change to an object and this change > would facilitate this. RV was asked to raise this on the mailing list. Currently we do know internally which maintainer was used to submit a successful update, but not which credential. Technically this could be added of course. And in case of SSO or PGP people can get some idea of which user did the update. But showing which password hash was used for an update may not be best security practice. With authorisation delegated to persons (possibly through roles) we will be able to give a much more better output. We can refer to the name of the person, rather than a credential that should be private to that person. Also note that for any of this we will also need to be sure that the user viewing this information is authorised to see this. So what we had in mind here is to show this only on the web interface for logged in users authorised for at least one mnt-by of the object they are looking at.

5 7

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

Re: [db-wg] [routing-wg] RPKI Validator 2.19; export ROAs as RPSL route: objects
by Randy Bush 13 May '15

13 May '15

>> We've been getting a lot of requests to make processed RPKI data >> easily available in existing (RPSL based) workflows. This is why we >> added the ability to export all ROAs as route: objects in the latest >> release, version 2.19. Practically, this means that running an RPSL >> export will give you almost 450,000 highly reliable, cryptographically >> validated route: objects. > Interesting! I was considering writing a script to do this, but the NCC > beat me to it! :-) drl wrote the script and has made the data available for years > Wouldn't it make sense to align the "created:" date with something > more specific to the ROA rather then the export date? yes > Another consideration might be to create a "expiry-date:" derived from > the ROA's expiry date for easy debugging purposes. use a remark: randy

1 0

Cross-RIR route object registration
by snash 13 May '15

13 May '15

In considering the verification of Route Object ownership for route acceptance policies, please consider organisations which implement temporary BGP announcements for traffic diversion for uses like DDoS Mitigation. The AS may be registered with an RIR which is not the same as the RIR of the Route Object. Plus there must continue to be a means to have more than one entity pre-authorised to announce any particular Route Object, or subnet thereof. Regards Steve ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com ________________________ Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 0

Cross registry authentication BOF - rough notes
by Nigel Titley 13 May '15

13 May '15

Please find the rough notes that I took during this BOF attached Nigel

3 2

Minutes of DB-WG for the RIPE 69 meeting
by Nigel Titley 11 May '15

11 May '15

Folks I'm a bit late in sending these minutes out, for which I apologise. Please rapidly get any comments back to me. Thanks Nigel

1 0

[training] RIPE NCC Training Courses July-September 2015
by Training Services 11 May '15

11 May '15

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Frankfurt, London, Skopje, Stockholm, Minsk, Sarajevo, Vladivostok, Tel Aviv, Tallinn, Zurich, Paris, Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course - Basic IPv6 Training Course - 2 day Advanced Training Course - Routing Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Proposal to clean up historical "abuse-mailbox:" attributes
by denis 09 May '15

09 May '15

2 4

[training] RIPE NCC Training Courses July-September 2015
by Training Services 08 May '15

08 May '15

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Frankfurt, London, Skopje, Stockholm, Minsk, Sarajevo, Vladivostok, Tel Aviv, Tallinn, Zurich, Paris, Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course - Basic IPv6 Training Course - 2 day Advanced Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Re: [db-wg] db-wg Digest, Vol 44, Issue 7
by denis walker 08 May '15

08 May '15

Hi Piotr Just to be clear, you refer to free text attributes. This has a specific meaning in terms of database syntax checks. It applies to those attributes where no syntax checks are done, for example "address:", "descr:", "remarks:". Is your proposal only referring to these attributes? I trust you do not mean all attributes other than primary keys. Incidentally, although "person:", "role:" and "org-name:" are not primary keys, they are not free text either. Currently there are syntax checks done on these values. If you allow these in UTF8 then all these syntax checks will have to be dropped. cheersdenisindependent netizen Date: Fri, 17 Apr 2015 12:18:04 +0200 From: Piotr Strzyzewski <Piotr.Strzyzewski(a)polsl.pl> To: db-wg(a)ripe.net Subject: [db-wg] Proposal to allow UTF8 Message-ID: <20150417101804.GD7031(a)hydra.ck.polsl.pl> Content-Type: text/plain; charset=utf-8 Dear DB-WG Members Proposal: I propose to allow UTF8 in all free text attributes of all DB objects except in primary keys. Description: RIPE NCC service region covers Europe, the Middle East and parts of Central Asia. Moreover we have users from outside of this region. This means that WHOIS DB stores data for people and organizations from number of different countries using number of different alphabets. At this moment, all data in the RIPE WHOIS DB have to be stored using 7-bit plain US ASCII character set. [As a side note: It is technically possible to store some UTF8 content in some attributes, but the answer to whois query (both terminal and web based) returns "?" character in this case.] Lack of the full support for national character sets leads to some problems which includes, but is not limited to: 1. Mistakes in person/organization names due to national->english and english->national (based mostly on guess) conversion. 2. Mistakes in person/organization address due to national->english and english->national (based mostly on guess) conversion. 3. Conflict of converted words with other correct words (most visible in latin-based character sets). 4. Possible offensive word formation due to national->english conversion of names and/or addresses of person/organization. [As a side note to points no 1-3: This could lead to some problems when LEA tries to find out precisely who should be contacted in case of abuse.] On the other side, community members needs to know who is responsible for certain resource without the necessity of understanding all the others character sets. Moreover, some objects are filled with data that has to be provided in ASCII character set due to business rules (like ORGANISATION object details for LIRs). RIPE NCC has a policy to insist on latin based names for organisation objects that it verifies (allocated, and sponsored end-user space). Taking this into accout I propose to allow UTF8 in all free text attributes of all DB objects except in primary keys. Some possible issues to be addressed: 1. When this proposal will be supported by the DB-WG, then it has to be discussed at least with AA-WG and AP-WG. 2. UTF8 may cause problems for client code. Comment: The proper implementation plan and announcements schedule should be prepared. 3. UTF8 may result in contact addresses and names that are not readable by a large part of the community. Comment: Primary keys (mostly names) still have to be in ASCII character set. Moreover, LIRs data are also in ASCII character set due to business rules. 4. At this moment there are no major technical issues blocking UTF8 support in the RIPE DB back-end. However thorough checks have to be done. Looking for your comments. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski(a)polsl.pl

4 7

Database release 1.79 deployed to RC environment
by Tim Bruijnzeels 07 May '15

07 May '15

Dear colleagues, The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.79 to the Release Candidate (RC) environment: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… <https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir…> This release introduces the new attributes "created:" and "last-modified:" as part of the first phase of the deprecating the changed attribute in the RIPE Database. You can find more information about the three phases of this effort here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… <https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-…> It should be noted however that: = The new attributes will only be enabled in output this Thursday 2 April (because updating all objects with initial values takes a long time) = We have found that we needed to use the 1970-01-01T00:00:00Z instead of 0000-00-00T00:00:00Z (because it's invalid, and we observed inconsistencies in dealing with year 0 AD different libraries) We will update the referenced article shortly to reflect these changes. This release also changes attribute "referral-by" from mandatory to optional. This attribute is part of a mntner object for historical reasons and will be deprecated. Detailed release notes are published here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79 <https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79> Documentation for this release is published here: https://www.ripe.net/data-tools/support/documentation/ripe-database-documen… <https://www.ripe.net/data-tools/support/documentation/ripe-database-documen…> Please let us know if you find any issues with this release. We plan to deploy this release to the production environment on Tuesday 28 April, and we plan to enable the new "created:" and "last-modified:" attributes the following Monday 4 May - after the initial values have been added for all objects. Please let us know if you have any questions or comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

5 12

Re: [db-wg] Proposal regarding Orphaned Objects
by denis walker 07 May '15

07 May '15

HI Shane is correct. This functionality already exists and allows resource holders of resources allocated or assigned by the RIPE NCC to delete any operational object within their address space. Note that this functionality does not apply to any objects containing personal or contact details. Also it only applies to resource objects where the RIPE NCC has a contractual relationship with the resource holder (or their sponsoring organisation) for that resource. Just to add a caveat regarding orphaned objects, just because an object has not been updated in a very long time does not make it orphaned, even if the original maintainers are unresponsive. cheersdenisindependent netizen Date: Fri, 1 May 2015 09:02:23 +0000 From: Shane Kerr <shane(a)time-travellers.org> To: William Sylvester <william.sylvester(a)addrex.net> Cc: db-wg(a)ripe.net Subject: Re: [db-wg] Proposal regarding Orphaned Objects Message-ID: <20150501090223.0427845f(a)vulcan.home.time-travellers.org> Content-Type: text/plain; charset=US-ASCII William, On Tue, 28 Apr 2015 14:32:33 -0400 William Sylvester <william.sylvester(a)addrex.net> wrote: > Currently, when a number block holder wishes to update their number > block they are unable to do so directly. They must contact the > maintainer of the old object. Many of the older maintainers do not > have current contact or have been acquired by another company and > left in an unknown orphaned status. These maintainers can be > difficult or impossible to contact. RIPE NCC then must be engaged to > make the change to an object the number block holder should have had > online access to manage directly in the first place. As I understand it, the database allows the maintainer of less-specific ("parent") inetnum or inet6num objects to delete more-specific ("child") objects. So, the recipient of either an allocation or assignment from the RIPE NCC already has the power to clean up their space. I believe this sort of delete functionality also applies to route and related domain (meaning reverse DNS) objects. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… As I understand it, your proposal has already been implemented, with the difference that maintainers can only delete, not modify objects that they do not directly maintain but are in their space. Cheers, -- Shane End of db-wg Digest, Vol 45, Issue 1 ************************************

7 15

public password issues
by denis walker 04 May '15

04 May '15

Hi All There was a lot of talk about the MNTNER with a public password during the last RIPE Meeting. Everyone agreed that something needs to be done, but there has been little discussion since. I have written an article on RIPE Labs summarising a few of the issues and added some thoughts about them. I hope it will be useful for the discussions at RIPE 70. https://labs.ripe.net/Members/den_is/security-and-trust-in-the-internet-rou… cheersDenis WalkerIndependent Netizen

1 0

Proposal regarding Orphaned Objects
by William Sylvester 01 May '15

01 May '15

Dear Database Working Group Members, There are many old records that have become orphaned. Examples of orphaned objects might include a routing or reverse dns object that exist in the database but are not currently maintained by an active maintainer. Many of these records have not been updated in a very long time. This proposal intends to enable number block holders to have a greater ability to manage their own resources. Currently, when a number block holder wishes to update their number block they are unable to do so directly. They must contact the maintainer of the old object. Many of the older maintainers do not have current contact or have been acquired by another company and left in an unknown orphaned status. These maintainers can be difficult or impossible to contact. RIPE NCC then must be engaged to make the change to an object the number block holder should have had online access to manage directly in the first place. I propose that the maintainer of a number block shall have full control over the contacts, routing, and reverse dns entries related to the number block held. In the event an object currently has a maintainer different than the holder of the number block the maintainer of the number block will be provided an upper maintainer status with rights to manage or delete associated blocks. The number block maintainer will have an ability to delete a related object through the LIR Portal, Webupdates, and related systems. At the inception of this policy the database should be updated to identify objects without a maintainer chain to the number block holder. Any identified objects should have the maintainer of the number block added as an upper maintainer to the related blocks. When a maintainer is removed from the number block, this maintainer should also be removed as an upper maintainer of the object this should work in a similar fashion when a maintainer is added to the number block. The upper maintainer will have an ability to remove the relationship between a number block and associated contacts, routing, and reverse dns objects. Open items to discuss; 1) What is the best mechanism to enable the association of existing objects and does it make sense to have the inetnum object be the central object? 2) What objects should be included? Should any be excluded? 3) What is the right hierarchy for the objects? 4) What is a reasonable schedule for announcements and implementation? Thank you for your consideration and I look forward to your comments. Billy William Sylvester william.sylvester(a)addrex.net <mailto:william.sylvester@addrex.net>

2 2