[db-wg] NWI-5 - Out of region ROUTE(6) / AUT-NUM objects

Dear Working Group,

This is a slighly longer problem statement, please bear with us.

There has been a LOT of discussion about the problems related to
out-of-region ROUTE(6) and AUT-NUM objects in the RIPE Database. We
would like to provide a starting point of the problem definition here,
and ask the community to discuss it further.

NWI-5 - Out of region ROUTE(6) / AUT-NUM objects
----------

The RIPE Database Internet Routing Registry (IRR) requires authorisation
to create ROUTE(6) objects, by the appropriate maintainer for the
covering inet(6)num object - or an existing covering ROUTE(6) object for
the prefix in the "route(6):" attribute, as well as the appropriate
maintainer for aut-num object matching the "origin:".

For resources within the RIPE region this authorisation is covered by
either:

    * Objects that RIPE NCC creates upon assigning or allocating
    resources to LIRs or end-users with a sponsoring LIR
    * Objects held by legacy resource holders
    (authorisation may be delegated to others by holders of these objects)

However for out-of-region space the authorisation is different. Because
out-of-region resources are not maintained in the RIPE Database there
are no proper maintainers in the RIPE Database to authorise the creation
of such objects. Because there is a need for having ROUTE(6) objects for
these routes, and there were no authoritative alternative IRRs
available, the RIPE community decided to support the creation of these
objects in the RIPE Database IRR through the use of placeholder objects
for out-of-region IP resources and ASNs.

In case of IP resources the INET(6)NUM objects delegate authorisation to
create route objects through "mnt-routes:" to a special use maintainer
with a well-known password: RIPE-NCC-RPSL-MNT.

In case of out-of-region ASNs the RIPE NCC maintains placeholder
AS-BLOCK objects. Since "mnt-routes:" does not exist on AS-BLOCK objects
the RIPE-NCC-RPSL-MNT is added to "mnt-lower:" here instead. Any user of
the database can therefore create a AUT-NUM object for an out-of-region
ASN, and use it to authorise ROUTE(6) objects.

There are a number of problems resulting from this approach:
    * Authorisation for out-of-region objects is anecdotal
    * Globally duplicate AUT-NUM objects are required for out-of-region
        ASNs, confusing contact information, policy etc
    * This facilitates hijacking for out-of-region resources and RIPE
        NCC is neither mandated nor staffed to deal with these issues.
    * Detailed placeholders need to be maintained, which causes overhead
        especially w.r.t. inter-RIR transfers
---------

We invite the working group to better define this problem definition so
that a structured discussion about (partial) solutions can follow.

Kind regards,

Job