- db-wg - mailman.ripe.net

out of region routing in the RIPE Database
by denis walker 18 Jul '17

18 Jul '17

Hi Daniel and others Just for the record I have followed all previous discussions on this issue over many years within the RIPE community. There have been many (opposing) views expressed. I don't recall any consensus within the RIPE community to expel all, or even just Afrinic, (foreign) ROUTE objects from the RIPE Database. If I did miss that, maybe someone can point me to the message on this or the ROUTING WG mailing lists where that consensus was drawn. Does Afrinic have a mandate, with a clear consensus, from the Afrinic community for the migration of all Afrinic ROUTE objects from the RIPE Database to the Afrinic Database? Has either community agreed anything on the (re)creation of Afrinic ROUTE objects in the RIPE Database? I have no personal interest in this either way. I just want to be clear what the current position is so we can move forward. cheersdenisco-chair DB-WG From: Daniel Shaw via db-wg <db-wg(a)ripe.net> To: Database WG <db-wg(a)ripe.net> Sent: Tuesday, 18 July 2017, 16:39 Subject: Re: [db-wg] out of region routing in the RIPE Database On 18/07/2017, 15:26, Nick Hilliard via db-wg typed: > > > There are two main ways to fix this problem: > > 1. change all non-RIPE address space to have a different source: tag > > 2. remove all non-RIPE address space completely > > There is some previous discussion about this issue on db-wg, and IIRC, > the WG suggestion was to go for option #2. > > On that basis, again IIRC, there was a suggestion to handle this in a > phased way, starting off with the lowest hanging fruit first. As > Afrinic objects formed the largest share of all out-of-region objects in > the ripedb, they were targeted first. Hello WG, That matches my recollection too. And so I'll re-iterate that, as previously mentioned on this list, this neatly matches up with some parallel goals within AFRINIC. Which is that regardless, we see an advantage in having our membership manage their IRR along with RDNS and RPKI and other registry interactions in one place under one authentication. Simpler. And we also see an advantage in general growth in usage of the AFRINIC IRR by our membership, as it's a service we already provide and will maintain and scale as needed in any case. And so, we do already provide tooling to our membership to assist them moving objects into the AFRINIC DB easily. We do liaise with upstream operators of our members when they have in the past implied a requirement for RIPE DB IRR objects. And our hostmasters also do run bootcamp tutorials at nog and other events to encourage migration of objects. In summary there is ongoing work that matches with migrating non-RIPE, AFRINIC route(6) objects underway. I will add that this is a long and slow process however. The work is done as convenient. And for now, only applies where both the IPv{4,6} an AS resources are within the AFRINIC region. The movement is slow. But in the direction of moving AFRINIC resources away from RIPE DB. Regards, Daniel

1 0

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

18 Jul '17

On 18/07/2017, 15:26, Nick Hilliard via db-wg typed: > > > There are two main ways to fix this problem: > > 1. change all non-RIPE address space to have a different source: tag > > 2. remove all non-RIPE address space completely > > There is some previous discussion about this issue on db-wg, and IIRC, > the WG suggestion was to go for option #2. > > On that basis, again IIRC, there was a suggestion to handle this in a > phased way, starting off with the lowest hanging fruit first. As > Afrinic objects formed the largest share of all out-of-region objects in > the ripedb, they were targeted first. Hello WG, That matches my recollection too. And so I'll re-iterate that, as previously mentioned on this list, this neatly matches up with some parallel goals within AFRINIC. Which is that regardless, we see an advantage in having our membership manage their IRR along with RDNS and RPKI and other registry interactions in one place under one authentication. Simpler. And we also see an advantage in general growth in usage of the AFRINIC IRR by our membership, as it's a service we already provide and will maintain and scale as needed in any case. And so, we do already provide tooling to our membership to assist them moving objects into the AFRINIC DB easily. We do liaise with upstream operators of our members when they have in the past implied a requirement for RIPE DB IRR objects. And our hostmasters also do run bootcamp tutorials at nog and other events to encourage migration of objects. In summary there is ongoing work that matches with migrating non-RIPE, AFRINIC route(6) objects underway. I will add that this is a long and slow process however. The work is done as convenient. And for now, only applies where both the IPv{4,6} an AS resources are within the AFRINIC region. The movement is slow. But in the direction of moving AFRINIC resources away from RIPE DB. Regards, Daniel

1 0

Re: [db-wg] out of region routing in the RIPE Database
by George Michaelson 18 Jul '17

18 Jul '17

On Tue, Jul 18, 2017 at 4:10 PM, Sander Steffann via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Sander Steffann <sander(a)steffann.nl> > To: George Michaelson <ggm(a)algebras.org> > Cc: Nick Hilliard <nick(a)foobar.org>, Database WG <db-wg(a)ripe.net>, denis walker <ripedenis(a)yahoo.co.uk> > Bcc: > Date: Tue, 18 Jul 2017 16:10:09 +0200 > Subject: Re: [db-wg] out of region routing in the RIPE Database > Hi George, > >> I think the previously stated position from APNIC region is clear: we >> have problems with the logistics which permit resources from our >> region to be included in IRR statements in the RIPE DB, when no formal >> check is made of permission or integrity, and we do not see any clear >> path to a deployable mechanism to provide authorization checks over >> resources from out of region. >> >> 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? Not a bad idea, I wouldn't oppose. Why do we have the NRO, if not to coordinate these kind of things? -George

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Sander Steffann 18 Jul '17

18 Jul '17

Hi George, > I think the previously stated position from APNIC region is clear: we > have problems with the logistics which permit resources from our > region to be included in IRR statements in the RIPE DB, when no formal > check is made of permission or integrity, and we do not see any clear > path to a deployable mechanism to provide authorization checks over > resources from out of region. > > 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? Cheers, Sander

1 0

Re: [db-wg] out of region routing in the RIPE Database
by George Michaelson 18 Jul '17

18 Jul '17

as a passive (mostly) participant, this is mostly my recollection too. as a non passive participant... I think the previously stated position from APNIC region is clear: we have problems with the logistics which permit resources from our region to be included in IRR statements in the RIPE DB, when no formal check is made of permission or integrity, and we do not see any clear path to a deployable mechanism to provide authorization checks over resources from out of region. its a broken process. it inherently permits things to be said, which should not have been said. if some strong checks can be created, and if a remote DB referential integrity issue can be resolved, I think we could discuss this. If the intention is to continue using open maintainer to add any non-RIPE resource? thats a really bad model. -George On Tue, Jul 18, 2017 at 3:25 PM, Nick Hilliard via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Nick Hilliard <nick(a)foobar.org> > To: denis walker <ripedenis(a)yahoo.co.uk> > Cc: Database WG <db-wg(a)ripe.net> > Bcc: > Date: Tue, 18 Jul 2017 14:25:05 +0100 > Subject: Re: [db-wg] out of region routing in the RIPE Database > denis walker via db-wg wrote: >> We would like to start off the (final?) round of discussions on this >> topic with a question. Should the RIPE Database be used as an open, >> free, global Internet Routing Registry (IRR)? If the answer is 'yes' >> then perhaps we should allow the routing policy of any global resource >> to be documented in the RIPE Database as a choice by the resource holder >> and move on to address the issues surrounding this process. If the >> answer is 'no' then perhaps we shouldn't allow any routing policy for >> any non RIPE resources (not selectively try to expel one group of ROUTE >> objects). > > I am not in favour of having the RIPE database as an open-access > database on the basis that this mixes up two sets of data, authoritative > and non-authoritative, and it it is impossible for someone casually > querying the database to determine which is which. > > Some people are inserting random route: objects into the database, and > those route: objects are being picked up by provisioning systems and > ending up configured on routers and IXP route servers. This enables > prefix hijacking, which is a pressing operational issue. > > There are two main ways to fix this problem: > > 1. change all non-RIPE address space to have a different source: tag > > 2. remove all non-RIPE address space completely > > There is some previous discussion about this issue on db-wg, and IIRC, > the WG suggestion was to go for option #2. > > On that basis, again IIRC, there was a suggestion to handle this in a > phased way, starting off with the lowest hanging fruit first. As > Afrinic objects formed the largest share of all out-of-region objects in > the ripedb, they were targeted first. I believe the plan was to > continue on after that with other categories of objects. This > recollection may be wrong. > > Nick > >

1 0

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

18 Jul '17

denis walker via db-wg wrote: > We would like to start off the (final?) round of discussions on this > topic with a question. Should the RIPE Database be used as an open, > free, global Internet Routing Registry (IRR)? If the answer is 'yes' > then perhaps we should allow the routing policy of any global resource > to be documented in the RIPE Database as a choice by the resource holder > and move on to address the issues surrounding this process. If the > answer is 'no' then perhaps we shouldn't allow any routing policy for > any non RIPE resources (not selectively try to expel one group of ROUTE > objects). I am not in favour of having the RIPE database as an open-access database on the basis that this mixes up two sets of data, authoritative and non-authoritative, and it it is impossible for someone casually querying the database to determine which is which. Some people are inserting random route: objects into the database, and those route: objects are being picked up by provisioning systems and ending up configured on routers and IXP route servers. This enables prefix hijacking, which is a pressing operational issue. There are two main ways to fix this problem: 1. change all non-RIPE address space to have a different source: tag 2. remove all non-RIPE address space completely There is some previous discussion about this issue on db-wg, and IIRC, the WG suggestion was to go for option #2. On that basis, again IIRC, there was a suggestion to handle this in a phased way, starting off with the lowest hanging fruit first. As Afrinic objects formed the largest share of all out-of-region objects in the ripedb, they were targeted first. I believe the plan was to continue on after that with other categories of objects. This recollection may be wrong. Nick

1 0

out of region routing in the RIPE Database
by denis walker 18 Jul '17

18 Jul '17

Colleagues The DB-WG co-chairs would like to try to resolve (or close and document that as a consensus) another long standing issue, out of region ROUTE(6) and AUT-NUM objects in the RIPE Database (NWI-5). We would like to start off the (final?) round of discussions on this topic with a question. Should the RIPE Database be used as an open, free, global Internet Routing Registry (IRR)? If the answer is 'yes' then perhaps we should allow the routing policy of any global resource to be documented in the RIPE Database as a choice by the resource holder and move on to address the issues surrounding this process. If the answer is 'no' then perhaps we shouldn't allow any routing policy for any non RIPE resources (not selectively try to expel one group of ROUTE objects). cheers denis co-chair DB-WG

1 0

Re: [db-wg] org field in the organisation object
by denis walker 13 Jul '17

13 Jul '17

Hi Sergey The original design of the ORGANISATION object was to allow for them to be used hierarchically. So there could be a chain of trust between organisations. But nothing was ever implemented in that way. cheersdenisco-chair DB-WG From: Sergey Myasoedov via db-wg <db-wg(a)ripe.net> To: DB-WG <db-wg(a)ripe.net> Sent: Thursday, 13 July 2017, 17:18 Subject: [db-wg] org field in the organisation object Dear Working Group, What is the goal of the org field in the organisation object? Thank you. -- Kind regards, Sergey Myasoedov

1 0

org field in the organisation object
by Sergey Myasoedov 13 Jul '17

13 Jul '17

Dear Working Group, What is the goal of the org field in the organisation object? Thank you. -- Kind regards, Sergey Myasoedov

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Andreas Worbs 11 Jul '17

11 Jul '17

Yes, go ahead :) Am 11.07.17 um 09:02 schrieb denis walker via db-wg: -- Mit freundlichem Gruß Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

1 0