[db-wg] The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top

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.

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.

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

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