- db-wg - mailman.ripe.net

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

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

10 Oct '17

> But this time we do need numbers. voting, eh? > Question - Should the RIPE Database allow creation of ROUTE objects > for non RIPE resources? yes randy

1 0

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

10 Oct '17

On Tue, Oct 10, 2017 at 18:33 Sander Steffann via db-wg <db-wg(a)ripe.net> wrote: > Hi, > > > 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. > > My preference would be to start such a global registry. I would love it if > at least RIPE, APNIC and AFRINIC (who all use very similar data models > IIRC) could combine databases. Having separate (but in reality partially > overlapping) databases for a global resource will always result in > discussions like we have had over the last two+ years IMHO. Let's make an > effort to form a single point of reference. > +1 > > Cheers, > Sander > > > -- -- Kind regards. Lu

1 0

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

10 Oct '17

Hi, > 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. My preference would be to start such a global registry. I would love it if at least RIPE, APNIC and AFRINIC (who all use very similar data models IIRC) could combine databases. Having separate (but in reality partially overlapping) databases for a global resource will always result in discussions like we have had over the last two+ years IMHO. Let's make an effort to form a single point of reference. Cheers, Sander

1 0

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

09 Oct '17

Clement Cavadore via db-wg wrote: > That one, but with a *strong* enhancement on a trust model for such > objects. We just cannot simply allow non-ripe route objects to be > inserted in the db without any legitimity checks. there is no way which non-ripe route objects can be subjected to legitimacy checks. It can't be done because several other RIRs don't provide the authentication hooks to be able to do this. On the question of this work item, what I would like is a mechanism to distinguish between route objects which have been verified using the trust grandfathering mechanism deployed by the RIPE NCC, and those which have not. There are many ways of doing this, e.g. 1. Option B: remove all non RIPE objects from the db. 2. use different source: tags to distinguish between ripe space and non ripe space. 3. leave whois.ripe.net as it is, and create a different database consisting of only authenticated route: objects. 4. leave whois.ripe.net as it is and create a different database view which, if queried, will return only objects which have been authenticated. Options for handling this might include: 4.1. same db on different hostname providing a different view 4.2. a new ripe-181++ tag identifying authenticated objects My preferences in order are: 2, then 4.2, then 4.1, then 3, then 1. No doubt there are plenty of other ways to crack this particular nut. Denis's description of Option C perpetuates what is a operational problem which has serious and ongoing consequences in the area of prefix hijacking. It would not be realistic to characterise the current situation as "if it ain't broke...", because it is identifiably broken, and it is this breakage which has led to this discussion. If we could solve this problem in a way which was operationally portable to other RIRs, that would be a bonus. Nick

1 0

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

09 Oct '17

Hi, 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. 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

1 0

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

09 Oct '17

On 09/10/2017 18:22, denis walker via db-wg wrote: C -Hank

1 0