2 Security Issues with RPKI and How To Fix Them

By Dr. Bahaa Al-Musawi, MANRS Fellow (2020 cohort)

Resource Public Key Infrastructure (RPKI), as defined in RFC 6810, was proposed to authenticate the relationship between a prefix and its origination. While it has many advantages, such as reducing route leaks, the system introduces some security issues. In this post, let’s discuss two of these issues and explore how we should address them.

RPKI is the first step to improve Border Gateway Protocol (BGP) security; its wide adoption can help ensure an advertised prefix is sent by an authorized autonomous system (AS) and hence BGP routers can be configured to prevent the propagation of invalid routes and then discard them. BGPsec and other small steps, such as ASPA and AS-Cone, also help in overall BGP security.

This form of RPKI-based filtering is termed Route-Origin Validation (ROV). Although some large networks (e.g. AT&T, Telstra, NTT, Telia Global) use ROV, others may enforce ROV partially or not use it at all. According to a survey of network operators, the most common reason for not filtering invalid routes is fear of being disconnected from legitimate destinations. However, incorrect (Invalid) Route Origin Authorizations (ROAs) should not bring false positives.

RPKI adoption brings many advantages, including reducing the risk of accidental BGP route leaks and mitigating the spread of invalid routes caused by accidental or deliberate anomalies. Nonetheless, the RPKI system introduces at least two security issues that we should be mindful of.

Distribution of RPKI data

The open source tool rsync is the main way of distributing RPKI data. It was designed to limit the amount of data that needs to be transferred between client and server. When an RPKI validator is used on a client system, it has a dependency on rsync. Different versions and different supported options, such as contimeout, can cause unpredictable results. Furthermore, rync is inefficient, insecure, and dangerous to run as a server or client, as George Michaelson and Byron Ellacot showed. APNIC’s Chief Scientist Geoff Huston discussed recently why rsync is not a recommended protocol.  While it served the system well in the early years, rsync has several downsides.

Firstly, repositories are vulnerable to Denial of Service (DoS) attacks. Secondly, there is a lack of rsync client libraries. In practice, all implementations must make system calls to an rsync binary. This is inefficient, as it introduces fragility with regard to updates of this binary, makes it difficult to catch and report problems to operators, and complicates software development and testing. Furthermore, scaling becomes increasingly problematic as the global RPKI data set grows and more operators download and validate data, as with rsync the server is involved in processing the differences. So, does that mean that rsync is a bad protocol to be used on the Internet? Unfortunately, yes.

To overcome these limitations, the RPKI Repository Delta Protocol (RRDP) was developed and standardized in RFC 8182, which relies on HTTPS. RRDP was specifically designed for scaling and allows Content Delivery Networks (CDNs) to participate in serving the RPKI data set globally and at scale. Also, HTTPS is well supported in programming languages, so the development of Relying Party (RP) software becomes easier and more robust. Currently, RRDP is implemented on the server side by ARIN, RIPE NCC, and APNIC. Most RPKI Validator implementations either already have RRDP support or have it on their short-term roadmaps. RRDP makes development and implementation easier and opens up possibilities for CDNs to participate in serving RPKI data.

Recommendation: RRDP is the alternative protocol and it is implemented by most RIRs. To encourage wide use of RRDP, NLnet Labs introduced a tool called rrdpit to turn any rsync server into an RFC 8182-compliant RRDP HTTPS server. Furthermore, the IETF’s Secure Inter-Domain Routing Operations Working Group (sidrops WG) released a new draft that facilitates incremental deployment RRDP as the only mandatory to implement access protocol.

No guarantee for data to be updated

RPKI does not guarantee that the data is up to date, there is no mechanism to force an IP address holder to refresh their information. Furthermore, the permission of the ASN holder is neither required nor is it strictly necessary for the ASN to be consulted for approval before issuing the ROA. In addition to unguaranteed updated RPKI data, there are several possibilities related to the operation of RPKI validators that lead to an incomplete or outdated view of RPKI datanamely RPKI validators might not reach a publication point server, an infrequent fetch of RPKI data, and some RPKI validators do not follow the technical specifications.

 Recommendation: The developers of the RPKI Relying Party softwares need to clarify the standards compliance. For example, they need to tell the operators which RFC standards are implemented, fully or partially. FORT validator, for example, adopted this step by highlighting which RFC standards are implemented. Furthermore, IP address holders need a plan to maintain their information.

In summary, more collaboration is required from operators and developers and we need to listen to each other!

Editor’s note: This is a guest post by a MANRS fellow. Viewpoints expressed in this post are those of the author’s and may or may not reflect official positions.