- db-wg - mailman.ripe.net

Last Call - creation of new out of region ROUTE(6) objects
by denis walker 11 Jan '18

11 Jan '18

Colleagues Plans to implement the solution for NWI-5 by dropping the auth requirement from ASNs in ROUTE(6) object creation and marking existing out of region ROUTE(6) objects in the database with a different source tag are progressing. In December I asked if we should continue to allow the creation of new ROUTE(6) objects in the RIPE Database (with the new source tag) for non RIPE address space. There were a few comments supporting the view NOT to allow any new object creations. There were no comments supporting the continued creation of any new objects. During the earlier, lengthy discussion on NWI-5 quite a few people supported the use of the RIPE Database for ROUTE(6) objects for non RIPE address space. With the plan to drop the ASN auth requirement are those people satisfied that we no longer need to create these ROUTE(6) objects in the RIPE Database? So basically I am making a last call to see if anyone still feels there is any need to allow creation of any new ROUTE(6) objects in the RIPE Database for non RIPE address space? cheersdenisco-chair DB WG

5 6

Creation of out of region ROUTE(6) objects
by denis walker 14 Dec '17

14 Dec '17

Colleagues We are now approaching the implementation stage for managing the existing out of region ROUTE(6) objects in the RIPE Database (NWI-5). A question has been asked about the creation of new ROUTE(6) objects in the RIPE Database relating to non RIPE address space. This will still be technically possible after implementation of the solution for NWI-5. The question we now need to answer is...Do we want to allow the creation of new ROUTE(6) objects in the RIPE Database for non RIPE address space? Over the years this issue has been debated within this community there have been arguments made for and against this situation. The case against doing this is well known now. If anyone believes there is still a case for allowing these object creations (either for any address space or for some section of the global address space) then can you please make your case now. We would like to wrap up this whole issue with a clear consensus from the community. cheersdenisco-chair DB WG

4 3

Validation on "org-name:" syntax (double spaces and newlines)
by Alexander Stranzky 01 Dec '17

01 Dec '17

Am 12.11.17 um 12:00 schrieb db-wg-request(a)ripe.net: > Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the ?org-name:? attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the ?org-name:? matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. While currently not an issue, you should include other non-spaces whitespace (i.e. Tabs & NULL-Bytes) in your blacklist. Regards, Alex -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

4 3

Validation on "org-name:" syntax (double spaces and newlines)
by Tim Bruijnzeels 23 Nov '17

23 Nov '17

Dear Working Group, Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following: 1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input I am leaning towards option 2, but I would value your input. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

6 6

Proxy proposal large communities
by Tim Bruijnzeels 14 Nov '17

14 Nov '17

Dear Working Group, As discussed at RIPE 75 I want to forward a request by Job Snijders on GitHub: https://github.com/RIPE-NCC/whois/issues/410 Job is asking to add a “large_community" keyword to RPSL dictionary where applicable. And provides the following example: Suggestion: name the keyword large_community mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT large_community.contains(21414:0:570) export: to AS6777 action large_community .= { 6777:0:6777 }; announce AS-FORTHNET mp-import: afi ipv6.unicast from AS8631 msk-rs2.ripn.net action large_community={31376:0:2}; pref=100; accept AS-MSKROUTESERVER import: from AS35082 95.128.51.234 at 95.128.51.233 action pref=500; large_community.append(29527:0:35082,29527:0:60000,29527:0:61200,29527:0:61210); accept AS-VIBUS-LONDON filter-set: fltr-as21229-export descr: Filter for AS21229 exported prefixes filter: AS-TVNETWORK AND large_community(21229:0:1) From our end I do not see any issues implementing this on the server side, but I can’t speak to how this will be treated by scripts that may parse RPSL today. Please discuss. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

5 24

new NWI? - was: mntner object updates by mail
by Piotr Strzyzewski 27 Oct '17

27 Oct '17

Dear WG Members After a nice chat just a seconds after DB-WG session has ended it was brought to the attention of few of us that there was an email sent last December by Ulf Kieber (with some responses) about mntner object updates by mail. Dear Chairs, can we proceed with that and make it next NWI? Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland

5 5

Co-Chair Resignation
by William Sylvester 20 Oct '17

20 Oct '17

All, Denis and I were notified this morning by David that he is resigning as a co-chair for the database working group. He also indicated that he had resigned from Larus and was no longer employed there. He had intended to notify the working group sooner; his delays were the result of his relocation from Hong Kong back to Europe. He will not be attending the RIPE meeting next week in Dubai. David is very apologetic for what has transpired and that it has taken focus from the working groups primary tasks. I know this has been a very charged situation for the working group, and I appreciate everyone maintaining the professionalism I greatly respect within our community. We wish David the best in his future endeavors and thank him for his contributions. As a working group, we consider this issue closed. If you have any questions or concerns please notify the chairs. As we are nearing the end of the year, Denis and I have agreed to kick off the chair selection process earlier this year. We will be sending details out on the chair selection process soon. Best regards, William & Denis, co-chairs

2 1

NWI-2 Displaying history for database objects where available
by den is 20 Oct '17

20 Oct '17

Colleagues The DB WG co-chairs would now like to address this issue. There was some discussion on the mailing list in May to July of 2016. In brief the issue is that the current history mechanism has an arbitrary design constraint that only the history of currently existing objects can be seen. This may also not be complete if the object has been deleted and re-created. The problem definition has not yet been finalised. Also there was some discussion about the reasons for wanting more historical information being made available for resource objects (and possibly some other object types). We would therefore like to ask anyone with concerns about historical data to please review what was said last year and express support or otherwise and perhaps add some reasoning as to why more data is needed. cheers denis co-chair DB WG

4 4

DMARC Settings Change on RIPE Database Working Group Mailing List
by Adam Castle 19 Oct '17

19 Oct '17

Hi RIPE Database Working Group, In March 2017, the RIPE NCC implemented a requested DMARC change to this list < https://www.ripe.net/ripe/mail/archives/db-wg/2017-March/005514.html > The change was to enable the DMARC 'Wrap Message' setting in Mailman so that DMARC-enabled users could receive emails from the list sent via other DMARC-enabled users. Unfortunately, this caused some users to see emails come through as attachments, as well as various other compatibility issues with some mail clients. After consultation with the RIPE Database Working Group Co-Chairs, we have changed the Mailman setting to 'Munge the From address'. If you experience any emails from this mailing list as attachments from this point onwards, then please let me know. Many thanks, Adam Castle Web Services Manager RIPE NCC

2 1

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Rob Evans 19 Oct '17

19 Oct '17

Hi, > 1) Remove the "origin:" authorization requirement. RIPE is currently > the only RIR that requires this, the current implementation creates > data concurrency issues across Internet databases by requiring the > creation of duplicate autnums. > > 2) Flag "route:" objects for non-RIPE-managed space with "source: > RIPE-NONAUTH" to identify non-authoritative data. I support both of those. I’ll observe that there have been attempts to do (1) in the past that have floundered. > 3) Consider possible, simple options to allow non RIPE resource > holders to 'approve' (if not authorise) the creation of a foreign > ROUTE object. I wouldn’t want to lose the ability to make progress on (1) and (2) because we end up getting bogged down in the details of (3), which is what I fear will happen, so I’d put something like this on the back burner for now. Cheers, Rob

5 5

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Randy Bush 18 Oct '17

18 Oct '17

> 2) Flag "route:" objects for non-RIPE-managed space with "source: > RIPE-NONAUTH" to identify non-authoritative data. why not go the other, more positive, direction, and identify authorised data with RIPE-AUTH or whatever? no need to be pejorative. randy

4 6

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Nick Hilliard 18 Oct '17

18 Oct '17

Bill, a single issue has been addressed in your email, relating to the RIPE NCC's actions in dealing with a violation of the RIPE DB T&Cs. The core issue of the complaint, namely the actions of one of the WG co-chairs, remains completely unaddressed. Can you kindly inform the working group whether, and if so, when the Database WG chairs intend to address this? Nick William Sylvester via db-wg wrote: > This message is to follow up on thread created recently with regard to a > reported violation of the RIPE Database Terms and Conditions. Several > members have commented publically and a few privately on this matter and > we wanted to publically addresses these concerns. The working group > chairs after consulting with the RIPE NCC and the RIPE Chair have > identified two primary issues in question; > > > > 1. A violation of the terms and conditions has been reported to the > working group, this is out of scope for the working group. Concerns > over usage in regard to the terms and conditions should be reported > to the RIPE NCC directly and not on the Database working group > mailing list. RIPE NCC has the responsibility and the resources to > handle these violations appropriately. It is our understanding that > the RIPE NCC has a process they have followed, and have done so with > the complaint registered on the working group mailing list. It is > the RIPE NCC’s responsibility to investigate and take action as > appropriate. As the working group, with this item referred to RIPE > NCC, we consider this issue handled and closed. > > > > 2. Conduct of a co-chair for a working group. This is a much more > challenging issue, should a chair be held accountable for the > actions of an employer? What are examples of unacceptable behavior > for a chair and when misconduct is suspected, what action, if any, > should be taken? Currently in the RIPE community there are no > policies for the removal of a chair. In the history of the RIPE > community a working group chair has only been removed once. Chair > selection is conducted through the processes identified by each > working group. Lacking a defined process, it seems that the chair > selection process coming up is the primary way the working group > selects or changes the working group leadership. > > > > I have always found David to be a good person who cares deeply about the > RIPE community, as a working group chair he has always handled working > group business with the highest integrity. I urge the working group to > consider mistakes we have each made as individuals, by our employers, > and in life. As working group chairs, we serve the working group for the > benefit of the RIPE community, we embrace open discussion from all > working group members, and we strive to resolve issues transparently > through community feedback and rough consensus. We continue to seek > community guidance in all aspects of managing the working group and look > forward to facilitating the database work in our working group. > > > > Thanks, > > > > William on behalf of the > > Database Working Group Chairs >

1 0

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Randy Bush 18 Oct '17

18 Oct '17

this is a brilliant exercise to see how far the community will bend over in pseudo-politeness while it is being slimed and abused. randy

2 2

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by George Michaelson 17 Oct '17

17 Oct '17

Yes, I would support these changes. Half of the concerns with APNIC resource management disappears if we cease depending on aut-num authorization for route objects. I prefer that ultimately the open maintainer method cease. But a step along the way is to mark foreign objects clearly, so their status and role can be understood. -George On Tue, Oct 17, 2017 at 9:23 AM, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: William Sylvester <william.sylvester(a)addrex.net> > To: Database WG <db-wg(a)ripe.net> > Cc: > Bcc: > Date: Mon, 16 Oct 2017 23:22:55 +0000 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > Db-wg members, > > Now that there has been substantial discussion on this topic, I wanted to try to bring the conversation back to a more practical and actionable path forward. Clearly this is a topic where there are a lot of opinions. From seeing the discussion and receiving additional feedback, I wanted to point out some re-occurring themes and request a revised proposal for working group consideration. > > > 1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums. > > 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. > > > I’d like to seek input from the group; > > - Do you feel these options are straight forward and easy to understand? > - Does this provide a reasonable security posture? > - Will this make a positive impact for RIPE DB and the greater Internet? > - Do you support these concepts? > > > Thanks, > William > Db-wg co-chair > >

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by denis walker 17 Oct '17

17 Oct '17

Hi Job I agree with your assessment and, although it should be in a separate thread later, I think it's worth having a discussion about notifying resource holders if a foreign ROUTE object is created in the RIPE Database. But lets focus on the main points for now. cheersdenis co-chair DB WG From: Job Snijders via db-wg <db-wg(a)ripe.net> To: den is <denis1(a)gmail.com> Cc: Database WG <db-wg(a)ripe.net> Sent: Tuesday, 17 October 2017, 10:06 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? Dear Denis, Just to make sure we are on the same page, the 2 items presented by Bill are not two mutually exclusive options, I think both need to be done. On Tue, Oct 17, 2017 at 01:04:08AM +0000, den is via db-wg wrote: > 3) Consider possible, simple options to allow non RIPE resource > holders to 'approve' (if not authorise) the creation of a foreign > ROUTE object. An even simpler option is to not even attempt to authorize the creation of non-RIPE route objects, but simply flag them as "RIPE-NONAUTH". If people want to create authoritive route objects for non-RIPE-managed space they can create those objects in the DB from the RIR where the space is managed (APNIC, AFRINIC, etc). While on the surface of things, it looks trivial to have the RIPE database software fire off an email to what most probably is the legitimate 'foreign' owner of the IP block, it introduces quite some complexity such as "what if the resource is transfer to a new owner" "what if the resource is transferred to a new owner and a new RIR". Even though at some point in the past a form of approval was given, a day later that approval may have been revoked. The RIPE DB would have to continuously track movement of IP space. The continuously tracking of ownership aspects in other databases certainly can be done, but now the project no longer is simple low hanging fruit. I see some value if the RIPE DB could notify owners of non-RIPE IP blocks when non-authoritative data is created in the RIPE DB, but I think that would be something to consider in the future. Kind regards, Job

1 1

Fw: Foreign ROUTE objects in RIPE Database - final decision?
by denis walker 17 Oct '17

17 Oct '17

Hi Randy I don't think anyone cares how much work a script has to do, whether it's the one that writes or reads the data. But keep in mind that the RIPE Database was designed to be, and still largely is, human readable. So for the poor humans who delve into the database manually it's probably better not to confuse them with extra, new tags on 95% of the data that has the same meaning as before, and just tag that little 5% (or so) that can now be interpreted differently. cheersdenisco-chair DB WG From: Randy Bush via db-wg <db-wg(a)ripe.net> To: job(a)instituut.net Cc: Nick Hilliard via db-wg <db-wg(a)ripe.net> Sent: Tuesday, 17 October 2017, 19:34 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? >>> 2) Flag "route:" objects for non-RIPE-managed space with "source: >>> RIPE-NONAUTH" to identify non-authoritative data. >> >> why not go the other, more positive, direction, and identify authorised >> data with RIPE-AUTH or whatever? no need to be pejorative. > > This is not meant to be pejorative. "RIPE-NONAUTH" was brought up > because that way we don't touch the majority of objects that actually > are valid, and belong with RIPE. ahh, the poor overworked script will have less to do so we will have to pay it less. good plan. > If you have a different suggestion than "RIPE-NONAUTH" I think the group > would be all ears. "RIPE-2", "RIPE-OTHER", all is fine with me. for those old enough to remember, RARE

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by den is 17 Oct '17

17 Oct '17

3) Consider possible, simple options to allow non RIPE resource holders to 'approve' (if not authorise) the creation of a foreign ROUTE object. cheers denis co-chair DB WG On 17 October 2017 at 01:23, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: William Sylvester <william.sylvester(a)addrex.net> > To: Database WG <db-wg(a)ripe.net> > Cc: > Bcc: > Date: Mon, 16 Oct 2017 23:22:55 +0000 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > Db-wg members, > > Now that there has been substantial discussion on this topic, I wanted to try to bring the conversation back to a more practical and actionable path forward. Clearly this is a topic where there are a lot of opinions. From seeing the discussion and receiving additional feedback, I wanted to point out some re-occurring themes and request a revised proposal for working group consideration. > > > 1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums. > > 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. > > > I’d like to seek input from the group; > > - Do you feel these options are straight forward and easy to understand? > - Does this provide a reasonable security posture? > - Will this make a positive impact for RIPE DB and the greater Internet? > - Do you support these concepts? > > > Thanks, > William > Db-wg co-chair > >

2 1

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Brian Nisbet 17 Oct '17

17 Oct '17

On 14/10/17 12:37, Carsten Schiefner wrote: >> William, >> >> On 13.10.2017 21:56, William Sylvester wrote: >>> [...] >>> >>> 2. Conduct of a co-chair for a working group. This is a much more >>> challenging issue, should a chair be held accountable for the >>> actions of an employer? >> >> are we really talking about an action by some random colleagues of David >> he'd barely know as they would work in another department across the >> street and therefore he'd almost never have anything to do with them? > > I can speak to this from personal experience. > > When I worked for BT, a misguided salesdroid mined the RIPE DB and > used it to send spam to possible customers. When I found out I > arranged for the salesdroid to be suitably formally warned, extracted > an apology from them and passed the apologies of the company to the > RIPE NCC and the community. At the time I was a co-chair of the DB WG. > > I would expect any member of the community (not just a WG chair) to do > likewise. > > Nigel I would very much like to see, at the very least, something similar to the above, very clearly and formally. There are, it should be pointed out, processes for removal of WG Chairs, however the DB WG has not decided to have one. There are examples out there that the WG could adopt if it wishes. The problems that occurred in Rome were one of the reasons the community felt that a process was a good idea, but remember, lack of documented process didn't stop things happening on that occasion. The WG has the power to effect change if needed. This is *still* not a great state of affairs and while I don't want to take away from the points that must be discussed in Dubai, I would, at this point, expect it to be on the agenda at the meeting. Thanks, Brian

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Nick Hilliard 17 Oct '17

17 Oct '17

Daniel Shaw via db-wg wrote: > On 17/10/2017, 03:24, William Sylvester via db-wg typed: >> > >> > >> > 1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums. >> > >> > 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. >> > >> > >> > I’d like to seek input from the group; >> > >> > - Do you feel these options are straight forward and easy to understand? >> > - Does this provide a reasonable security posture? >> > - Will this make a positive impact for RIPE DB and the greater Internet? >> > - Do you support these concepts? >> > > > Yes. There isn't really any downside to these. There are clear benefits to both. Agreed. This sounds like a sensible thing to do. Nick

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Daniel Shaw 17 Oct '17

17 Oct '17

On 17/10/2017, 03:24, William Sylvester via db-wg typed: > > > 1) Remove the "origin:" authorization requirement. RIPE is currently the only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums. > > 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. > > > I’d like to seek input from the group; > > - Do you feel these options are straight forward and easy to understand? > - Does this provide a reasonable security posture? > - Will this make a positive impact for RIPE DB and the greater Internet? > - Do you support these concepts? > Yes. There isn't really any downside to these. There are clear benefits to both. Regards, Daniel

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Job Snijders 17 Oct '17

17 Oct '17

Dear WG, chairs, On Mon, Oct 16, 2017 at 11:24:14PM +0000, William Sylvester via db-wg wrote: > Now that there has been substantial discussion on this topic, I wanted > to try to bring the conversation back to a more practical and > actionable path forward. Clearly this is a topic where there are a lot > of opinions. From seeing the discussion and receiving additional > feedback, I wanted to point out some re-occurring themes and request a > revised proposal for working group consideration. > > 1) Remove the "origin:" authorization requirement. RIPE is currently > the only RIR that requires this, the current implementation creates > data concurrency issues across Internet databases by requiring the > creation of duplicate autnums. > > 2) Flag "route:" objects for non-RIPE-managed space with "source: > RIPE-NONAUTH" to identify non-authoritative data. > > I’d like to seek input from the group; > > - Do you feel these options are straight forward and easy to understand? > - Does this provide a reasonable security posture? > - Will this make a positive impact for RIPE DB and the greater Internet? > - Do you support these concepts? I fully support executing both action items. Removal of the "origin:" authorisation step will bring the RIPE IRR in line with other databases such as APNIC, RADB and as such make use of the database easier for global organisations. It also aligns with the practises observed in RPKI. Flagging "route:/route6:" objects with "RIPE-NONAUTH" when they cover non-RIPE managed space has many benefits. Setting the "source:" to represent what the data actually means, we can programmatically analyse the contents of the RIPE DB and facilitate creation of higher quality route filters, but also for instance use it as a reputation factor in spam scoring. These two options represent what currently is the lowest hanging fruit to improve in this problem space. Funny enough, neither of these items makes things more difficult for anyone involved, on the contrary - by making route: authorisation easier, _and_ showing what is authoritative data and what is not, we improve the security posture of the RIPE community. Kind regards, Job

4 3

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Job Snijders 17 Oct '17

17 Oct '17

Dear Denis, Just to make sure we are on the same page, the 2 items presented by Bill are not two mutually exclusive options, I think both need to be done. On Tue, Oct 17, 2017 at 01:04:08AM +0000, den is via db-wg wrote: > 3) Consider possible, simple options to allow non RIPE resource > holders to 'approve' (if not authorise) the creation of a foreign > ROUTE object. An even simpler option is to not even attempt to authorize the creation of non-RIPE route objects, but simply flag them as "RIPE-NONAUTH". If people want to create authoritive route objects for non-RIPE-managed space they can create those objects in the DB from the RIR where the space is managed (APNIC, AFRINIC, etc). While on the surface of things, it looks trivial to have the RIPE database software fire off an email to what most probably is the legitimate 'foreign' owner of the IP block, it introduces quite some complexity such as "what if the resource is transfer to a new owner" "what if the resource is transferred to a new owner and a new RIR". Even though at some point in the past a form of approval was given, a day later that approval may have been revoked. The RIPE DB would have to continuously track movement of IP space. The continuously tracking of ownership aspects in other databases certainly can be done, but now the project no longer is simple low hanging fruit. I see some value if the RIPE DB could notify owners of non-RIPE IP blocks when non-authoritative data is created in the RIPE DB, but I think that would be something to consider in the future. Kind regards, Job

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Sander Steffann 17 Oct '17

17 Oct '17

Hi, Op 17 okt. 2017, om 09:53 heeft Job Snijders via db-wg <db-wg(a)ripe.net> het volgende geschreven: > These two options represent what currently is the lowest hanging fruit > to improve in this problem space. Funny enough, neither of these items > makes things more difficult for anyone involved, on the contrary - by > making route: authorisation easier, _and_ showing what is authoritative > data and what is not, we improve the security posture of the RIPE > community. +1 This is low-hanging fruit indeed, and I see no problems with either of them. Cheers, Sander

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Daniel Shaw 17 Oct '17

17 Oct '17

On 11/10/2017, 18:22, Sascha typed: > > >> Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? This question has to be split into two to be able to be answered. Part 1: Should RIPE DB allow creation of route/route6 objects when both the inetnum(6) and aut-num resources are non-RIPE? Part 2: Should RIPE DB allow creation of route/route6 objects where one or the other of the prefix or origin asn *are* in the RIPE DB, and the other is not. That is so call cross-rir route objects? Part 2 is trickier, and largely what this thread is debating as I understand it. For part 1, I struggle to see any good reason to allow this to continue. It simple allows for anyone to create any route: objects, referring to any combination of resources that may or may not have any bearing on the reality of the internet. There is not even a good verification the resources are even allocated at all. In addition, once set up, there is zero incentive for anyone to ever delete these once obsolete. This was necessary once upon a time, as there were no useful alternatives then. That is now history. > > Is an option D: create a central IRRDB with authentication hooks > into all RIRs completely out of the question? I don't see that as a practical or realistic option. Regards, Daniel

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Daniel Shaw 17 Oct '17

17 Oct '17

On 11/10/2017, 17:48, Nick Hilliard via db-wg typed: > > > Job Snijders wrote: >> I think this touches upon an incredibly important question: how do we >> distinguish between garbage and properly authenticated "route:" >> objects covering RIPE-managed space? > > and more to the point: are there good reasons and community support for > continuing not to distinguish between the two. Quite so. I cannot see any. Having a flag/label that makes it clear right away how much authentication a given route:/rotue6: object has associated with it can only be a good thing. That doesn't change the existence or creation of any class of object. But clearly marking what is what seems a no brainer to me. Thanks, Daniel

1 0