Dear NANOG, It appears the WHOIS service at whois.radb.net is now filtering out RPKI-invalid IRR route/route6 objects for common expansion queries! This really is exciting and excellent news. I'll elaborate a bit on what this exactly means. Example ROA & IRR object ======================== Take for example the 194.32.71.0/24 test prefix: https://irrexplorer.nlnog.net/prefix/194.32.71.0/24 For experimental purposes, NTT (ages ago) created a cryptographically verifiable RPKI ROA to indicate that any BGP announcements for 194.32.71.0/24 or-longer are RPKI-invalid: https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/01/ee8b98-7... RPKI ROA: +--------------------------------+ | Prefix: 194.32.71.0/24 | | Origin: AS 0 | | Trust Anchor: RIPE NCC | +--------------------------------+ Additionally, an IRR route object was created in the RIPE NCC managed 'RIPE' IRR database: https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true&searchtext=-r%20%20-T%20route%20194.32.71.0%2F24&source=RIPE IRR Route Object: +--------------------------------+ | route: 194.32.71.0/24 | | origin: AS15562 | | pingable: 194.32.71.1 | | ... | | source: RIPE | +--------------------------------+ Obviously, the above IRR route object is in conflict with the sole RPKI ROA for 194.32.71.0/24, which designated AS 0 exclusively. Following the reasoning that IRR route objects describe possible BGP states, and in BGP the combo 194.32.71.0/24AS15562 would be rejected; it makes sense to go a step further and filter out IRR objects which are RPKI-invalid too. This concept of filtering out RPKI-invalid IRR objects was described in https://www.ripe.net/publications/docs/ripe-731 and also implemented in IRRd v4. RPKI-Invalids no longer visible via whois.radb.net ================================================== Since recently, whois.radb.net indeed applies such filtering and no longer displays the RPKI-conflicting IRR object for 194.32.71.0/24: $ whois -h whois.radb.net 194.32.71.0/24 % No entries found for the selected source(s). The above 'No entries found' output means that the IRRd instance filtered out the RPKI-invalid IRR objects! This is great :-) In doing so, RADB actively helps safeguard the interests of resource holders: it no longer is possible for adversaries to create IRR route objects which are in conflict with RPKI ROAs via the RADB service, and RADB also filters out RPKI-invalid IRR route/route6 objects received via the NRTM mirror streams; additionally, this filter mechanism helps clean up historical route objects that have become irrelevant due to transfers. The RPKI-based filtering mechanism cleans up the past and helps protect going forward. Of course RADB isn't the only IRR operator who apply RPKI-based filtering, NTT is another one, as is TC, etc; but this week's RADB migration it certainly moves the needle in a significant way: now all the world's largest IRR mirrors apply RPKI-based filtering! :-) Thanks ====== I'd like to express appreciation to the NTT crew (past and present) for helping launch the IRRd v4 initiative: Dorian Kim, Shawn Morris, Michael Wheeler, Dan Lowe, Troy Boudreau, Camilo Cardona; to Sasha Romijn from Reliably Coded for leading the development of IRRd v4; and to the Merit crew who diligently worked to migrate RADB away from legacy IRRd - I believe we collectively benefit from their efforts. The IRRd cross-organizational open-source project is here: http://irrd.net/ お疲れ様です! Kind regards, Job