- db-wg - mailman.ripe.net

Re: [db-wg] out of region routing in the RIPE Database
by Daniel Shaw 11 Aug '17

11 Aug '17

On 11/08/2017, 05:14, Randy Bush via db-wg typed: > >> >> databases. It's that they never have, and it's just the "way things >> have been done". It's always ended up that they *can* support multiple >> databases if asked to. > > when negotiating with a prospective peer, i would rather not add "you > will have to change operational practice and code for this to work." That is a good point. I would also rather not, generally. And that is the basis of my original fears around this something like a year ago. What I found in practise (so far) has been that when stated not as "you will *have* to change operations", but as "would it be possible for you to change operations for me?", the answer has usually been "Ok". I have to be honest, that was a surprise. - Daniel

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Randy Bush 10 Aug '17

10 Aug '17

> That has proven to never really be an issue. When a network upstream > of another network says they don't support additional databases for > IRR, so far that has always proven to actually mean they've never > needed to think about supporting multiple databases, and never had the > demand to do the work to change that. > > In other words, it's not that they *can't* support other > databases. It's that they never have, and it's just the "way things > have been done". It's always ended up that they *can* support multiple > databases if asked to. when negotiating with a prospective peer, i would rather not add "you will have to change operational practice and code for this to work." randy

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Daniel Shaw 10 Aug '17

10 Aug '17

Hi there, On 09/08/2017, 19:34, Stefan Ideler via db-wg typed: > > > As a result our route objects regardless of origin are noted in the RIPE database. Our upstreams use it to generate their prefix filters (and not all of them support multiple databases) I won't comment here on your specific use case or the overall reasoning or motivation for wanting to use the RIPE DB exclusively, even for resources that may come from various other regions. I have an opinion, but it's just that. An opinion. What I'd like to comment on is the excerpt above. Specifically about upstream providers not supporting multiple databases. That has proven to never really be an issue. When a network upstream of another network says they don't support additional databases for IRR, so far that has always proven to actually mean they've never needed to think about supporting multiple databases, and never had the demand to do the work to change that. In other words, it's not that they *can't* support other databases. It's that they never have, and it's just the "way things have been done". It's always ended up that they *can* support multiple databases if asked to. I speak from experience here. If you go back into the archives of this list, when this issue was first brought to the list, I responded with this exact fear: But what about the upstream support? Since then I've had the opportunity to speak to folks from some of the larger networks that are often someone's upstream on behalf of AFRINIC members from time to time, and also in my own capacity in the context of an RIR meeting event network. We've also encouraged member operators to just ask their upstreams to change. And this has proved to never have remained an issue to the best of my knowledge. Summary: While you may (or may not) have other good reasons for the RIPE DB to be open (or not), upstream support of alternates is not likely one of the reasons. Best regards, Daniel

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Nick Hilliard 09 Aug '17

09 Aug '17

Stefan Ideler via db-wg wrote: > Being a member of multiple RIR's, the Ripe db is user friendly and a > scriptable database. I don't want to divide my as-sets and prefix > filter generation over 3 or more different database systems, with > the additional maintenance and in some cases even less verification. > Atleast my RIPE originating objects are secure and they make up the > majority of my prefixes. > > As a result our route objects regardless of origin are noted in the > RIPE database. Our upstreams use it to generate their prefix filters > (and not all of them support multiple databases) and as a result we > require all our downstream customers to have their AS/route objects > within the RIPE database as well. Several years ago, we planned this sort of approach via IXP Manager, but when we wrote the code to do it, we realised that this was a very limited and limiting mechanism for handling prefix list generation. It caused a lot of extra work for us in terms of support requirements and explaining to people that they had to do this. Several member organisations refused to comply and said they had no intention of changing their policies. The result of this was that we ended up not carrying traffic that we could alternatively have carried, and we annoyed our members. Not the best idea, in retrospect. We ended up having to be a lot more flexible on the issue. The best way we found to handle it was to allow any customer to be associated with any arbitrary IRR policy. E.g. one customer could use source: RIPE, ARIN and RADB, and another could use LACNIC, ALTDB and LEVEL3. It's actually pretty straightforward to implement this, and gives the advantage that you're no longer creating extra work for customers by forcing them to register their route: objects in IRRDBs where they wouldn't otherwise do so. The code for this is freely available on github.com/inex/IXP-Manager. I'm mentioning this because there is a serious security problem associated with permitting out-of-region objects in the RIPE database: this causes repeated, serious security problems with routing leakage on the Internet. This feature is being persistently abused by scammers and other criminals and is devaluing the integrity of the data in the RIPE IRRDB. Unless this problem is fixed, it's going to continue to be a problem indefinitely. We cannot fix it unless people fix their code. Nick

1 0

Re: out of region routing in the RIPE Database
by Stefan Ideler 09 Aug '17

09 Aug '17

Hi, > I would like to have the IRR kept open, we have space from various > regions and need to be able to make use of a single well known IRR in > order to register our policies and be able to mix our ASNs with our > space. >This might indeed be the way forward for "I have a customer in my RIPE >AS which has APNIC space and wants to document that in a way that that >provisioning tools can pick this with sufficient trust on data quality". I agree with the above. Being a member of multiple RIR's, the Ripe db is user friendly and a scriptable database. I don't want to divide my as-sets and prefix filter generation over 3 or more different database systems, with the additional maintenance and in some cases even less verification. Atleast my RIPE originating objects are secure and they make up the majority of my prefixes. As a result our route objects regardless of origin are noted in the RIPE database. Our upstreams use it to generate their prefix filters (and not all of them support multiple databases) and as a result we require all our downstream customers to have their AS/route objects within the RIPE database as well. As such I oppose removing the functionality to register "foreign route objects" and instead support that a proper verification solution between the different RIR's should be implemented (some examples described in this thread). Regards, Stefan Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Tim Bruijnzeels 07 Aug '17

07 Aug '17

Dear working group, We will come back with a more detailed implementation time line later this week. Informally speaking we expect that we can do the technical work to prepare the phase-1 whois release in the coming weeks. We will probably have to plan the clean-up after the holidays. But, we will get back to you once we have a more definite plan. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 4 Aug 2017, at 14:39, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation plan > Date: 3 August 2017 at 21:12:06 GMT+2 > To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> > > > Working group members, > > Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". > > At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation. > > Kind Regards, > > DB-WG Chairs > > > > >

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Lu Heng 04 Aug '17

04 Aug '17

Hi, I would like to have the IRR kept open, we have space from various regions and need to be able to make use of a single well known IRR in order to register our policies and be able to mix our ASNs with our space. It is very convenient to be able to use the RIPE IRR for that. I do see that authentication/verification against other RIR's Database is not done at the moment and can be abused and will support any simple mechanism put in place in order to fix that issue. But closing the IRR down for out of region resources far outweighs the negative side effects seen by typos and abuses that comes through from time to time. On 20 July 2017 at 15:41, Gert Doering via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Gert Doering <gert(a)space.net> > To: Sander Steffann <sander(a)steffann.nl> > Cc: George Michaelson <ggm(a)algebras.org>, denis walker < > ripedenis(a)yahoo.co.uk>, Database WG <db-wg(a)ripe.net> > Bcc: > Date: Thu, 20 Jul 2017 09:41:09 +0200 > Subject: Re: [db-wg] out of region routing in the RIPE Database > Hi, > > On Tue, Jul 18, 2017 at 04:10:52PM +0200, Sander Steffann via db-wg wrote: > > > its a broken process. it inherently permits things to be said, which > > > should not have been said. > > > > Time to set up a joint IRR database where only authoritative data from > participating RIRs is stored? > > This might indeed be the way forward for "I have a customer in my RIPE > AS which has APNIC space and wants to document that in a way that that > provisioning tools can pick this with sufficient trust on data quality". > > (And no, RADB is not) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > -- -- Kind regards. Lu

2 1

NWI-7: abuse-c implementation plan
by William Sylvester 03 Aug '17

03 Aug '17

Working group members, Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation. Kind Regards, DB-WG Chairs

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Sebastian Wiesinger 27 Jul '17

27 Jul '17

* Gert Doering via db-wg <db-wg(a)ripe.net> [2017-07-20 09:42]: > > > its a broken process. it inherently permits things to be said, which > > > should not have been said. > > > > Time to set up a joint IRR database where only authoritative data from participating RIRs is stored? > > This might indeed be the way forward for "I have a customer in my RIPE > AS which has APNIC space and wants to document that in a way that that > provisioning tools can pick this with sufficient trust on data quality". Yes please! Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Call for Agenda Items DB-WG Meeting - RIPE75 - Dubai, UAE
by William Sylvester 25 Jul '17

25 Jul '17

Dear DB-WG Members, This is the call for agenda items for the DB-WG Meeting at RIPE75 at the Conrad Dubai in Dubai, UAE. Please submit agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net> The DB-WG Meeting is scheduled for Wednesday, October 25th, starting at 14:00 local time, after lunch and before the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 74 meeting plan please refer to its most up-to-date version at https://ripe75.ripe.net/programme/meeting-plan/ Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements We are looking forward to another successful meeting in Dubai. Kind regards, William, Denis, & David DB WG Chairs

1 0