RPKI: The Invisible Pillar Holding the Internet Together

11/02/2025

By Carlos Martinez Cagnazzo, LACNIC CTO

The Internet consists of millions of interconnected devices exchanging information, allowing data to be sent and received to and from anywhere in the world. But how is this network built and what holds it together?

At the core of the Internet are devices whose function is basically to forward packets of information, in other words, to receive incoming packets and then send them elsewhere. What does this process look like? Each device responsible for forwarding packets has a table that determines the correct exit port based on a packet’s destination. This is known as forwarding and it is one of the key functions of the Internet.

The next question is “How is this table populated?” One option is manual configuration (static routing), a common method used in the early days of the Internet. However, in large-scale networks, this process is automated through routing protocols.

If we think of the Internet as a collection of networks or a ‘cloud’ of interconnected devices, the Border Gateway Protocol (BGP) is the routing protocol that allows these networks or clouds to talk to each other.BGP allows each cloud to tell its neighboring cloud: “I know all of these IP addresses and can carry your traffic to them.” The neighboring cloud provides a similar response. In turn, these clouds or networks ‘talk’ to other clouds with which they exchange their own information, and this is how their own data and information from others nearby is propagated.

The version of BGP in use today has been around for approximately 30 years. So, what is going on with this protocol? For many years, BGP worked without any issues. However, sometime in the mid-2000s, it became evident that these clouds or autonomous systems were not only referencing their own IP addresses but also others, which they knew nothing about. And what is the impact of this? That some traffic ends up reaching destinations it shouldn’t. Given that the whole purpose of routing is to direct packets to their legitimate destination, when one of the clouds participating on the Internet provides incorrect information regarding an IP address, the result is that part of the traffic is directed to an illegitimate location.

Initially, these situations were caused by operational errors. However, in 2008, one of the most infamous BGP hijacks occurred, involving Pakistan’s state-owned telecommunications company, PTCL, and YouTube. Because of a video it deemed anti-Islamic, the Pakistani government ordered ISPs to block access to YouTube for its citizens. To enforce this, PTCL announced more specific BGP routes to YouTube’s network to intentionally hijack Pakistan’s traffic to the video streaming service. Once hijacked, PTCL’s goal was to send the traffic into a black hole, preventing people in Pakistan from accessing YouTube. But things escalated when PTCL propagated these routes to its international transit providers, who in turn propagated them worldwide, thus blocking YouTube for a large portion of the global Internet.

This is an example of what is known as ‘route hijacking,’ where an autonomous system advertises that it knows how to reach certain destinations it doesn’t know how to reach, or which lack the capacity to handle the amount of traffic.

The Pakistan Telecom incident was a case of unintentional route hijacking resulting from an error in the operation of its network. However, route hijacking can also be the result of a malicious action.

Basically, if someone captures another network’s traffic, they can exploit, analyze, or otherwise manipulate it. For example, in the case of blockchain technology, a blockchain’s operation relies on their nodes being able to talk to each other. In fact, there is a documented attack against a blockchain that was executed by hijacking part of its nodes’ communication routes.

So, how was the Internet protected for many years from this type of threat? Essentially, by assuming that each cloud would perform some level of manual verification of the routes announced by its neighbors. For example, if Antel established a BGP session with Telecom Argentina, Telecom Argentina was supposed to perform some kind of verification of the routes announced by Antel and vice versa.

The problem is that this type of manual supervision is very difficult to maintain. Following the events of 2008, the Internet Engineering Task Force (IETF) set out to improve this system and RPKI emerged as the initial solution: a set of technologies that allow routers to independently verify the information they receive and calculate the routing table based on this data.

Specifically, RPKI is a public key infrastructure framework designed to offer providers additional tools to validate a customer’s right to use particular Internet resources. It incorporates Route Origin Attestations (ROAs), digitally signed objects that establish an association between a set of prefixes (IPv4 or IPv6) and the autonomous system authorized to originate a route for these prefixes in BGP advertisements. This allows automatically comparing the information received via BGP against the information contained in the ROAs.

It is worth noting that RIRs, the organizations that assign the IP addresses, serve as trust anchors for this information, as what a router needs to know in order to determine whether an advertisement is valid or invalid under RPKI is whether the originating autonomous system that mentions a specific IP prefix is ​​the legitimate holder of those IP addresses. Additionally, a chain of digital signatures certifies that this statement has been issued properly.

In this regard, another point I wish to emphasize is how important and urgent it is for operators in the region to enable their routing policies and for LACNIC members to increase the IP address space covered by RPKI, which is why part of our efforts are directed to verifying the validity of their certificates. An encouraging development is the positive evolution of the percentage of routes announced by our region that are covered by RPKI ROAs: as of November 2024, 54.6% of the region’s IPv4 routes and 55.4% of IPv6 routes were covered by ROAs.

We also observe that LACNIC members’ use of the Internet Routing Registry (IRR, a global database documenting routing information among network operators) and RPKI services continues to grow, accompanying the adoption by content providers and carriers of security checks based on IRR and RPKI as a requirement for establishing peering and transit agreements.