Mitigating prefix hijacks with RPKI (Part 2)

By Tiziano Tofoni, CEO of Reiss Romoli, Flavio Luciani, CTO of Namex (Roma IXP) & MANRS ambassador, and Hiba Eltigani, MANRS fellow

In our first post, we explained BGP hijacking and route leaks. This time, we’ll explain how to mitigate some of the most common routing problems by using RPKI.

We use Public Key Infrastructure, or PKI, every day – even if many of us don’t understand what it is or how it works. Briefly, a PKI allows us to securely use the Internet and other public networks by enforcing a set of policies, technologies, and procedures to create, manage, store, and revoke digital certificates and to manage public-key encryption.

Resource Public Key Infrastructure (RPKI), on the other hand, is specifically used to enhance Internet routing security and provide legitimacy for holders of IP resources. It was first introduced in February 2007 in the Internet Engineering Task Force’s (IETF) Request for Comments (RFC) 6480 to improve routing security.    

Unlike in web security, PKI is mainly used here to provide authorization in the form of x.509 certificates. How is that? Let’s explore beyond the surface.

The majority of routing incidents are caused by issues such as prefix hijacking, often because of Border Gateway Protocol’s (BGP’s) inability to verify whether or not an entity is authorised to originate a specific prefix. RPKI can help by allowing entities to verify whether a specific autonomous system (AS) number is indeed authorised to originate a prefix. It cannot prove that the said entity is actually what it claims to be, but for the sake of routing security, all we really need to know is that entity “X” is authorized to originate the prefix “Y”.

To implement this idea, RFC 6480 suggests an architecture that depends on three components: RPKI, signed routing objects, and a repository to hold both. Internet resource allocation mostly follows a hierarchical structure (with the exception of legacy resources) and by mimicking the same we can implement the required RPKI authorization.

Each Regional Internet Registry (RIR) gives a certificate of authorization to each resource it allocates, and allows each entity under its geographical presence to do the same. This means that any network operator can use RPKI to verify the announcements received from its peers against the signed resources. These two operations are known as Route Origin Authorization (ROA) and Route Origin Validation (ROV).

In ROA the prefix holder uses an X.509 digital certificate, with extensions for IP addresses and the AS numbers (RFC 3779) issued by an RIR, to declare which autonomous system is authorized to originate the prefix. This declaration is then stored along with the prefix holder’s digital certificate in each RIR, in what is known as the RPKI Repository.

The RIRs are tasked with issuing the digital certificates to their members. The main use of these certificates is to validate public keys and an AS’s legitimacy to use a particular AS number and to inject a particular block of prefixes into the BGP.

On the network operator side, the architecture will expect an RPKI validator server to be used, which leads us to ROV. The RPKI validator will interface with the various RIRs’ RPKI repositories in order to perform a local download of ROAs to create an RPKI table.

There are different ways to implement an RPKI validator, mainly based on open source software. When a router receives a BGP announcement, it can judge its validity by comparing its content with that of the ROAs present in the appropriate RPKI table (IPv4 / IPv6).

There are three possible outcomes for ROV, based on whether or not the prefix and AS-number BGP announcement matches an ROA: valid, invalid, or not found. How the router deals with each outcome depends on the network configuration, thus giving engineers flexibility to control their routing decisions, but also leaving the door open for potential breaches.

Below is an example of prefix hijacking, in this case, with RPKI enabled. AS1 has created relevant associations and objects using RPKI. AS4 then implements RPKI validation and checks the legitimacy of the received announcements via its validator, therefore blocking the unauthorized announcement from AS5.

Despite the additional layer of security that RPKI offers over the traditional Internet Routing Registry, it all comes down to how network engineers choose to run and operate their networks – whether or not they keep their routing information up to date and delete any obsolete objects. For example, if we change our network provider but don’t bother to delete the old ROA, we give opportunity for the old provider to make unauthorized announcements.

In fact, the human factor always plays a significant role in routing security, regardless of the underlying used technology. MANRS (Mutually Agreed Norms for Routing Security) highlights just this by depicting coordination and global validation as separate actions in its initiatives. Those two MANRS actions help promote a culture of collective responsibility toward the security and resilience of the Internet’s global routing system.

Prefix hijacking is a serious problem and many engineers have created different standards, best practices and initiatives to try to combat it. The complete solution requires commitment and aspiration for excellence from all players in the Internet – but then isn’t that what being a network engineer is all about?