[db-wg] Foreign ROUTE objects in RIPE Database - final decision?

On Tue, Oct 10, 2017 at 4:51 PM, Piotr Strzyzewski via db-wg
<db-wg at ripe.net> wrote:
> From: Piotr Strzyzewski <Piotr.Strzyzewski at polsl.pl>
> To: Database WG <db-wg at 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