Celebration: RADB appears to now filter RPKI-invalid IRR route/route6 objects

[Job Snijders via NANOG <nanog () nanog org>]

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-7240-4b62-acc5-780a25cd0dd9/1/LeUtRtipWJVA-QrrwolA6aEiFsI.roa.html

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