- db-wg - mailman.ripe.net

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