IRRD & exceptions to RPKI-filtering

Tue Feb 13 00:12:36 UTC 2024

On Mon, Feb 12, 2024 at 05:01:35PM -0600, Richard Laager wrote:
> On 2024-02-12 15:18, Job Snijders via NANOG wrote:
> > On Mon, Feb 12, 2024 at 04:07:52PM -0500, Geoff Huston wrote:
> > > I was making an observation that the presentation material was
> > > referring to "RPKI-Invalid" while their implementation was using
> > > "ROA-Invalid" There is a difference between these two terms, as I'm
> > > sure you're aware.
> 
> I'm sure Job is aware, but I'm not. Anyone want to teach me the
> difference?

I'll try, but please bear with me as terminology throughout the years
has shifted and perhaps wasn't entirely consistent from the start, and
maybe I missed some bits. :-)

The word "invalid" in context of RPKI and BGP has a lot of additional
context:

RFC 6811 ("BGP Prefix Origin Validation") introduced the concept of a
given BGP route being "NotFound", "Valid", or "Invalid". In later years
many people referred to "Prefix Origin Validation" as "Route Origin
Validation" or "RPKI-based Origin Validation" (both variants abbreviated
to "ROV"). Other variants also exist.

Before one can conduct the RFC 6811 "Prefix Origin Validation" (née
"Route Origin Validation") process, the operator (in an automated
fashion, using a RPKI validator) will ascertain the validity of the ROAs
(Route Origin Authorizations) by checking the cryptographic signatures,
validity time windows, and other properties (See RFC 6488
and https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rfc6482bis)

In order for the RFC 6811 validation process to arrive at a "Valid" or
"Invalid" outcome, first of all a *valid* ROA needs to exist (as in
cryptographically valid). So, to designate a BGP route as 'invalid', one
needs at least one 'valid' ROA covering the IP address prefix at hand.

The concept of validating BGP routes (or, as some call it 'verifying BGP
routes'), using RPKI derived information, has been transposed to IRR
data as well. For example, in 2018 RIPE NCC started using RPKI data to
untangle and cleanup the "RIPE-NONAUTH" IRR database, as per policy
https://www.ripe.net/publications/docs/ripe-731/ And the NTT Global IP
Network (GIN/AS2914) used the same methodology on its IRRd server
'rr.ntt.net' (the default host used in bgpq4). Now RADB uses the same
methodology (and software) as NTT does.

A ROA can be invalid (for example, because its X.509 EE certificate
expired); a BGP route can be invalid (because no valid RPKI ROA attest
that the route could originate from the ASN at hand), and an IRR object
can be invalid (because no Valid ROA attest the route object's "origin:"
could originate the prefix at hand).

Kind regards,

Job