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

Hi Håvard,

Please see my comments below.

> Op 15 aug. 2018, om 10:21 heeft Havard Eidnes via db-wg <db-wg at 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 <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
> 

Best regards,

Nathalie Trenaman
Product Manager 
RIPE NCC


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20180815/698798b7/attachment.html>