Hi Guys To create a ROUTE(6) object in the RIPE Database, the referenced origin AUT-NUM object doesn't need to exist in the RIPE Database. But should the ASN have been allocated by one of the RIRs? So perhaps the first questions to answer aren't about whether or not we should delete these ROUTE(6) objects referencing non allocated or reserved ASNs. Maybe we should ask questions like "does such a ROUTE(6) object have any operational value?". Does it have any legitimacy being in either the RIPE or RIPE-NONAUTH database? Can the existence of such an object cause any harm? If deleting such a ROUTE(6) object breaks something, but that 'something' should not have been relying on an invalid and unauthorised agreement (which is what a ROUTE(6) object is), does that matter? For the ROUTE(6) objects referencing RIPE address space and invalid ASNs, these objects had to be authorised by the address space holders. Why did they authorise creation of objects advertising false agreements? RIPE resource holders are required to enter correct data into the RIPE Database. The terms of the contracts they signed as resource holders give these objects no validity to remain in the RIPE Database. Answering these questions may answer the question about whether or not we should delete these ROUTE(6) objects. Ed, have any of these ROUTE(6) objects been created recently? Looking ahead, should we have a business rule in the RIPE Database to not allow creation of ROUTE(6) objects with an invalid (unallocated) origin ASN? cheers denis co-chair DB-WG On Wed, 30 Jun 2021 at 14:02, Cynthia Revström via db-wg <db-wg@ripe.net> wrote:
Hi Ed,
Thanks for the data, based on this I will stand by my opinion that there should be no action taken here currently. This opinion is also mainly based on the fact that it is not validated in the RIPE database. I am not sure if this is right or not, but I think it should probably not be cleaned up in RIPE-NONAUTH if it is not validated in RIPE.
But once again if someone has a better reason then I could change my mind. Also if/when we get to a point that these objects are a very significant part of the remaining objects in RIPE-NONAUTH then it might be worth discussing again.
I feel like in this case when there is no real personal data (afaik), we should value not breaking things we didn't think of way higher than cleaning up ~1600 route(6) objects. (Assuming the resource holders can contact the NCC to request to have them removed)
-Cynthia
On Wed, Jun 30, 2021 at 1:40 PM Edward Shryane <eshryane@ripe.net> wrote:
Hi Cynthia,
On 29 Jun 2021, at 15:00, Cynthia Revström <me@cynthia.re> wrote:
Hi Ed,
Thanks for implementing this :)
Thanks for your feedback.
I mainly wanted to give my initial take on the AS origin status part which is in short: I don't think we should clean up based on origin AS. This is as you do not need any technical authorization from the AS holder to create a route(6) object. Additionally, I don't think this is validated in RIPE AUTH, but I could be wrong on that part.
I might have a different opinion if it is a huge amount of objects that could be cleaned up or if it is such a tiny amount that maybe just contacting the maintainers manually would be enough. Summary: I don't think it is a good idea unless it is either a very large amount of objects, a very trivial task, or there is another good reason to do so.
-Cynthia
I found 1,577 route objects (out of 55,960) and 43 route6 objects (out of 1,522) in the RIPE-NONAUTH database which reference an unregistered AS number (i.e. "available" or "reserved" in any RIRs delegated stats).
Of these, there are 169 distinct unregistered AS numbers referenced by route(6) objects in RIPE-NONAUTH.
As we don't validate the origin AS number in the RIPE database (apart from excluding bogon space according to: http://www.team-cymru.com/bogon-reference.html), I also checked route(6) objects there.
I found 72 routes and 20 route6 objects in the RIPE database which reference an unregistered AS number (41 distinct AS numbers).
Regards Ed Shryane RIPE NCC