October 2017 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 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

NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
by William Sylvester 15 Feb '18

15 Feb '18

DB-WG Members, Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described. This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows: 1) Remove the "origin:" authorization requirement. 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. Thank you all for your work on this proposal! Kind regards, William & Denis DB-WG co-chairs

11 21

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 18 Oct '17

18 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

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

Re: [db-wg] Whois release 1.90 in Release Candidate environment, production release planned for 16 October
by denis walker 17 Oct '17

17 Oct '17

Hi Tim Thanks for working through this in time for the RIPE Meeting. It may not be the last word on "abuse-c:" but it will please a lot of people. cheersdenisco-chair DB WG From: Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> To: Database WG <db-wg(a)ripe.net> Sent: Monday, 16 October 2017, 16:21 Subject: Re: [db-wg] Whois release 1.90 in Release Candidate environment, production release planned for 16 October Dear Working Group, Whois release 1.90 has now been deployed to production. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technical Officer RIPE NCC > On 27 Sep 2017, at 10:28, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> wrote: > > > From: Tim Bruijnzeels <tim(a)ripe.net> > Subject: Whois release 1.90 in Release Candidate environment, production release planned for 16 October > Date: 27 September 2017 at 10:26:44 GMT+2 > To: Database WG <db-wg(a)ripe.net> > > > Dear working group, > > RIPE Database Release 1.90 was deployed to the Release Candidate Environment, last week on 22 September 2017. If no issues are raised, we plan to deploy this version to production on Monday 16 October 2017 > > Release 1.90 introduces the following main features in support of NWI-7 (abuse-c implementation): > > = Allow adding an "abuse-c:" attribute to INET(6)NUM and AUT-NUM objects > = Disallow adding "abuse-c:" to object types other than ROLE, INET(6)NUM and AUT-NUM > > Release 1.90 contains a number of small improvements: > > = Make org-name validation case-sensitive (no longer consider case changes a no-op) > = Support to remove generated AUT-NUM "remarks:" regarding legacy status > > The complete list of other minor issues solved by this release can be found here: > https://github.com/RIPE-NCC/whois/blob/master/changes.txt > > Please let us know if you see any issues with this release in the RC environment. > > Kind regards > > Tim Bruijnzeels > > Assistant Manager Software Engineering and Senior Technical Officer > RIPE NCC > > >

1 0

Re: [db-wg] Whois release 1.90 in Release Candidate environment, production release planned for 16 October
by Tim Bruijnzeels 16 Oct '17

16 Oct '17

Dear Working Group, Whois release 1.90 has now been deployed to production. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technical Officer RIPE NCC > On 27 Sep 2017, at 10:28, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> wrote: > > > From: Tim Bruijnzeels <tim(a)ripe.net> > Subject: Whois release 1.90 in Release Candidate environment, production release planned for 16 October > Date: 27 September 2017 at 10:26:44 GMT+2 > To: Database WG <db-wg(a)ripe.net> > > > Dear working group, > > RIPE Database Release 1.90 was deployed to the Release Candidate Environment, last week on 22 September 2017. If no issues are raised, we plan to deploy this version to production on Monday 16 October 2017 > > Release 1.90 introduces the following main features in support of NWI-7 (abuse-c implementation): > > = Allow adding an "abuse-c:" attribute to INET(6)NUM and AUT-NUM objects > = Disallow adding "abuse-c:" to object types other than ROLE, INET(6)NUM and AUT-NUM > > Release 1.90 contains a number of small improvements: > > = Make org-name validation case-sensitive (no longer consider case changes a no-op) > = Support to remove generated AUT-NUM "remarks:" regarding legacy status > > The complete list of other minor issues solved by this release can be found here: > https://github.com/RIPE-NCC/whois/blob/master/changes.txt > > Please let us know if you see any issues with this release in the RC environment. > > Kind regards > > Tim Bruijnzeels > > Assistant Manager Software Engineering and Senior Technical Officer > RIPE NCC > > >

1 0

Re: [db-wg] DB signatures
by Job Snijders 16 Oct '17

16 Oct '17

Thanks Tim!

1 0

Re: [db-wg] DB signatures
by Tim Bruijnzeels 16 Oct '17

16 Oct '17

Dear Aliaksei, working group, The split files, and all other content of the ftp site, are also available on https: https://ftp.ripe.net/ https://ftp.ripe.net/ripe/dbase/split/ They have been available here for quite a while but I realise that this was not widely announced, nor documented. I will make sure that documentation is updated. The files are generated using a snapshot of data at midnight CEST - but take over 2 hours to complete - because we have to filter out personal data. Because this is resource intense, and because there may be scripts out there running at various times in the day and expecting to retrieve the ‘midnight’ snapshot, I am not keen on increasing the frequency unless it’s clear that there is great demand for this. Dependent on your needs the NRTM service may also be a fit for you: https://www.ripe.net/manage-ips-and-asns/db/nrtm-mirroring Kind regards, Tim Bruijnzeels > On 16 Oct 2017, at 11:30, Horváth Ágoston János via db-wg <db-wg(a)ripe.net> wrote: > > > From: Horváth Ágoston János <horvath.agoston(a)gmail.com> > Subject: Re: [db-wg] DB signatures > Date: 15 October 2017 at 12:22:03 GMT+2 > To: Aliaksei Sheshka <sheshkaoss(a)gmail.com> > Cc: "db-wg(a)ripe.net >> Database WG" <db-wg(a)ripe.net> > > > The gzip format already contains checksum. > Signing is a different issue. But the first question one might ask is > why this data is still offered through FTP. Using https would also > make most of the signing requirements obsolete. > > On Sat, Oct 14, 2017 at 1:02 AM, Aliaksei Sheshka via db-wg > <db-wg(a)ripe.net> wrote: >> >> >> ---------- Forwarded message ---------- >> From: Aliaksei Sheshka <sheshkaoss(a)gmail.com> >> To: db-wg(a)ripe.net >> Cc: >> Bcc: >> Date: Fri, 13 Oct 2017 19:01:56 -0400 >> Subject: Re: [db-wg] DB signatures >> I assume time stamps are UTC, ftp shows 10/12/17, 10:12:00 PM, now it is Fri Oct 13 22:57:17 2017 UTC >> I would say 24h+ update for such data is too much. >> Also having signatures / checksums is a standard security measure for any downloads and are very easy to implement. >> >> >> On Fri, Oct 13, 2017 at 1:58 PM, denis walker <ripedenis(a)yahoo.co.uk> wrote: >>> >>> Hi Aliaksei >>> >>> The files are regenerated daily. There are some checks done on the files as part of the generation process, like zero size check or size difference more than some percentage from yesterday. Perhaps the RIPE NCC can comment on the possibility of signing or checksum files? >>> >>> cheers >>> denis >>> co-chair DB WG >>> >>> ________________________________ >>> From: Aliaksei Sheshka via db-wg <db-wg(a)ripe.net> >>> To: db-wg(a)ripe.net >>> Sent: Friday, 13 October 2017, 19:45 >>> Subject: [db-wg] DB signatures >>> >>> Hello! >>> >>> I would like to know if there is a plan to sign / checksum files located at >>> ftp://ftp.ripe.net/ripe/dbase/split/ ? >>> Currently there is no mechanism to know if files aren't tampered or corrupted. >>> >>> My second question is how often those files are updated? >>> >>> Thanks!

1 0

Re: [db-wg] DB signatures
by Horváth Ágoston János 15 Oct '17

15 Oct '17

The gzip format already contains checksum. Signing is a different issue. But the first question one might ask is why this data is still offered through FTP. Using https would also make most of the signing requirements obsolete. On Sat, Oct 14, 2017 at 1:02 AM, Aliaksei Sheshka via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Aliaksei Sheshka <sheshkaoss(a)gmail.com> > To: db-wg(a)ripe.net > Cc: > Bcc: > Date: Fri, 13 Oct 2017 19:01:56 -0400 > Subject: Re: [db-wg] DB signatures > I assume time stamps are UTC, ftp shows 10/12/17, 10:12:00 PM, now it is Fri Oct 13 22:57:17 2017 UTC > I would say 24h+ update for such data is too much. > Also having signatures / checksums is a standard security measure for any downloads and are very easy to implement. > > > On Fri, Oct 13, 2017 at 1:58 PM, denis walker <ripedenis(a)yahoo.co.uk> wrote: >> >> Hi Aliaksei >> >> The files are regenerated daily. There are some checks done on the files as part of the generation process, like zero size check or size difference more than some percentage from yesterday. Perhaps the RIPE NCC can comment on the possibility of signing or checksum files? >> >> cheers >> denis >> co-chair DB WG >> >> ________________________________ >> From: Aliaksei Sheshka via db-wg <db-wg(a)ripe.net> >> To: db-wg(a)ripe.net >> Sent: Friday, 13 October 2017, 19:45 >> Subject: [db-wg] DB signatures >> >> Hello! >> >> I would like to know if there is a plan to sign / checksum files located at >> ftp://ftp.ripe.net/ripe/dbase/split/ ? >> Currently there is no mechanism to know if files aren't tampered or corrupted. >> >> My second question is how often those files are updated? >> >> Thanks! >> >> >> >> > >

1 0

violation of DB T&C by DB-WG co-chair, is it acceptable?
by Elvis Daniel Velea 15 Oct '17

15 Oct '17

Dear RIPE NCC, can you please present a report showing how many LIRs have reported RIPE DB T&C violations? How many were resolved and what was the outcome? - Specifically, how many times has the RIPE NCC taken any action other than a warning message. Dear DB-WG, should we accept that one of the chairs of this WG is purposely violating the T&Cs of the RIPE DB? Please see below one of the e-mails received from David, the RIPE DB-WG co-chair, by a RIPE NCC member named /<company>/. (I'd like to mention that /<company>/ has never had a business relationship with Larus Cloud Service Limited, has never subscribed to any mailing list and has never requested the message below - which I find to be spam as it was never solicited). regards, elvis From: Larus Team <vendors(a)laruscloudservice.net> Subject: Unused IPv4 space of /<company>/ Dear Colleagues, We are contacting you regarding potential unused IPv4 address currently registered to your organisation /<company>/. Organisations like yours have in the past received address IPv4 space, it sometimes remains unused after changes to networks. Based on the available information it appears that your organisation is currently holding IPv4 space that appears unused or underutilised. We would like to offer you the possibility to capitalise on these addresses, we can assist you in either finding organisation to permanently transfer (sell) towards, or assist you in finding and forging long term relationships with some of our clients by leasing the unused space to them, generating a long-term income. We are a company based in Hong Kong, our CEO Heng Lu, has over ten years’ experience in managing Internet resources across the globe. Our IP manager David Hilario previously worked for the RIPE NCC one of the five RIR and as such has an intricate knowledge of the policies in the RIR policies especially when it comes to transfers and leasing the address space. We have clients lined up waiting for permanent transfers or long-term lease, so we can fulfil any of your requirements. We offer clients with available IP space a 3 months exclusivity contract. based on your requirements, we will match our waiting list clients with your criteria so that your IP space can be capitalise as soon as possible at the best possible rate. Please note that if you are leasing out your address space, we will offer it on a minimum of yearly basis with advance payment from our clients. Please find attached to this email our NDA to be filled in from your side and returned to us before we can proceed any further in our cooperation in regard to these transfers or long-term lease. We can lease and sell IP space to and from ARIN (North America) APNIC (Asia Pacific) and RIPE NCC (Europe, Middle East and parts of Central Asia). Kind Regards, David Hilario IP Manager Larus Cloud Service Limited p: +852 29888918 m: +359 89 764 1784 f: +852 29888068 a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR w: laruscloudservice.net e: d.hilario(a)outsideheaven.com Larus Team www.laruscloudservice.net <http://sctrack.mail.laruscloudservice.net/track/click/eyJ1c2VyX2lkIjogNDE4M…>

4 3

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Sascha Luck [ml] 14 Oct '17

14 Oct '17

On Wed, Oct 11, 2017 at 02:46:54PM +0100, Nick Hilliard via db-wg wrote: >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. Well, distinguishing in the irrdb is one thing, but how would you distinguish between them in RealLife(tm)? It's not like you can not route/accept a cross-RIR route: object (at least not without Breaking The Internet) Also, what would the distinguisher be for eg. a route: with prefix from RIPE and ASN from ARIN? RIPE-PARTIALLY-AUTHENTICATED? cheers, Sascha Luck

3 2

Re: Geoloc Object
by Erik Bais - A2B Internet 14 Oct '17

14 Oct '17

Hi Milad, If you can share the range (can be off-list if you prever) and the desired geo loc. I’ll be more than happy to assist. We fix these kind of things for customers a lot .. Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 14 okt. 2017 om 11:02 heeft Milad Afshar <afshar.milad89(a)gmail.com> het volgende geschreven: > > Hi Folks, > I hope this email finds you well. > I have problem on some of my IP ranges location showing in RIPEstat,I would like to know that does the "geoloc" object in RIPE Database help the geolocation database providers(Maxmind and etc.) to find the correct location of IP Ranges? > Many thanks. > Milad Afshari >

1 0

Geoloc Object
by Milad Afshar 14 Oct '17

14 Oct '17

Hi Folks, I hope this email finds you well. I have problem on some of my IP ranges location showing in RIPEstat,I would like to know that does the "geoloc" object in RIPE Database help the geolocation database providers(Maxmind and etc.) to find the correct location of IP Ranges? Many thanks. Milad Afshari

1 0

Re: [db-wg] DB signatures
by denis walker 14 Oct '17

14 Oct '17

Hi Aliaksei The files are regenerated daily. There are some checks done on the files as part of the generation process, like zero size check or size difference more than some percentage from yesterday. Perhaps the RIPE NCC can comment on the possibility of signing or checksum files? cheersdenisco-chair DB WG From: Aliaksei Sheshka via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Friday, 13 October 2017, 19:45 Subject: [db-wg] DB signatures Hello! I would like to know if there is a plan to sign / checksum files located at ftp://ftp.ripe.net/ripe/dbase/split/ ? Currently there is no mechanism to know if files aren't tampered or corrupted. My second question is how often those files are updated? Thanks!

2 1

DB signatures
by Aliaksei Sheshka 13 Oct '17

13 Oct '17

Hello! I would like to know if there is a plan to sign / checksum files located at ftp://ftp.ripe.net/ripe/dbase/split/ ? Currently there is no mechanism to know if files aren't tampered or corrupted. My second question is how often those files are updated? Thanks!

1 0

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

13 Oct '17

Second attempt to get through the mailing system.... ----- Forwarded Message ----- From: denis walker <ripedenis(a)yahoo.co.uk> To: Sascha Luck [ml] <dbwg(a)c4inet.net> Cc: Database WG <db-wg(a)ripe.net> Sent: Wednesday, 11 October 2017, 19:40 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? Hi Sascha, all I see this as a real possibility for the longer term. But realistically it is not going to help with the situation in the near future. I see some think that RADB is already a 'central DB' whereas others in this thread have said they would not use RADB (don't know it that is for technical, political or reliability issues). Just to throw a wild idea into the pot on this. If we were to look into the possibility of a centralised database, at least for the three RIRs who use a common database root RIPE, APNIC, Afrinic, then to me it makes sense to have a common, public database for operational data not only for routing information but also for number resource information. Then such a common database could do proper authentication. Almost certainly the personal data referenced by the operational data would need to remain in separate regional databases for privacy and data protection reasons. From the point of view of managing globally unique resources it makes perfect sense. But I suspect there would be lots of opposition to such a suggestion for political and self preservation reasons from many directions. Bearing in mind that any such suggestion would takes years from an idea to reality, I don't think we should get too bogged down in discussing this as part of this thread. However, several people have mentioned the idea of proper management of global resources. So perhaps if someone feels the desire to raise the issue in Dubai and formally call for the start of a serious investigation process that could lead to a common operational database, then the ball will at least start rolling.... cheersdenisco-chair DB WG From: Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> To: denis walker <ripedenis(a)yahoo.co.uk> Cc: Database WG <db-wg(a)ripe.net> Sent: Wednesday, 11 October 2017, 16:21 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg wrote: > Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? Is an option D: create a central IRRDB with authentication hooks into all RIRs completely out of the question? It certainly sounds like the technologically most elegant answer. Modulo legacy resources, no unauthenticated irrdb objects should then have to exist. The trust root could be shared between the RIRs as is seemingly done with RPKI these days... cheers, Sascha Luck

1 0

Re: [db-wg] RIPE Access Account: Cannot change registered e-mail address back to previously one
by Tim Bruijnzeels 12 Oct '17

12 Oct '17

Dear Christoffer, Unfortunately this is not as easy to implement as one might think. However, we will look into this again and see if we can find a solution for this issue. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC > On 10 Oct 2017, at 21:16, Christoffer Hansen via db-wg <db-wg(a)ripe.net> wrote: > > > From: Christoffer Hansen via db-wg <db-wg(a)ripe.net> > Subject: [db-wg] RIPE Access Account: Cannot change registered e-mail address back to previously one > To: RIPE Database Working Group <db-wg(a)ripe.net> > Reply-To: Christoffer Hansen <netravnen(a)gmail.com> > > > > From: Christoffer Hansen <netravnen(a)gmail.com> > Subject: RIPE Access Account: Cannot change registered e-mail address back to previously one > Date: 10 October 2017 at 19:52:50 GMT+2 > To: RIPE Database Working Group <db-wg(a)ripe.net> > > > RIPE Database Working Group <db-wg(a)ripe.net> > > > Am I the only one who have previously wondered about the following issue... (?) > > 1. Register a RIPE Access Account with [account_1(a)example.com] > 2. is changed to [account_2(a)example.com] > 3. later tries to change registered RIPE Access Account e-mail back to [account_1(a)example.com]. > > I'am not allowed to do this. > > RIPE NCC's website simply does *not* allow me to do this. > > Refer to the following pictures for clarification. > > > Changing the e-mail address back to [account_1(a)example.com] > <2017-10-10 19_00_24-RIPE NCC Access — RIPE Network Coordination Centre.png> > × > > > > Creating a new RIPE Access Account for [account_1(a)example.com] > <2017-10-10 19_03_18-RIPE NCC Access — RIPE Network Coordination Centre.png> > × > > > > Trying the forgotten password function for [account_1(a)example.com] > <2017-10-10 19_04_28-RIPE NCC Access — RIPE Network Coordination Centre.png> > × > > > > > Regards, > Christoffer Hansen. > gpg: c8b3 82a8 a1cd cdb7 71fe b24c c654 948f da86 becd > > > >

2 4

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

12 Oct '17

I think its time to stop disrespecting external source of authority on this. You argued for a position based on the desire of RIPE entities needing to import foreign objects into their RPSL But you did not address the far larger body of people who are exposed to risks from the public maintainer and foreign object model, which we know is causing problems. I have presented three times on this at RIPE meetings in Dublin, Bucharest and Amsterdam pointing out that APNIC helpdesk and hostmaster are mediating calls from members who are concerned at how their ASN wound up in the RIPE RPSL. I also spoke recently at the APNIC services meeting to this, calling for a bit more dialogue on what we want to do. Lets build an ecology which can handle disparate sources, and stop demanding a bogus security model. The open maintainer is yesterdays man. a) Move the non-local stuff to another source and be explicit its an import to allow people to discriminate. We should do this irrespective of any other work: its not in RIPE data management, its not part of RIPE authoritative statements. A declaration of intent through an open maintainer is functionally indistinguishable from a lie. b) We can think about ROA. There is no permission from the origin-as to be referred to in a ROA, and we know that people regard the ROA as semantically in the same space as the route: object which demands the aut-num import. So we have a clear signal that routing praxis is now not that concerned with ASN authority to be cited in origin-AS. If you remove the dependency on aut-num maintainer, you will removed the dependency on foreign object import. The validity of authority over the aut-num can be understood from its appropriate RIR or NIR declaration, as an imported source. -George On Wed, Oct 11, 2017 at 8:06 AM, Job Snijders via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Job Snijders <job(a)instituut.net> > To: "Carlos M. Martinez" <carlosm3011(a)gmail.com>, "Sascha Luck [ml]" <dbwg(a)c4inet.net> > Cc: Database WG <db-wg(a)ripe.net>, denis walker <ripedenis(a)yahoo.co.uk> > Bcc: > Date: Wed, 11 Oct 2017 15:06:04 +0000 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > > On Wed, 11 Oct 2017 at 16:52, Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> wrote: >> >> On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote: >> >IMHO, any idea that starts with “Let´s create a central X” is doomed from the start. >> > >> >We must think along other lines. >> >> Maybe "central" was the wrong word to use. Think a DB that every >> RIR provides a copy of and authenticates the bits that "belong" >> to it. This would even be necessary to avoid compromise. >> One could pick the copy to use for filter generation or even >> query them all and implement a majority decision if there are >> discrepancies. >> Of course it would require all RIRs to use the same RPSL format >> but that appears more of a political than a technical problem. > > > > We already have that “central IRR” in the form of the likes of the RADB Whois server. RIPE’s data is the odd one out here. > > RIPE is the _only_ IRR source where we cannot differentiate between authenticated data and non-authenticated data. > > For all other sources we know that either the route objects have been authenticated against the inetnum’s specified maintainer (APNIC, AFRINIC, JPIRR) or is entirely without such verification (ARIN, NTTCOM, ALTDB, RADB itself, etc). > > The value of the data in the RIPE DB would significantly increase if this difference is shown. > > Kind regards, > > Job > >

1 0

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

11 Oct '17

On Wed, 11 Oct 2017 at 16:52, Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> wrote: > On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote: > >IMHO, any idea that starts with “Let´s create a central X” is doomed from > the start. > > > >We must think along other lines. > > Maybe "central" was the wrong word to use. Think a DB that every > RIR provides a copy of and authenticates the bits that "belong" > to it. This would even be necessary to avoid compromise. > One could pick the copy to use for filter generation or even > query them all and implement a majority decision if there are > discrepancies. > Of course it would require all RIRs to use the same RPSL format > but that appears more of a political than a technical problem. We already have that “central IRR” in the form of the likes of the RADB Whois server. RIPE’s data is the odd one out here. RIPE is the _only_ IRR source where we cannot differentiate between authenticated data and non-authenticated data. For all other sources we know that either the route objects have been authenticated against the inetnum’s specified maintainer (APNIC, AFRINIC, JPIRR) or is entirely without such verification (ARIN, NTTCOM, ALTDB, RADB itself, etc). The value of the data in the RIPE DB would significantly increase if this difference is shown. Kind regards, Job >

1 0

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Carlos M. Martinez 11 Oct '17

11 Oct '17

IMHO, any idea that starts with “Let´s create a central X” is doomed from the start. We must think along other lines. /Carlos On 11 Oct 2017, at 11:21, Sascha Luck [ml] via db-wg wrote: > From: Sascha Luck [ml] <dbwg(a)c4inet.net> > > To: denis walker <ripedenis(a)yahoo.co.uk> > > Cc: Database WG <db-wg(a)ripe.net> > > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - > final decision? > > Date: October 11, 2017 at 11:21 AM > > > > > On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg > wrote: > > >> Question - Should the RIPE Database allow creation of ROUTE objects >> for non RIPE resources? > > > Is an option D: create a central IRRDB with authentication hooks > into all RIRs completely out of the question? It certainly sounds > like the technologically most elegant answer. Modulo legacy > resources, no unauthenticated irrdb objects should then have to > exist. The trust root could be shared between the RIRs as is > seemingly done with RPKI these days... > > cheers, > Sascha Luck

2 1

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

11 Oct '17

Sascha Luck [ml] via db-wg wrote: > Not allowing > "foreign" resources in the ripedb denies the reality that there > will always be RIPE-allocated prefixes originated from > non-RIPE-assigned ASNs and vice versa. Not true - you can easily run a whois query on whois.radb.net specifying multiple sources, including RIPE: % bgpq3 -S RIPE,APNIC,LACNIC AS-FOO In fact, there is no way of writing a functioning irrdb querier which can't handle specifying arbitrary irrdb source: options on a per-ASN basis. Nick

2 2

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Sascha Luck [ml] 11 Oct '17

11 Oct '17

On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg wrote: > Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? Is an option D: create a central IRRDB with authentication hooks into all RIRs completely out of the question? It certainly sounds like the technologically most elegant answer. Modulo legacy resources, no unauthenticated irrdb objects should then have to exist. The trust root could be shared between the RIRs as is seemingly done with RPKI these days... cheers, Sascha Luck

1 0

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

11 Oct '17

On Tue, Oct 10, 2017 at 4:17 PM, Nick Hilliard via db-wg <db-wg(a)ripe.net> wrote: > ---------- Forwarded message ---------- > From: Nick Hilliard <nick(a)foobar.org> > To: Randy Bush <randy(a)psg.com> > Cc: Database WG <db-wg(a)ripe.net> > Date: Tue, 10 Oct 2017 15:16:41 +0100 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > Randy Bush via db-wg wrote: >>> > Question - Should the RIPE Database allow creation of ROUTE objects >>> > for non RIPE resources? >> >> yes > > then how can we use the traditional irrdb to distinguish between address > blocks which have been authenticated by the ripe ncc and those which > have not. > > Nick I think this touches upon an incredibly important question: how do we distinguish between garbage and properly authenticated "route:" objects covering RIPE-managed space? It seems it would be low hanging fruit to use the "source:" tag to distinguish between objects that are authenticated and non-authenticated by using "source: RIPE" and "source: RIPE-NONAUTH". The above described small step bridges the needs to many who expressed opposing views in this thread: some want to be able to register anything in the RIPE DB and some want it to be pristine and purge all non-RIPE-managed space from the IRR DB. By decorating the two types of data with the appropriate "source:" attribute I think we are meeting in the middle. By using a different "source:" attribute for RIPE vs non-RIPE space it becomes easier for operators to cherry pick which data they want to use in the creation of their routing security filters. Should the group decide to proceed with option A or C (between which I don't see a difference), at the very least it should be visible to my tooling which objects represent what type of data. Kind regards, Job

2 1

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Horváth Ágoston János 11 Oct '17

11 Oct '17

On Wed, Oct 11, 2017 at 12:28 PM, Daniel Shaw via db-wg <db-wg(a)ripe.net> wrote: > On 11/10/2017, 14:09, Job Snijders via db-wg typed: >> You >> as network operator can easily poll the APNIC or AFRINIC database. >> There are even a number of "IRR aggregation services" such as NTTCOM >> and RADB which mirror a ton of IRRs for your querying convenience. > > Without commenting on the debate either way (in this mail, at this time), just a quick technical note: In fact, the RIPE DB mirrors the AFRINIC IRR data, so you at least as far as AFRINIC goes, provided there is IRR data in the AFRINIC DB, you can get it by querying the RIPE DB with the correct 'source:' Correct. But if RIPE allows the creation of objects for which it has no authority over, what are users supposed to do when they see the contradicting data coming from RIPE and AFRINIC (to follow your example)? That's also the reason for the existence of the --resource query flag. Question is, why would we keep data that is not authoritative (and not mirror) in the RIPE DB? Agoston On Wed, Oct 11, 2017 at 12:28 PM, Daniel Shaw via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Daniel Shaw <daniel(a)afrinic.net> > To: Database WG <db-wg(a)ripe.net> > Cc: > Bcc: > Date: Wed, 11 Oct 2017 14:27:56 +0400 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > On 11/10/2017, 14:09, Job Snijders via db-wg typed: >> You >> as network operator can easily poll the APNIC or AFRINIC database. >> There are even a number of "IRR aggregation services" such as NTTCOM >> and RADB which mirror a ton of IRRs for your querying convenience. > > Without commenting on the debate either way (in this mail, at this time), just a quick technical note: In fact, the RIPE DB mirrors the AFRINIC IRR data, so you at least as far as AFRINIC goes, provided there is IRR data in the AFRINIC DB, you can get it by querying the RIPE DB with the correct 'source:' > > Cheers, > Daniel > > >

1 0

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

11 Oct '17

On 11/10/2017, 14:09, Job Snijders via db-wg typed: > You > as network operator can easily poll the APNIC or AFRINIC database. > There are even a number of "IRR aggregation services" such as NTTCOM > and RADB which mirror a ton of IRRs for your querying convenience. Without commenting on the debate either way (in this mail, at this time), just a quick technical note: In fact, the RIPE DB mirrors the AFRINIC IRR data, so you at least as far as AFRINIC goes, provided there is IRR data in the AFRINIC DB, you can get it by querying the RIPE DB with the correct 'source:' Cheers, Daniel

1 0

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

11 Oct '17

Hi Randy, On Tue, Oct 10, 2017 at 4:27 PM, Randy Bush via db-wg <db-wg(a)ripe.net> wrote: > From: Randy Bush <randy(a)psg.com> > To: Nick Hilliard <nick(a)foobar.org> > Cc: Database WG <db-wg(a)ripe.net> > Date: Tue, 10 Oct 2017 23:26:34 +0900 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? >>>>> Question - Should the RIPE Database allow creation of ROUTE objects >>>>> for non RIPE resources? >>> >>> yes >> >> then how can we use the traditional irrdb to distinguish between address >> blocks which have been authenticated by the ripe ncc and those which >> have not. > > as you said, it would be good to have an strongly authenticated > ownership which could assert routing. try the rpki; works across > all regions. You are right, RPKI does fit the bill in a number of ways, and I look forward to the operators taking advantage of the good bits. However this does not preclude the RIPE community from improving the quality of another commonly used source: IRR. As you know there are only 2 or 3 networks on this planet using RPKI in their operations, while I can point at many more networks using IRR to build their whitelists for provisioning. As you know there is a feature gap between IRR and RPKI. RPKI doesn't have an "AS-SET"-like replacement, and not all the RPKI TALs are as easy to obtain as their equivalent IRR data. > a least it's a more credible argument than thinking encouraging ipv4 > run-out will increase ipv6, as opposed to nat, uptake. < dripping > sarcasm > OK, this seems off topic. Kind regards, Job

1 0

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

11 Oct '17

On Tue, Oct 10, 2017 at 4:51 PM, Piotr Strzyzewski via db-wg <db-wg(a)ripe.net> wrote: > From: Piotr Strzyzewski <Piotr.Strzyzewski(a)polsl.pl> > To: Database WG <db-wg(a)ripe.net> > Date: Tue, 10 Oct 2017 16:50:45 +0200 > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision? > On Mon, Oct 09, 2017 at 07:43:13PM +0200, Gert Doering via db-wg wrote: >> On Mon, Oct 09, 2017 at 03:48:43PM +0200, denis walker via db-wg wrote: >> > Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? >> >> I wonder if this is the right question to ask, or we should step back >> and ask the question >> >> what can we do to provide a secure routing registry where people >> can document "this prefix will be announced by that AS" in a way >> that is a) strongly authenticated (= only the current holder of the >> address space can create such a route: object), and b) easy to use >> for people building filters (= not having to walk 5 different IRRDBs >> to find the set of prefixes announced by a possible customer)? >> >> instead? A, B or C may be a consequence of this. >> >> >> In any case, given that we have no proper global registry, and we have >> lots of cross-region routes ("addresses from RIR A, AS number from RIR B"), >> we need to find a way to document these properly. >> >> From a user perspective, I like to have all route: objects for my customers >> in a single place (RIPE BD, that is), so for me, "A" would be most convenient >> - but we need to add some sort of cross-RIR authentication layer. > > +1 > > Piotr Hi Piotr, Gert, Group, It seems strange to allow "route:' objects covering APNIC- or AFRINIC-managed space in the RIPE DB, just for your "convenience". You as network operator can easily poll the APNIC or AFRINIC database. There are even a number of "IRR aggregation services" such as NTTCOM and RADB which mirror a ton of IRRs for your querying convenience. The "convenience" argument seems a slippery slope: as your customer base grows, you'll be encouraging more and more non-RIPE space to end up in the RIPE database (even though it could be in an authenticated source such as APNIC). Why? To what benefit? Why would you be supportive of the continuation of type of pollution? Isn't a simpler solution to drop the "origin:" attribute verification and only authenticate against the "inetnum:" authentication hierarchy? This way an ARIN-managed ASN can easily register RIPE-managed space in the RIPE database and it would be strongly authentication against the "inetnum:" I think that RIPE managed space belongs in the RIPE database, however non-RIPE-managed space (APNIC, AFRINIC, ARIN, LACNIC, chunks of legacy) have no place here since we cannot authenticate them. Kind regards, Job

1 0

RIPE Access Account: Cannot change registered e-mail address back to previously one
by Christoffer Hansen 10 Oct '17

10 Oct '17

RIPE Database Working Group <db-wg(a)ripe.net> Am I the only one who have previously wondered about the following issue... (?) 1. Register a RIPE Access Account with [account_1(a)example.com] 2. is changed to [account_2(a)example.com] 3. later tries to change registered RIPE Access Account e-mail back to [ account_1(a)example.com]. I'am not allowed to do this. RIPE NCC's website simply does *not* allow me to do this. Refer to the following pictures for clarification. *Changing the e-mail address back to [account_1(a)example.com <account_1(a)example.com>]* *× * *Creating a new RIPE Access Account for [account_1(a)example.com <account_1(a)example.com>]* *× Trying the forgotten password function for [account_1(a)example.com <account_1(a)example.com>]* *× * Regards, Christoffer Hansen. gpg: c8b3 82a8 a1cd cdb7 71fe b24c c654 948f da86 becd

1 0

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

10 Oct '17

On Mon, Oct 09, 2017 at 07:43:13PM +0200, Gert Doering via db-wg wrote: > On Mon, Oct 09, 2017 at 03:48:43PM +0200, denis walker via db-wg wrote: > > Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? > > I wonder if this is the right question to ask, or we should step back > and ask the question > > what can we do to provide a secure routing registry where people > can document "this prefix will be announced by that AS" in a way > that is a) strongly authenticated (= only the current holder of the > address space can create such a route: object), and b) easy to use > for people building filters (= not having to walk 5 different IRRDBs > to find the set of prefixes announced by a possible customer)? > > instead? A, B or C may be a consequence of this. > > > In any case, given that we have no proper global registry, and we have > lots of cross-region routes ("addresses from RIR A, AS number from RIR B"), > we need to find a way to document these properly. > > From a user perspective, I like to have all route: objects for my customers > in a single place (RIPE BD, that is), so for me, "A" would be most convenient > - but we need to add some sort of cross-RIR authentication layer. +1 Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland

1 0

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

10 Oct '17

Randy Bush via db-wg wrote: >> > Question - Should the RIPE Database allow creation of ROUTE objects >> > for non RIPE resources? > > yes then how can we use the traditional irrdb to distinguish between address blocks which have been authenticated by the ripe ncc and those which have not. Nick

2 1