- db-wg - mailman.ripe.net

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

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

17 Oct '17

Hi Guys: How about not change any status in BD until we have an automated API to deal with this. How about Just simply send an email the the holder in foreign database to notify them properly. I think the biggest problem we have here is not foreign route object being created, but rather they being created without holder’s knowledge. On Tue, Oct 17, 2017 at 09:03 den is via db-wg <db-wg(a)ripe.net> wrote: > 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 > > > > > > -- -- Kind regards. Lu

1 0

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

17 Oct '17

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