YMMV, but my take: 1 - You should worry a little, but not much. Filters allowing unwanted announcements might be created using these erroneous IRR records, but they won't do any damage by themselves. An actual wrong BGP announcement is required for any damage to happen, and even without those IRR records, a wrong announcement will cause some havoc since not everyone builds filters based on IRR and not everyone runs RPKI validation. 2 - Most IRR databases will take reports from the RIR-registered contact of the block seriously. Some databases will react faster than others; for instance, in TC any such objects will be removed upon knowledge and if the maintainer recreates those objects, the maintainer may be permanently excluded from the database. 3 - Unfortunately there is not much you can do since this is caused by relaxed submission filtering at IRR databases, The RIR-connected IRR databases are usually very good in preventing such, but the independent ones usually are not. IRRd versions prior to v4 (thanks NTT for v4) are also more prone to accept non-compliant records and can only eliminate them after inclusion. Rubens On Fri, Oct 30, 2020 at 10:11 PM Pirawat WATANAPONGSE <pirawat.w@ku.th> wrote:

Dear Guru(s),

I am seeking advice concerning someone else announcing IRR records on resources belonging to me. [I was referred to this mailing list from the DNS-OARC community.]

Context: I have already registered all my IP address blocks with ROA/RPKI [evidence: https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS9411] However, HE reports a lot of spurious IRR records on my resources [example: https://bgp.he.net/net/158.108.0.0/16#_irr]

Question #1: Should I worry about those spurious records [Yes | No | Depends]? My fear is that other sites might accept those records without checking and thus be misled somewhere else, since ROV is not yet the behavior-in-majority. My other reasoning is that, if we are not going to keep accurate records, why bother keeping them at all anyway.

Question #2: What can I do about it [in case the answer to Question #1 is Yes]? Should I notify those Database Admins? Will they consider me a nuisance? And most importantly: Will they erase those records for me, or will they just ignore me?

Question #3: Did I not do something that can prevent those spurious records from happening in the first place? And, anything I can do now to prevent it from ever happening again?

Thanks in advance for your advice(s),

Pirawat.

Dear Pirawat, On Mon, Oct 26, 2020 at 08:13:19PM +0700, Pirawat WATANAPONGSE wrote:

I am seeking advice concerning someone else announcing IRR records on resources belonging to me.

Change is underway in the IRR ecosystem! The situation we are all used to is that it is rather cumbersome to get IRR databases to remove IRR objects. The IRR database operator may not trust your request for object removal, or is busy doing other things. There was no industry-wide automated process for IRR object removal. With the introduction of "RIPE-731" (https://www.ripe.net/publications/docs/ripe-731) in the RIPE region, the "RIPE-NONAUTH" database has slowly been shrinking. The RIPE-NONAUTH database exclusively contains IRR objects covering non-RIPE space. As more and more people create RPKI ROAs, which in turn provide automated evidence whether objects in RIPE-NONAUTH are valid or not valid. If an object is found to be invalid, it is deleted. While RIPE-731 addressed the issue of stale objects in the RIPE-NONAUTH database, of course it did not change anything for non-RIPE databases. Most non-RIPE databases use software called "IRRd" (the likes of NTTCOM, RADB, TC, etc). The IRRd software is the main entrypoint into the IRR system, and recently IRRd v4.1.0 was released which can automatically delete RPKI invalid IRR route objects. A youtube video from last week with some information on IRRdv4 can be seen here: https://www.youtube.com/watch?v=V9fsU0mNcA4 NTT has not yet upgraded from 4.0.0 -> 4.1.0, we are working on that. RADB is also investigating a migration path. LACNIC & ARIN already are on the v4 train. The moment NTT and RADB have deployed 4.1.0 at rr.ntt.net and whois.radb.net there will be an industry-wide fully automated IRR cleanup process running which accomplishes two things: - stale/rogue/erroneous objects (conflicting with RPKI) are deleted - new objects which are in conflict with RPKI ROAs cannot be created Using RPKI to clean up the IRR is a continuous process: this mechanism helps clean up the past, but also going forward ensures that IRR does not contain new information which is in conflict with published cryptographically signed RPKI ROAs. This 2018 video outlines the strategy how to migrate to an improved state of internet routing security: https://www.youtube.com/watch?v=3BAwBClazWc https://nlnog.net/static/nlnogday2018/9_routing_security_roadmap_nlnog_2018_... Reality is now nearly synced up to all slides of the deck :-) Kind regards, Job