Resource Certification (RPKI) Data Quality and Usage

The amount of members requesting a Resource Certificate is steadily climbing, soon reaching 900. What is even more impressive is the amount of routing information these LIRs have entered in the system by creating Route Origin Authorisations (ROAs). But what is the quality of the data and is it used by anyone?

On the 3 February I saw this tweet by Andree Toonk:

"80.227.96.0/24 (Emirates Telecom) just got hijacked by AS6503. It's covered by ROA 80.227.96.0/19 AS15802 perhaps some day it helps..."

and today a routing error caused 3 Million Telstra customers to go offline because the ISP does not employ appropriate BGP filtering. The first case is particularly interesting to me because as the tweet says, Emirates Telecom (DU) actually has ROAs for their route anouncements , causing the hijack to be flagged as an unauthorised announcement. Yet that did not not make any practical difference.

It relates to a question that I get asked more and more frequently:

"It's great that more than 10% of the RIPE NCC membership has a Resource Certificate and created ROAs for more than 10% of the total RIPE NCC address space, but how many people are actually using this data for making BGP Routing decisions?"

My answer to that is: "In production, virtually nobody." Even though the RIPE NCC RPKI Validator toolset that has been developed to help make BGP routing decisions, has been downloaded hundreds of times and gets great feedback, operators first need to be convinced that the RPKI data set is accurate and reliable before using it in production.

The good news is that the 1,803 ROAs in the global RPKI system create 4,937 valid, authorised route announcements. Unfortunately these same ROAs also make 3,266 announcements look like hijacks.

RPKI Invalids Preview

It is safe to say that overall data quality is pretty bad, which is mostly caused by a poor understanding of how ROAs affect route announcements (more on that here and here ). If operators would start relying on the RPKI data set and give the invalid announcements a lower pref (or even drop them) then operators who created the bad ROAs would be pressured to fix their mistakes. But who would start using a data set with this quality in the first place?

The Proposal: No Indefinite Lifetime For ROAs

When we launched the Resource Certification system, we decided to allow users to create ROAs with a lifetime matching the Resource Certificate by default. Optionally, they can specify an explicit start and end date for the validity of the ROA. In practice it means that every ROA in the system is present and valid for as long the associated prefixes are held by the LIR. It now looks like this will lead to very stale, unreliable data and a lot of cruft cluttering the system.

We are considering changing the interface to make ROAs only valid for a limited time, for example one year. This means that at least once a year, ROAs need to be reviewed and renewed by the operator, giving them a chance to compare the ROAs against real-world BGP. This should lead to better quality data. If the ROAs are neglected by the LIR and not renewed, then all related route announcements will fall back to the status 'unknown', which is arguably a better situation than the risk of a large amount of (unintended) invalids tainting the data set.

I look forward to your thoughts about this...