[anti-abuse-wg] [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database

On Wed, Nov 11, 2015 at 02:52:36PM +0100, denis wrote:
> From what I understood from Gert and Randy's comments it is a user's
> choice where to put a ROUTE object and there seem to be some reasons
> why they sometimes choose to put it in the RIPE Database.

Be that as it may, I am not convinced (yet) that non-RIPE objects really
have a place in the RIPE db. Given that today there _are_ non-RIPE
objects in the RIPE db, we need to find a way to deal with those. All of
us hate rogue objects and want to nail down security in such a way that
the RIPE db no longer is a 'free for all to exploit' database. An
example of a functional IRR does not allow foreign objects: APNIC. I've
not heard of that policy leading to any issues.

Randy has asserted in the past that some parties (IXPs?) require people
to exclusively register in the RIPE database, but I have not found data
supporting that idea so far. Even if there is an IXP who operates a
route-server for which filters are build exclusively using RIPE's IRR
database, that is a local choice made by that IXP to not look at other
databases. I won't take a single IXP's decision to not look any further
as a strong incentive to put the whole world's IRR in the RIPE database.

Gert indicated that it might be beneficial for a single ASN to register
all their routes (including non-RIPE space) in a single database. Gert's
remark is a single datapoint, it is my personal opinion that there is no
operational issue if networks spread their route-object registrations
over multiple databases (e.g. APNIC space in APNIC IRR, RIPE space in RIPE
IRR, etc). 

The benefit of pushing users to the most authoritve database is that 3
out of 5 RIRs can offer strong guarantees about the validity of a
route-object if it covers space managed by that respective RIR. RIPE
cannot offer the same strong guarantees as APNIC & AfriNIC can in their
own IRR. Why would we not encourage the community to exploit those
guarantees, and direct users to create those 'foreign' route-objects in
the more authoritive IRR? 

> Is there some specific policy now that prohibits ROUTE objects in the
> RIPE Database for AFRINIC resources?

"IRR Homing" was influenced by two ideas: Nick Hilliard's "why don't we
change the 'source: RIPE' line to something like 'source: RIPE-NONAUTH'
for objects covering non-RIPE space" and the observation that there are
30.000 route-objects covering AfriNIC space in a database which
_does_not_ offer guarantees on their validity, while at the same time
there is a perfect IRR which _does_ offer those guarantees: AfriNIC's
own IRR.

At the time I thought it safer to first migrate AfriNIC's objects and
then consider changing the "source:" attribute for non-authoritive
objects.

So, no such policy exists, but the IRR Homing proposal (which is in the
making) will include the suggestion that creation of route-objects
covering AfriNIC space at some point is no longer allowed, and instead
people are referred to the AfriNIC IRR. As Tim mentioned, this is a
proposal and the DB-WG will be tasked with reviewing the plan.

Kind regards,

Job