What Is RPKI?

Why Do We Need RPKI?

The early Internet consisted of several core autonomous systems (ASs) and some edge ASs. These ASs exchanged routing information through an inter-AS routing protocol — BGP — to ensure reachability of Internet routes. At that time, the main objective was to transmit data successfully, and the ASs were mutually trusted. As such, the authenticity and reliability of routing information were not considered during BGP design. However, as the Internet evolved from a simple information sharing platform to a commercial platform, thousands of routable ASs have emerged on the global Internet. Today, with so many ASs, it is difficult to ensure that the routing information advertised by each AS is complete, authentic, and reliable. Without any security mechanism, inter-AS routing systems face severe security threats when peers advertise fake routing information.

BGP, a widely used inter-AS routing protocol, is the basic guarantee for interconnection and interworking between ASs around the world. However, because BGP cannot ensure the authenticity of route advertisements, route hijacking may occur due to network attacks or incorrect configurations. Route hijacking severely impacts how the Internet runs, and large-scale hijacking may even cause widespread network breakdown. Currently, one of the most serious security threats to BGP is BGP prefix hijacking, which can be classified into prefix hijacking and sub-prefix hijacking, as shown in Figure 1 (b) and Figure 1 (c). Figure 1 (a) shows a scenario in which BGP advertisement is normal. AS 1 is the valid holder of the IP address 10.1.0.0/16 and advertises the corresponding route with this prefix and the AS_Path of 1 through a BGP message. After receiving the route, AS 2 sends the IP packets whose destination addresses are included in the 10.1.0.0/16 address block to AS 1, adds its AS number to the front of the AS_Path, and advertises the route. In the route, the IP prefix is 10.1.0.0/16, and the AS_Path is <2 1>. The implementation in AS 3 and AS 4 is similar to that in AS 2.

To implement route hijacking, attackers usually forge the origin AS number in a BGP message. On the network shown in Figure 1 (b), after AS 1 advertises the route 10.1.0.0/16, AS 4 forges a route advertisement, claiming itself as the origin AS (10.1.0.0/16). In this case, AS 3 receives two routes destined for 10.1.0.0/16: one route whose AS_Path length is 2 (the real route), and another whose AS_Path length is 1 (the fake route). Because BGP prefers the route with the shortest AS_Path, AS 3 selects the fake route. As a result, all traffic to be sent to AS 1 is hijacked to AS 4. This is prefix hijacking.

In sub-prefix hijacking, attackers construct messages of more detailed BGP routes to implement route hijacking. On the network shown in Figure 1 (c), after AS 1 advertises the route 10.1.0.0/16, AS 4 constructs and sends an advertisement of a more detailed route (10.1.0.0/24). Because BGP prefers the route with the longest prefix, the traffic from AS 2 or AS 3 to 10.1.0.0/24 is sent to AS 4.

To prevent network security incidents such as route hijacking, Internet service providers (ISPs) wanted a technology that allows one or more ASs to be authorized by the valid holder of an IP address as initial route broadcasters of the IP address, to obtain authorization information, and to implement validation. In response, the IETF Secure Inter-Domain Routing (SIDR) working group proposed and standardized the RPKI protocol. In the example shown in Figure 1 (b), after RPKI is deployed, AS 3 determines that AS 1 is a valid broadcaster of the IP address 10.1.0.0/16 and that AS 4 is a fake broadcaster. In this case, route hijacking can be avoided.

The idea of RPKI comes from the Secure Border Gateway Protocol (S-BGP) solution proposed by BBN in 1997 to solve the BGP prefix hijacking problem. S-BGP validates the binding relationship between IP address prefixes and AS numbers through AS signatures that are added to BGP advertisements. However, drawbacks such as complex key management and high calculation overhead prevent the adoption of S-BGP. RPKI inherits the idea of binding IP address prefixes and ASs through signatures in S-BGP but abandons the approach of adding signatures to BGP advertisements, thereby eliminating the need to modify BGP's implementation and reducing the cost of border routers. Instead, RPKI independently stores signatures in the RPKI database in an out-of-band manner. A dedicated server obtains the signatures and certificates from the RPKI database and validates them. Routers then obtain the validation results from the server for route selection. Its compatibility with BGP and out-of-band design have allowed RPKI to be deployed.

RPKI has the following advantages:

• Ensures network security: RPKI validates AS authorization relationships, preventing network data flows from being hijacked by network attackers through forged routes and ensuring network security.
• Improves network reliability: RPKI improves route reliability and stability and reduces route leakage, improving network reliability.
• Protects users' commercial interests: RPKI prevents sensitive user information from being stolen by network attackers through forged routes, preventing economic loss.
• Promotes the healthy development of the Internet: RPKI ensures route security, thereby promoting the healthy development of the Internet.

How Does RPKI Work?

RPKI Function Extension

As an RPKI validation mechanism, regional validation controls route selection results by checking whether the routes received from EBGP peers in an external region belong to the local region. This prevents local region routes from being hijacked by attackers outside the local region, and ensures that hosts in the local region securely access internal services.

Regional validation applies to the following typical scenarios: regional validation scenario and regional confederation validation scenario.

Regional validation scenario

On the network shown in the following figure, AS 1, AS 2, and AS 3 belong to a carrier's network, and AS 3 connects to AS 100, which belongs to another carrier's network. A user accesses the server at 10.1.0.0/16 in AS 2 through AS 1. In normal cases, the user accesses the server through the path AS 1 -> AS 3 -> AS 2. If an attacker in AS 100 forges a route 10.1.0.0/24, the traffic for the user to access the server will be stolen by the attacker because the route advertised by the attacker is more specific. To solve this problem, you can configure regional validation on the border router of AS 3 and combine AS 1, AS 2, and AS 3 into region 1. With regional validation, AS 3 considers the attack route invalid or reduces its priority because although its source is AS 2, which belongs to the local region, the route is received from a BGP peer outside region 1 (in AS 100).

Regional confederation validation scenario

On the network shown in the following figure, AS 1, AS 2, and AS 3 belong to a carrier's network, and AS 4 and AS 5 belong to a partner carrier's network. AS 3 and AS 4 are connected to AS 100, which belongs to another carrier's network. A user accesses the server at 10.1.0.0/16 in AS 5 through AS 1. In normal cases, the user accesses the server through the path AS 1 -> AS 3 -> AS 4 -> AS 5. If an attacker in AS 100 forges a route 10.1.1.0/24, the traffic for the user to access the server will be stolen by the attacker because the route advertised by the attacker is more specific. To solve this problem, you can configure regional validation on the border router of AS 3, and combine AS 1, AS 2, and AS 3 into region 1, AS 4 and AS 5 into region 2, and regions 1 and 2 into regional confederation 1. With regional validation, AS 3 considers the attack route invalid or reduces its priority because although its source is AS 5, which belongs to the local regional confederation, the route is received from a BGP peer outside the regional confederation (in AS 100).