On Tue, Oct 10, 2017 at 4:51 PM, Piotr Strzyzewski via db-wg <db-wg@ripe.net> wrote:

From: Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> To: Database WG <db-wg@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