- db-wg - mailman.ripe.net

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

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

Personalised authorisation
by Sascha Luck [ml] 19 Jun '15

19 Jun '15

Hi Alex, > Our current proposal allows authorisation on person objects for > those who want it, through maintainer objects Does this mean that calling a maintained object will spit out a reference to a mntner: object which will spit out a ton of references to person: objects which are authorised to make changes on the original object? rgds, Sascha Luck

2 2

[training] RIPE NCC Webinars - new dates
by Training Services 18 Jun '15

18 Jun '15

Dear colleagues, We are pleased to announce the dates for the RIPE NCC Webinars for the coming quarter. These interactive on-line learning sessions take about one hour, and give you the opportunity to learn and interact with our trainers without leaving your desk. In the next 3 months you can participate in the following Webinars: - Advanced RIPE Atlas Usage (NEW!) - Introduction to the RIPE Database - RIPE Database - Advanced Topics - IPv6 in the RIPE Database - IPv6 Addressing Plan - Webinar for New LIRs - Resource Certification (RPKI) Register now at https://www.ripe.net/support/training/learn-online/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have any questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
by Sascha Luck [ml] 17 Jun '15

17 Jun '15

Sorry for breaking the thread already, wasn't subscribed to this before. IMO there is a lot of work to be done before deprecating passwords. Right now this seems more than a little half-baked: 1) There should most definitely be SSO support for syncupdates. Webupdates, I'm sure, is fine for some but to me it's the most awkward and time-consuming way to make any db change. As far as email is concerned, deprecate that for all I care. I have never used that method in 15 years. 2) There are many issues with using PGP. As someone who makes DB changes for up to 5 LIRs at a time and who does not have a desk with a PC from which all work is done, what am I supposed to do? (On a side note, SSO has made that job so very much easier. If it can be used to authenticate mntners, by all means, please make that possible!) -Use the same privkey for all mntners? Hardly. -put all the privkeys on a USB stick? What if that is lost or stolen? All mntners are now compromised and have to be changed. Hopefully there is a copy of each privkey in some secure location... So, I wouldn't deprecate passwords until there is another option that is as flexible as a simple password. rgds, Sascha Luck

1 0

Re: [db-wg] Publishing Deleted Objects - Legal Analysis
by Athina Fragkouli 12 Jun '15

12 Jun '15

Dear Bengt and all, The purpose of the RIPE Database is defined in Article 3 of the RIPE Database Terms and Conditions: ------------------ Article 3 - Purpose of the RIPE Database The RIPE Database contains information for the following purposes: - Ensuring the uniqueness of Internet number resource usage through registration of information related to the resources and Registrants - Publishing routing policies by network operators (IRR) - Facilitating coordination between network operators (network problem resolution, outage notification etc.) - Provisioning of Reverse Domain Name System (DNS) and ENUM delegations - Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information. - Scientific research into network operations and topology - Providing information to parties involved in disputes over Internet number resource registrations to parties who are authorised under the law to receive such information. ------------------- The RIPE Database Terms and Conditions can be found here: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms Kind regards, Athina Fragkouli Legal Counsel RIPE NCC > From: Bengt Gördén <bengan(a)resilans.se> > Subject: Re: [db-wg] Publishing Deleted Objects - Legal Analysis > Date: 9 Jun 2015 17:12:02 GMT+2 > To: db-wg(a)ripe.net > > Den 2015-06-02 15:36, Athina Fragkouli skrev: >> Dear colleagues, > Hi Athina, > > Thank you for the legal clarification i this matter. > >> In response to the question raised on the Database WG mailing list, >> “…whether there would be legal restrictions or considerations with >> regards to publishing information about deleted objects or the deleted >> objects themselves”, please find below a preliminary analysis from a >> legal perspective. >> >> The RIPE Database contains a variety of types of data. A distinction >> should be made between database objects that contain personal data (i.e. >> person and role objects) and those that do not (i.e. inetnum, inet6num, >> autnum, etc.). >> >> For database objects containing personal data, the Personal Data >> Protection Act in the Netherlands applies. More specifically, according >> to the Act personal data may be collected for specific, explicitly >> defined and legitimate purposes. >> Once collected, this data must not be >> kept for any longer than is necessary to achieve the purpose for which >> it has been collected. >> >> In consultation with the RIPE community, the RIPE Data Protection Task >> Force identified the reason why personal data should be inserted into, >> and made publicly available through, the RIPE Database. The reason the >> Internet community initially requested that this data be made publicly >> available was for Internet operation purposes. Internet network >> operators should have each other’s contact details (which is considered >> to be personal data by the Act) in order to facilitate communication >> among the individuals responsible for networks in case of operational >> problems in the network (troubleshooting, abuse, etc.). >> >> Accordingly, the RIPE Database contains the contact details of >> individuals that are responsible for resolving operational problems in a >> network. However, if an individual no longer has this responsibility, >> this individual’s contact details must be deleted from the RIPE Database. >> >> If the RIPE community wishes to have access to contact details of >> individuals that were responsible for resolving operational problems in >> the past, then the RIPE community must have a specific, explicitly >> defined and legitimate purpose for it. If such a purpose is defined, the >> RIPE NCC will proceed with investigating the conditions under which this >> feature can be implemented in compliance with the Act. Implementation of >> this feature may include prior consent of these individuals. >> >> For more information about the implementation of this legislation in the >> RIPE Database and related services, please see the RIPE NCC Data >> Protection Report [1]. >> >> For database objects that do not contain personal data, there are no >> restrictions in terms of personal data protection. If the RIPE Community >> wishes the RIPE NCC to include the feature for publishing the history of >> deleted objects in the RIPE Database, the RIPE NCC will proceed with the >> implementation of this feature. As part of this process the RIPE NCC >> will need to investigate and possibly update its procedures and >> governance documents to ensure compliance with its legal obligations. >> Updating the relevant governance documents is subject to the RIPE NCC >> procedural document “Adoption Process for RIPE NCC Corporate Documents” >> [2]. > > If we can start out with inetnum, inet6num, aut-num, route, route6 and organisation it's good so far. > > I have a question about the word "purposes" of the text. Denis also mentions "purposes" in his e-mail. Are these "purposes" defined somewhere in a RIPE document or is it a legal definition that must be applied to what we believe is the "purpose" of an object? > > regards, > > -- > > Bengt Gördén > Resilans AB > >

1 0

Publishing Deleted Objects - Legal Analysis
by Athina Fragkouli 09 Jun '15

09 Jun '15

Dear colleagues, In response to the question raised on the Database WG mailing list, “…whether there would be legal restrictions or considerations with regards to publishing information about deleted objects or the deleted objects themselves”, please find below a preliminary analysis from a legal perspective. The RIPE Database contains a variety of types of data. A distinction should be made between database objects that contain personal data (i.e. person and role objects) and those that do not (i.e. inetnum, inet6num, autnum, etc.). For database objects containing personal data, the Personal Data Protection Act in the Netherlands applies. More specifically, according to the Act personal data may be collected for specific, explicitly defined and legitimate purposes. Once collected, this data must not be kept for any longer than is necessary to achieve the purpose for which it has been collected. In consultation with the RIPE community, the RIPE Data Protection Task Force identified the reason why personal data should be inserted into, and made publicly available through, the RIPE Database. The reason the Internet community initially requested that this data be made publicly available was for Internet operation purposes. Internet network operators should have each other’s contact details (which is considered to be personal data by the Act) in order to facilitate communication among the individuals responsible for networks in case of operational problems in the network (troubleshooting, abuse, etc.). Accordingly, the RIPE Database contains the contact details of individuals that are responsible for resolving operational problems in a network. However, if an individual no longer has this responsibility, this individual’s contact details must be deleted from the RIPE Database. If the RIPE community wishes to have access to contact details of individuals that were responsible for resolving operational problems in the past, then the RIPE community must have a specific, explicitly defined and legitimate purpose for it. If such a purpose is defined, the RIPE NCC will proceed with investigating the conditions under which this feature can be implemented in compliance with the Act. Implementation of this feature may include prior consent of these individuals. For more information about the implementation of this legislation in the RIPE Database and related services, please see the RIPE NCC Data Protection Report [1]. For database objects that do not contain personal data, there are no restrictions in terms of personal data protection. If the RIPE Community wishes the RIPE NCC to include the feature for publishing the history of deleted objects in the RIPE Database, the RIPE NCC will proceed with the implementation of this feature. As part of this process the RIPE NCC will need to investigate and possibly update its procedures and governance documents to ensure compliance with its legal obligations. Updating the relevant governance documents is subject to the RIPE NCC procedural document “Adoption Process for RIPE NCC Corporate Documents” [2]. Kind regards, Athina Fragkouli Legal Counsel RIPE NCC [1] https://www.ripe.net/about-us/legal/ripe-ncc-data-protection-report [2] https://www.ripe.net/about-us/corporate-governance/adoption-process-for-rip…

4 5

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

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

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

14 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