[connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call

Dear working group,

As some of you may know improving Internet routing security is a topic
dear to my heart, so I read this proposal with much interest. I have
some concerns I'd like to share related to impact analysis, existing
deployed mitigations, alternative approaches, and potential
inaccuracies.

TL;DR - I do not think this draft proposal is ready for publication as
RIPE document.

1. Impact analysis
==================

I have some experience helping operate the NTT IRR mirror (rr.ntt.net),
and throughout my tenure I've both been part of the decision group
concerned with adding new and deprecating IRR database mirrors (both RIR
and third party databases). Part of the onboarding and offboarding
process would be to run simulations to understand how many BGP best
paths, not-best-but-elegible paths, and currently ineligible paths would
change status; additionally attempts were made to understand potential
for traffic swings.

I think some numbers were shared in previous Connect WG meetings, but
the proposal at hand does not include a thorough impact analysis from
the perspective of the IX operations affiliated with the authors. I'm
also not sure whether previously shared information contained impact
analysis broken out into RPSL object classes (for example, is the juice
worth the squeeze for just ROUTE/ROUTE6 objects, or is most of the
friction in AS-SETs, or in ROUTE-SETs, or some other type?).

I suspect impact will differ from IX operation to IX operation, for
example I can imagine that a Netherlands-specific IX is unlikely to
benefit much from using Canada's CANARIE IRR, but speaking from the
perspective of YYCIX (Calgary, Canada), there seems little to be gained
and some to be lost by dropping CANARIE.

The proposal correctly observes out that because there is a multitude of
information sources, those sources could be in conflict with each other
(simply by virtue of there existing multiple sources). What is perhaps
less understood is whether the information in the RIR database is the
correct one or the information in the third-party databases is more
aligned with the resource holder's intentions. In other words, yes,
conflicting information exists, but it doesn't automatically follow that
the 'wrong' information is in the non-RIR databases.

2. Existing deployed mitigations / threat model
===============================================

At the moment of writing both the NTT and the RADB 'IRR mirror
aggregators' support RPKI-based filtering for ROUTE/ROUTE6 objects. This
is a fairly recent development and means that anyone using the bgpq3,
bgpq4, or irrtoolset's peval utility will enjoy a view on the IRR that
is informed by a cryptographically signed source of truth (the RPKI).
It's only been 6 months since RADB deployed RPKI-filtering, have the
effects of this been studied?

This touches upon threat modeling, because the above means that
third-party databases no longer are a useful vector to inject
information which conflicts with the RPKI. With RPKI ROAs nowadays
covering over 50% of routes and over 70% of IP traffic flowing towards
RPKI-ROV-valid destinations, what threats are mitigated exactly with
this draft proposal?

My intuition is that the third-party IRR databases nowadays at best
contain information that is not present in the RPKI (legacy space,
AMPRnet, or information about IP networks where the resource holder for
one reason or another didn't create RPKI ROAs), and at worst... well
they no longer present information that's in conflict with RPKI ROAs. So
what problem is solved? It seems to articulate what exactly the harm is
in third-party databases while it is easier to point at potential
benefits.

3. Potential inaccuracies
=========================

The proposal starts with "The root of the Internet Number Registry
System is the IANA, the Internet Assigned Numbers Authority, which
manages the complete pool of all possible IP addresses and AS numbers."
but historically that's not been the case entirely. Prior to IANA
numbers were managed by Jon Postel, and later on both IANA, InterNIC,
and the RIRs played a role. Throughout the years authorities came and
went, or were subsumed in other authories, or later on relieved (to some
degree) from duties.

A good example of inaccuracy in IANA 'managed' data is this registry:
https://www.iana.org/assignments/as-numbers/as-numbers.xml
is an incomplete registry, where only 'new' ASN assignments are listed.
In the past this registry used to list all ASNs, but then later on the
RIRs asked IANA to revert to being less detailed...

Another IANA registry which is not very precise (read: inaccurate) is:
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
It only contains high-level information about /8s, but a number of those
/8s are in reality managed by multiple RIRs, or are part RIR-managed
part legacy space.

A registry report that's more accurate than IANA's in relationship to
RIR-managed space is available via the NRO collaboration:
https://ftp.ripe.net/pub/stats/ripencc/nro-stats/latest/nro-delegated-stats
However, this NRO data is only accurate for RIR-managed space, and there
still is non-RIR-managed IP space and ASNs.

Perhaps a more practical viewpoint would be to consider that there are
multiple 'roots' for the management of IP addresses and AS numbers, each
with their own scope. Taking such a perspective would lead to the
conclusion that not all Internet Number Resources are managed by either
IANA or the RIRs, begging the question whether a 100% RIR-centric
approach for IRR mirroring is helpful at this point in time.

As a sidenote: the RIR IRR and RPKI systems from time to time are in
slight conflict with each other. As part of the 'constraining RPKI Trust
Anchors'-project I've uncovered a number of inconsistencies between RIRs
in terms of what they claim authority for:
https://datatracker.ietf.org/doc/html/draft-snijders-constraining-rpki-trust-anchors
Despite everyone's best intentions, the rabbit hole is deep :-)

I'd like to emphasize we should view the data in context of higher and
lower sources of truth, with cryptographically verifyable data
superseding non-cryptographic information, and in doing so removing the
(potential) stinger out of non-RIR data.

4. Alternative approaches?
==========================

It seems the proposal does not mention considerations on alternative
approaches. For example, instead of wholesale dropping third-party
databases, one could argue that IRRd software should take into
consideration information from the 'nro-delegated-stats' file, and
either filter or mark differently information found in non-RIR IRR
databases that covers IRR information in RIR-managed databases. For
example, if IP address block ABC is managed by RIPE, but the RIPE
database doesn't contain any route/route6 information for ABC, and a
third-party database *does* contain information for ABC; then IRR should
not filter out the third-party information about ABC. Especially when
ABC is not in conflict with ROAs, especially when ABC is not covered by
ROAs.

Related to section 2 of this email, the proposal mentions dropping
RIPE-NONAUTH, but only a few years ago through a RIPE policy update
(https://www.ripe.net/publications/docs/ripe-731/) the community came
to consensus that imposing RPKI filtering on the RIPE-NONAUTH data would
be a sufficiently effective sunsetting strategy to over the years to
come purge more and more information, all the while retaining
routing information for which there is no better authority.

Or, perhaps such development work is not needed at all taking a long
view: every day more and more RPKI ROAs are being created, and as
industry we'd do well to let the brunt of the work be done by resource
holders creating ROAs for their IP address space? It may well be that
patience is all that's needed (again, depends on the threat model!).

5. Conclusion
=============

I'd prefer to see data cleanup and migration proposals which are softer
in nature: rather than dropping a database in its entirety merely
because it is not managed by an RIR, instead seek to develop strategy
and tooling to continue to extract benefit from such databases, while at
the same time strengthening the position of data stored in 'more
authoritative' sources.

Dropping one or more sources of routing information in their entirety is
is probably the crudest form of data source harmonization, instead I
think there is precedent to harmonize data such as was done in IRRd v4's
RPKI integration and through RIPE-731. Perhaps it is time to now see if
a similar approach can be done based on the NRO provided data? And once
that's done, see what treatment the remaining data needs ... if any.

Kind regards,

Job

On Tue, Jun 04, 2024 at 11:16:18AM +0000, Stavros Konstantaras wrote:
> Hi folks,
> 
> We are discussing this subject since RIPE86 and we have presented our progress in both RIPE87 and RIPE88. Every time we bring this subject, we receive strong support from the community, both during the presentations and in personal discussions. We thank you all for that as it provides us fuel and motivation to continue our work.
> 
> I have discussed the process with RIPE NCC employees and they are happy to adopt it as an official RIPE BCP/document, as long as the support is documented in this mailing list.
> 
> Thus, we would like to make a call for adoption for this working item. Please find attached the latest version of the draft and feel free to submit your comments in case you find mistakes (e.g. typos, grammar, etc etc).
> 
> 
> 
> Kind Regards
> 
> Stavros, Marco, Will, Andrei


> _______________________________________________
> connect-wg mailing list
> connect-wg at ripe.net
> https://mailman.ripe.net/
> 
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/