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

Hi All

I raised an idea before the last RIPE Meeting but it did not generate a 
lot of interest at that time. I brought it up again yesterday on the 
Anti Abuse WG list and it seemed to get quite a bit of support. So I 
will bring it back to the DB WG as it is a DB issue.

I have CC'ed both AA WG and Routing WG for information. But it may be 
useful to keep the discussion now on the DB WG list.

I don't claim this will solve all the problems of the universe, but it 
does satisfy an immediate goal to have all ROUTE objects in the RIPE 
Database created with the knowledge and approval of the related resource 
holders. And I believe it could be implemented in a relatively short 
space of time giving immediate benefits.

cheers
denis


STEP 1

Any ROUTE object submitted for creation in the RIPE Database involving 
an out of region resource (address space and/or ASN) where that out of 
region resource does not exist in the authoritative RIR database (has 
not been allocated or assigned), reject the creation.

The RIPE NCC mirrors the operational data from all the other 4 RIRs. 
These mirrors are updated daily as well as the RIRs daily stats. It is 
easy to determine if a resource is registered in the authoritative database.

STEP 2

For those ROUTE objects from STEP 1 where the out of region resource 
does exist, hold the object creation as pending. The mechanism for doing 
this already exists in the RIPE Database software as it is used for 
multiple authentications.

Lookup the out of region resource(s) in the authoritative database(s) 
and find the contacts for that resource. Send a notification to those 
contacts informing them of the pending ROUTE object creation in the RIPE 
Database. The notification mechanism already exists in the RIPE Database 
software. If they don't approve, do nothing and the creation request 
will time out after a week and the object will not be created. If they 
do approve, respond in some way (many technical options for doing this 
that the RIPE NCC can choose from). If appropriate approval(s) are 
received within a week, create the ROUTE object.

STEP 3

On a daily basis, for each ROUTE object in the RIPE Database that 
relates to an out of region resource, check for the continued existence 
of that resource in the appropriate RIR database. If it no longer 
exists, delete the ROUTE object from the RIPE Database.

STEP 4

This is a one off cleanup of existing ROUTE objects. For all ROUTE 
objects currently in the RIPE Database that relate to an out of region, 
existing resource, send the appropriate notifications. For any that no 
response is received, delete the ROUTE object from the RIPE Database. We 
can be a bit more generous on the timing for this step and even send 
multiple reminder notifications to be sure.

(Possible) STEP 5

If a delete request is sent to the RIPE Database for a ROUTE object 
related to out of region address space without the proper authorisation, 
send a notification to the contacts for the authoritative address space 
holder. If an appropriate response is received back, delete the ROUTE 
object.

This would simulate the reclaim functionality for RIPE address space 
holders.

AUT-NUM copies

Another byproduct of implementing this is that we no longer need to hold 
copies of AUT-NUM objects in the RIPE Database. The out of region ASN 
auth requirement is satisfied by the appropriate response to the 
notification. So all 'foreign' AUT-NUM objects could be immediately 
deleted. (Or after allowing time for these ASN holders to make sure 
their routing policy is actually up to date in the authoritative AUT-NUM 
object.)