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 <[email protected]>.
Cheers,
Rob
Forwarded message:
From: Job Snijders <[email protected]>
To: [email protected]
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
