You are here: Home > Publications > RIPE Labs > nusenu nusenu > The RPKI Observatory: A New Website Aiming to Help Reduce RPKI Misconfigurations

The RPKI Observatory: A New Website Aiming to Help Reduce RPKI Misconfigurations

nusenu nusenu — 17 Oct 2018
In this post I'll cover why it is important to take care of RPKI misconfigurations, what the impact of ignoring them is, how network operators can easily determine whether they are affected by a specific RPKI misconfiguration and how significantly the amount of RPKI unreachable IP space changed over the course of just a few weeks.

An issue blocking RPKI-based ROV adoption at Tier 1 Providers

The number of network operators and IXPs deploying RPKI-based Route Origin Validation (ROV) - which helps reduce the impact of BGP hijacking attacks and accidental misconfigurations - is increasing, but tier 1 transit providers are not yet among those.

One of the reasons why big transit providers can't deploy ROV as easily as an IXP or smaller networks yet are old misconfigured RPKI Route Origin Authorizations (ROAs) causing many RPKI "INVALID" prefix-origin pairs. "INVALID" prefix-origin pairs could be BGP hijacking attacks that would be filtered out in an ROV environment, but instead of being actual BGP hijacking attempts many are actually just misconfigured ROAs. These legacy ROAs aren't an issue for Route Servers at IXPs performing ROV since they usually don't require a complete routing table.

Tackling the Problem

Recently, I analyzed RPKI invalid prefix-origin pairs

Instead of looking at all of them I specifically filtered for those that actually result in unreachable IP space (where no alternative routes are available to cover for the invalid prefix-origin pairs).

The main motivation behind analyzing unreachable IP space was to find and inform affected network operators to help cleaning up these legacy ROAs and to eventually pave the way for a wider ROV adoption by big transit providers.

Helping network operators by providing an easily browsable list

The previous results were one-off snapshots of which network operators were affected at a certain point in time, but since networks are constantly changing, that list became outdated fast and its usefulness was limited.
So one of the goals I had was to create a regularly updated list of affected networks that is easily search and explorable by network operators and anyone else interested in Internet routing security.

Such a page could be used by network operators to easily determine whether any of their prefixes are suffering from this kind of RPKI misconfiguration, but it could also be handy when debugging reachability issues from (and to) networks that deployed ROV already or to get an idea of how much IP space is unreachable due to ROV in general.

That being said the list of RPKI unreachable networks is now available as the first module of a new website that aims to help reduce RPKI misconfigurations:

The RPKI Observatory

The goals of the RPKI Observatory are:

  • Measure how widespread common RPKI configuration issues actually are
  • Increase awareness for them
  • Provide actionable information for RPKI adopters to solve common issues
  • Increase the RPKI adoption and IP space coverage
  • Gather RPKI and routing security metrics
  • Analyse trends in RPKI deployments
  • Encourage the creation of ROAs and the deployment of ROV

"Unreachable Networks" is currently the first and only module but eventually I'd like to add more modules to analyse and tackle additional issues of the deployed RPKI landscape.

The page is supposed to be somewhat self explanatory, but here is a short overview. You can browse the list of RPKI unreachable networks at

RIR-Level


Country-Level




ASN-Level

asn-level

ROA-Level



Prefix-Level

prefix-level

At the individual prefix level you can manually inspect and verify the record by clicking the "reason" field which will direct you to the latest record for that prefix-origin pair on RIPE NCC's public RPKI validator.

This page is still very fresh so expect some rough edges. I appreciate any feedback you might have via the feedback button on the website or as Github issue.

So are we getting any better?

NIST's RPKI Monitor has been tracking the total number of RPKI invalid prefix-origin pairs for a long time and shows a somewhat grim picture. Note: this graph shows all invalid prefix-origin pairs not just unreachable ones. The red line showing number of invalids is increasing.

NIST's RPKI Monitor Graph

But if you look closely at the very end of the red line you can spot a tiny decrease and an increase in the green line (VALIDs) and since this graph shows the last 5 years this tiny portion depicts how things changed during the last few weeks.

Here is a graph showing how the amount of unreachable IPv4 space decreased during that time:



The amount of unreachable IPv4 address space decreased by over 1000 /24s in less than a month. That made me curious and I was wondering were are all these invalids solved? So here is a per-RIR graph showing that apparently LIRs in the RIPE region were solving invalids while others regions are mainly unchanged or even worsened (increased). A single RIPE LIR solved 512 /24s via two previously unreachable /16 prefixes.

Due to this one-sided change (improvements happened almost exclusively in the RIPE IP space) the fraction across RIRs also changed accordingly. The APNIC region is now the home of more than 55% of the RPKI-unreachable IPv4 address space, but since the affected prefixes in that region are relatively big (one /14, multiple /16s) it also involves fewer IP holders (meaning less work required for mitigation).

2018-09-24: Fraction of RPKI-unreachable IPv4 address space by RIR (8775 /24s)

2018-10-16: Fraction of RPKI-unreachable IPv4 address space by RIR (7599 /24s)

It is hard to know for sure what triggered this improvement without performing a questionnaire across LIRs that solved RPKI invalid announcements during the last month, but here is a timeline of events that might be related:

  • 2018-09-15 blog post: "Towards cleaning up RPKI INVALIDs" is published and sent to RIPE's routing WG and NANOG
  • 2018-09-19 Cloudflare announces plans to deploy RPKI-based ROV via two blog posts (tentative timeline: end of 2018)
  • 2018-09-19 List of affected networks is send to NANOG
  • 2018-09-20 List of affected networks is send to LACNOG
  • 2018-09-25 blog post: "Mapping the RPKI unreachable IP space" is published and send to the routing WG
  • 2018-09-26 - 09-29 List of affected networks is send to NANOG, UKNOF, ARNOG, ITNOG, NLNOG and DENOG

Conclusion

  • The RPKI Observatory makes it easy to determine if an ASN is suffering from RPKI misconfigurations resulting in RPKI unreachable IP space
  • The amount of unreachable IPv4 address space significantly improved (decreased) in the past month - although almost exclusively in the RIPE region.

That being said there are still over 1500 RPKI unreachable prefixes waiting to be taken care of, so now is a good time to head over to the RPKI Observatory to find out if your network's reachability is affected.

2 Comments

Taejoong Chung says:
17 Oct, 2018 08:27 PM
Thanks for the post! I have one quick question, what is your data source of BGP announcement to validate the IP prefixes advertisement against its ROA?
nusenu nusenu says:
18 Oct, 2018 09:56 AM
Thanks for your comment and question.

I talk to a RIPE Validator 3 instance which fetches data from RIPE RIS (http://www.ris.ripe.net/dumps/) itself as the underlying data source.


https://nusenu.github.io/RPKI-Observatory/#how-does-it-work
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.