New RFC 8360 – RPKI Validation Reconsidered – Offers Alternative Validation Procedures to Improve Routing Security Thumbnail
Securing Border Gateway Protocol (BGP) 6 April 2018

New RFC 8360 – RPKI Validation Reconsidered – Offers Alternative Validation Procedures to Improve Routing Security

By Andrei RobachevskyFormer Senior Director, Technology Programmes

RFC 8360, Resource Public Key Infrastructure (RPKI) Validation Reconsidered, is now published in the RFC libraries.

What is RPKI?

Resource Public Key Infrastructure (RPKI) aims to improve the security of the Internet routing system, specifically the Border Gateway Protocol (BGP), by establishing a hierarchy of trust for BGP routes. Today, most organizations simply trust that routing updates they get are sent by authorized senders. This is how bad actors and misconfigurations can cause massive routing issues. With RPKI, the receiving organization can verify that the sending organization is authorized to send the routing update.

RPKI works by issuing X.509-based resource certificates to holders of IP addresses and AS numbers to prove assignment of these resources. These certificates are issued to Local Internet Registries (LIRs) by one of the five Regional Internet Registries (RIRs) who allocate and assign these resources in their service regions.

What Does This RFC Do?

In the IETF, participants have been discussing issues that may arise when resources move across registries. The problem happens when a subordinate certificate “over-claims” resources compared to its parent. According to the standard validation procedure specified in RFC 6487, the whole branch beneath would be invalidated. The closer to the top of the RPKI hierarchy such mistakes happen, the bigger the impact; some ISPs can lose their routing completely (assuming other networks validate, of course). The probability of such mistakes is unfortunately non-zero, especially taking into account inter-RIR address transfers. This new RFC specifies an alternative certificate validation procedure that reduces these aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features.

The RFC 8360 revised validation algorithm is intended to avoid causing CA certificates to be treated as completely invalid as a result of overclaims – only resources not covered by the parent certificate will be considered invalid. However, these changes are designed to not degrade the security offered by the RPKI. Specifically, ROAs and router certificates will be treated as valid only if all of the resources contained in them are encompassed by all superior certificates along a path to a trust anchor.

More Resources

Routing security is vital to the future and stability of the Internet, and the Internet Society is committed to helping network operators implement the crucial fixes needed to eliminate the most common malicious threats to the routing system. The Mutually Agreed Norms for Routing Security (MANRS) initiative is technology-neutral, but RPKI is one component to help improve routing security for all. We encourage all network operators to implement the four simple but concrete Actions and join the MANRS initiative. We also have more resources on Securing BGP and RPKI at, including an Introduction to PKIs and CAs.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Securing Border Gateway Protocol (BGP) 18 April 2024

The US FCC Signals a Dangerous New Course on BGP Security

The US Federal Communications Commission recently released a draft Declaratory Ruling and Order in the Open Internet Proceeding. However,...

About Internet Society 11 December 2019

Claudio Jeker Honored by Internet Security Research Group with Radiant Award

This week another Radiant Award has been awarded by the Internet Security Research Group, the folks behind Let’s Encrypt....

IETF 22 March 2019

Internet Resilience Discussions at IETF 104

Let’s look at what’s happening in the Internet Engineering Task Force (IETF) and the upcoming IETF 104 meeting in...