- db-wg - mailman.ripe.net

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

Re: Foreign ROUTE objects in RIPE Database - final decision?
by Alexander Stranzky 09 Oct '17

09 Oct '17

personal opinion: I don't care as a programmer. company's opinion: A - all our network resources are routed solely through our RIPE-AutNum. -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

1 0

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

09 Oct '17

Hello Denis, WG On Mon, 2017-10-09 at 15:49 +0200, denis walker via db-wg wrote: > A: Yes the RIPE Database should allow creation of ROUTE objects for > non RIPE resources. If this is the answer then we can look at how to > make the data more trusting in the short term (and there may be ways > to do that). 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. -- Clément Cavadore

1 0

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

09 Oct '17

Denis, 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? > >A: Yes the RIPE Database should allow creation of ROUTE objects >for non RIPE resources. If this is the answer then we can look >at how to make the data more trusting in the short term (and >there may be ways to do that). > >B: No the RIPE Database should not allow creation of ROUTE >objects for any non RIPE resource. If this is the answer then >maybe we need to look at a project to remove all non RIPE >resource related ROUTE(6)/AUT-NUM objects from the RIPE Database >and disable the feature. But that needs to look at what to do >with ROUTE objects for prefixes from one region and ASNs from a >different region. > >C: Just leave things as they are. Don't promote the service but >no projects to remove any data from the RIPE Database either. >Just drift along on the principle "if it ain't broken, don't fix >it". This also means document this as the answer to this >question and no more discussions. Of course any problems >associated with this feature don't go away. Either A or C, insofar as they are different. 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. One could make an argument for not allowing route: objects where both the prefix and ASN are from outside RIPE. This would complicate (or make impossible) any attempt at automating acceptance filters, unless and until this information is available from other (trusted?) sources. As it currently stands, this would, on balance, be worse for the "good of the internet". cheers, Sascha Luck

1 0