I think that it is wrong to exclude use of the RPKI signed assertion of authority over a resource to drive admission of foreign records. I do not speak to RPSL per se or ROA, but the fact is that maintainer status is not visible in routing and is irrelevant. Databases need ACL and admission control but we all know the RIPE code has (and always has had) a privileged channel which can effect change in the contents of the schema without first class use of the authorization primitives: heck you can type SQL commands directly and make objects

So I like much of what Wilfred said in terms of its intent and outcome. I do not agree that ab initio we should reject use of RPKI signed objects to permit import and export of external information.

If I sign an authorization to somebody to include my resources in their IRR, and my resources are in the certificate which signed that authorization what can be stronger?

-G

On 14 November 2014 06:59, Elvis Daniel Velea <elvis@velea.eu> wrote:

Hi Wilfried,

finally someone responding to the problem presented. I was about to
think that nobody cares anymore.

On 14/11/14 16:18, Wilfried Woeber wrote:
> Michael Horn wrote: (to anti-abuse-wg@ripe.net)
>
> [...]
>
>> will result in significant workload. Holy dingus, is this database a mess...
> And not just "this" one. The whole "Routing Registry" stuff is an incredible
> mess, and since years, actually. Not really a Numbers Registry failure or a
> negligence, but rather a multi-faceted mesh of FUD, History and Trade Secrets
> claimed.
>
> Let me try to collect some facts, at least according to my memory.
> Please correct me where I'm wrong...
>
> - not all 5 RIRs actually do support an IRR functionality.
>
> - the RPSL doc.set, back in the good old days, had some ideas and provisions
> for integrating the 5 (or then, rather 3, iirc) pieces of Numbers Registries
> into a single, global, consistent structure.
> As Gert put it: it didn't fly.
> Since then, we were putting band-aid over patch over whatever to deal with
> that. The result is what we have before us, right now.
>
> - the whole system of creating objects, at least in the RIPE Region, has become
> totally inconsistent. For an address block, where the RIPE DB is authoritative,
> and an AS number, you need the credentials from both parties to register a route:
> or route6: object.
>
> for out-of-region authoritative entries, the dreaded maintainer was created, in
> order to provide the (useless) 2nd auth: token.
>
> For the RPKI stuff, again, there isn't a requirment for a second authentication
> token, iirc not even a *notification* to the AS ref.d, when an RoA is created.
> Anyone of you still thinks RPKI is going to be helpful here?
> Bah, it's just going to give another false impression of credibility + new vectors
> for errors and attacks.
>
>> -mh
> The only way(s) forward I can see are:
>
> - require manual approval of route: objects for the case of out-of-region registrations

sounds like an other patch, one that I would welcome as a temporary
solution.
>
> - get the RPSL flaws fixed, the RFCs updated and then implemented
this will probably take years..
>
> - integrate the 5 Number Registries into a homogenous, distributed DB with consistent
> authentication mechanisms
>
> - come up with a viable proposal for 1 (one!!) global routing registry that is
> authoritative, up-todate and complete, used by all operators (yes, I know, it is
> the wrong type of year /w a XMAS)
I've been asking myself for years why the RIRs can not, under the NRO,
ASO, IANA, (?) umbrellas to come up with a unique registry (resource +
routing).. It's not like the communities do not want/need it... Do we
need to pass a global policy to ask the RIRs to work together? :-)

A single source of information is, at this moment, a dream.
> - try to do any or all of the above and do so without RPKI requirements. Please!
>
> Wilfried.
>
regards,
elvis