Hi all, this work item in the Database Working Group is also very relevant to this one. Comments on whether this is an accurate description of the problem we’re trying to solve when we look at out-of-region routing registry objects in the RIPE database should be sent to <db-wg@ripe.net>. Cheers, Rob Forwarded message:

From: Job Snijders <job@instituut.net> To: db-wg@ripe.net Subject: [db-wg] NWI-5 - Out of region ROUTE(6) / AUT-NUM objects Date: Wed, 25 May 2016 15:48:04 +0200

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