Hi Job
No I can't. I am suggesting it is 'theoretically' possible. But I'm not in a
position to do the analysis to see if there are any such examples. Perhaps the
RIPE NCC can figure out a way to check for any such cases.
cheersdenis
From: Job Snijders <[email protected]>
To: denis walker <[email protected]>
Cc: RIPE Routing Working Group <[email protected]>
Sent: Wednesday, 17 October 2018, 23:18
Subject: Re: [routing-wg] source: RIPE may also contain invalid ROUTEs
Hi Denis,
Can you point us to one example object?
Kind regards,
Job
On Wed, Oct 17, 2018 at 22:23 denis walker via routing-wg <[email protected]>
wrote:
Hi guys
There is a corner case where invalid ROUTE(6) objects may occur in the source:
RIPE database. Before NWI-5 a ROUTE(6) object could be created either by the
address space holder or the ASN holder. Both had to authorise the creation, but
whoever created the object would maintain it.
Suppose the ASN holder created an object and maintains it, then the address
space holder chooses another ASN to announce the address space. The address
space holder can delete the ROUTE(6) object using the Force Delete
mechanism(1), if they know about it. But many resource holders still don't know
such mechanisms exist. They may instead just create an RPKI ROA for the new
announcement and leave the old ROUTE(6) object in the database.
AFAIK there isn't yet any alignment mechanism, but it has been talked about
recently, and the cleanup proposal under discussion only applies to source:
RIPE-NONAUTH (but I'm not suggesting you extend it). Although this is a corner
case, it means you can't guarantee all the data in source: RIPE is still
authoritative.
(1)
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/10-authorisation/10-13-force-delete-functionality
cheersdenisco-chair DB-WG
