[db-wg] Removal of bogon route objects

Hi Ronald,

> On 11 Jun 2021, at 23:19, Ronald F. Guilmette via db-wg <db-wg at ripe.net> wrote:
> 
> In message <4282F6EF-99C9-4306-817B-95382487CBBA at ripe.net>, 
> Edward Shryane <eshryane at ripe.net> wrote:
> 
>>> I see.  That message is very interesting.  There are a couple of parts
>>> of it that I have trouble interpreting however, to wit:
>>> 
>>>  There are approximately 64 routes and 37 route6's with a prefix not
>>>  listed in any RIR's delegated stats. These will not be affected.
>>> 
>>> Can you explain the meaning of that, in small words?
>>> 
>> 
>> The cleanup job will use all of the RIRs delegated stats. If the route
>> prefix is not defined in any delegated stats, then it's skipped.
> 
> Umm... I thought that it was the definition of a "bogon" that it is some
> IP space (or ASN) that has not been assigned, by any RIR, to any other
> party.

This particular cleanup job is deleting route(6) objects referencing *unregistered* space ("available" or "reserved" in delegated stats), rather than any "bogons".

The aim is to cleanup route(6) objects after an RIR deregisters space (e.g. 196.52.0.0/14, as discussed in January).

> 
> And isn't the project here to detect and eliminate bogon route objects?
> 
> We seem to have a communications/terminology gap at some level.

Not for now. I suggest we define "bogon" space and cleanup any referencing route(6) objects as a separate effort.

Note that Whois already blocks the creation of new route(6) objects with a "bogon" prefix, as defined here: http://www.team-cymru.com/bogon-reference.html

> 
>> I'm not using the NRO extended stats, but rather I'm combining each RIRs
>> delegated stats.
>> 
>> Each RIRs delegated stats are more specific about the prefix status,
>> including "assigned".
> 
> Could you please post the 5 URLs for those 5 RIR delegated stats files?
> I'm sure that I could find them on my own, if pressed, but it would save
> me a small amount of time if you would just post them.
> 

Thanks Nick for explaining the location of the RIR delgated stats files.

> (It is a curious oddity that the NRO stats file is apparently not quite a
> perfect representation of the sum total of those 5 files.)
> 

I'm using the RIR delegated stats as they are already in use by Whois, I haven't checked for differences with the NRO delegated stats.

>>> Last but not least, there is this very perplexing line:
>>> 
>>>  The origin AS status is not considered, only the IPv4/IPv6 prefix.
>>> 
>>> Why?
>> 
>> The origin AS is not validated either in the RIPE database when creating
>> or updating a route(6) object (apart from excluding AS numbers reserved
>> by IANA).
>> 
>> Also, this cleanup job was created out of discussion about deregistered
>> address space: "196.52.0.0/14 revoked, cleanup efforts needed" in January.
> 
> OK, but as long as a cleanup is happening anyway, I would like to propose
> that all (stale?) route objects which reference bogon ASN should be elided
> also.
> 
> It seems quite entirely half fast for you/NCC to be doing all of this
> work to eliminate JUST the bogus route objects that reference bogon
> IP address space, while leaving alone all of the route objects that
> refer to bogon ASNs.
> 
> I mean, is it just me, or isn't that obvious?

We can extend the cleanup job to also validate the origin AS, if the rules are clear and if the DB-WG agrees.

> 
>> If the DB-WG agrees that we should, and can define *which* AS numbers
>> should be cleaned up, the job can be extended to include AS numbers.
> 
> I have stated my own preference.  I certainly would be happy to hear the
> opinions of others in the WG.
> 
>> If so, should *both* the prefix and origin be considered, or separately
>> (i.e. should we cleanup if either is unregistered)?
> 
> I'm not sure that I am following you here.  I mean I'm not even sure your
> question makes any sense to me.  I will just reiterate what I believe
> I have already expressed, i.e. that in my opinion a given route object
> is, by definition, "bogus" (and should be removed from the DB) if *either*
> it references bogon IP space *or* it references an unassigned (bogon) ASN.
> 

Thanks, that was my question, should we validate that *either* the IP or AS is unregistered, or *both* IP and AS are unregistered (and you indicated *either*).

Regards
Ed Shryane
RIPE NCC


>> Also thanks to you for checking NONAUTH for bogon route objects, your
>> questions and comments are very welcome.
> 
> Just trying to be helpful, if I can be.
> 
> I should be thanking *you* for your work on and involvement in this rather
> elaborate cleanup process.
> 
> It's a tough and probably thankless job, but somebody's got to do it.
> 
> I wish that I could wake up tomorrow and find that the whole world had
> totally and universally embraced RPKI, but until then, the route
> registries of the 5 RIRs are still being relied upon by a lot of folks,
> and it just won't do to have these route registries oozing bogosity.
> 
> 
> Regards,
> rfg
>