Please see my comments below.

Op 15 aug. 2018, om 10:21 heeft Havard Eidnes via db-wg <db-wg@ripe.net> het volgende geschreven:

Hi,

following up on a particular point (only), dropping the
anti-abuse WG, but keeping the other two because it relates to
database authorization and the IRR:

More to the point, since when has it become a routine part of "day
to day operations" to have RIPE members flooding the RIPE data base
with blatant bovine excrement?

I guess one important reason is that in some specific cases it's
difficult to automate the distinction between what you refer to
as "bovine excrement" and legitimate route objects.

(This refers to your substantiated claim that fraudulent route
objects have been and are being registered in the IRR part of the
RIPE database.)

Looking at the description of the route object in the RIPE DB:

https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-5-description-of-the-route-object

and the authorization requirements at

https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/10-authorisation/10-7-protection-of-route-6-object-space

my understanding is that it describes that when "route" objects
are created which cover in-region address space, authorization is
requied from both the maintainer of the AS object as well as from
the maintainer of the address space, so registering in-region
route objects without the consent of the address space holder is
more or less prevented.

Indeed, but this is about to change. The RIPE DB Working Group has decided to remove AS authentication for ROUTE(6) objects. This will come into effect on the 4th of September 2018.

From then, only a prefix holder can create a ROUTE(6) object and can reference any AS number.

However, if the address space is out-of-region, the authorization
checks for the address space is dropped / ignored, and only the
authorization for the AS object is used, allowing the
registration of route objects without the consent of the address
space holder. I suspect it is this loop-hole which is being
abused to register the route objects you are mentioning.

Exactly, and part of the NWI-5 implementation is that from the 4th of September, it will not be possible anymore to create new out-of-region ROUTE(6) objects and AUTNUMs in the RIPE IRR.

This loophole will then be closed. All the out-of-region objects will remain in the RIPE IRR, but with a different “source:” attribute: RIPE-NONAUTH. Holders can still update and delete these objects, but not create new ones.

We have communicated these changes to all out-of-region object holders and the RIPE DB WG. Also we have communicated this to all other RIRs (most of them wrote articles about these upcoming changes and informed their members.

You can read the full implementation plan here:

https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation

I suspect that out-of-region route objects in the RIPE DB are an
operational requirement for other reasons.

Well, the WG decided it was time to move on and fixing the loophole was more important.

One way to close this loop-hole would be for the RIRs to agree on
a uniform authorization model, and share the authorization
information (and data) between themselves. I suspect this is no
small task.

Best regards,

- Håvard