RPKI

What Is RPKI?

Resource Public Key Infrastructure (RPKI) is a technology based on PKI designed to prevent network security issues like route hijacking by verifying the authenticity and validity of BGP-advertised routing information. PKI is primarily used to manage and validate digital certificates, ensuring the security and integrity of data exchanges. RPKI applies PKI principles to secure BGP routes.

Why Do We Need RPKI?

The early Internet consisted of several core autonomous systems (ASs) and some edge ASs, which exchanged routing information via the inter-AS routing protocol BGP to ensure the reachability of Internet routes. At that time, the primary goal was successful data transmission, and mutual trust existed among ASs. Consequently, the authenticity and reliability of routing information were not prioritized in BGP's design. However, as the Internet evolved from a simple information-sharing platform to a commercial one, thousands of routable ASs emerged globally. Today, with so many ASs, ensuring that each AS's advertised routing information is complete, authentic, and reliable has become challenging. Without security mechanisms, inter-AS routing systems face severe threats when peers advertise fake routing information.

BGP, a widely used inter-AS routing protocol, is fundamental for interconnection and interworking between ASs worldwide. However, BGP cannot ensure the authenticity of route advertisements, which may lead to route hijacking due to network attacks or incorrect configurations. Route hijacking significantly impacts Internet functionality, and large-scale hijacking can cause widespread network breakdowns. Currently, BGP prefix hijacking is one of the most serious security threats to BGP. It can be categorized into prefix hijacking and sub-prefix hijacking, as shown in Figures 1(b) and 1(c). Figure 1(a) illustrates a scenario where BGP advertisement is normal. AS 1, the valid holder of the IP address 10.1.0.0/16, advertises the corresponding route with this prefix and the AS_Path of 1 through a BGP message. After receiving the route, AS 2 sends IP packets destined for addresses in the 10.1.0.0/16 block to AS 1, adds its AS number to the front of the AS_Path, and advertises the route. The IP prefix is 10.1.0.0/16, and the AS_Path is <2 1>. AS 3 and AS 4 follow a similar implementation.

To execute route hijacking, attackers usually forge the origin AS number in a BGP message. In 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). Consequently, AS 3 receives two routes destined for 10.1.0.0/16: one with an AS_Path length of 2 (the real route) and another with an AS_Path length of 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 intended for AS 1 is hijacked to AS 4. This is prefix hijacking.

In sub-prefix hijacking, attackers create messages for more detailed BGP routes to perform route hijacking. In 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 for 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 mitigate network security incidents like route hijacking, Internet service providers (ISPs) sought a technology enabling one or more Autonomous Systems (ASs) to be authorized by the legitimate holder of an IP address as initial route broadcasters for that IP address. They needed a method to obtain authorization information and validate it. In response, the IETF Secure Inter-Domain Routing (SIDR) working group proposed and standardized the RPKI protocol. Once RPKI is deployed, as illustrated in Figure 1 (b), AS 3 can ascertain that AS 1 is a valid broadcaster for the IP address 10.1.0.0/16, while identifying AS 4 as an unauthorized broadcaster. This setup effectively prevents route hijacking.

The concept of RPKI stems from the Secure Border Gateway Protocol (S-BGP) proposed by BBN in 1997 to address BGP prefix hijacking. S-BGP validates the relationship between IP address prefixes and AS numbers through AS signatures appended to BGP advertisements. However, complexities in key management and significant computational overhead hindered S-BGP adoption. RPKI retains the idea of binding IP address prefixes and ASs via signatures, as in S-BGP, but eliminates the need to modify BGP's implementation or burden border routers with additional processing. Instead, RPKI employs an out-of-band approach, storing signatures independently in the RPKI database. Dedicated servers retrieve signatures and certificates from this database for validation. Routers then access validation results from these servers to inform route selection. RPKI's compatibility with BGP and its out-of-band design have facilitated its deployment.

RPKI offers several advantages:

• Ensures network security: By validating AS authorization relationships, RPKI thwarts network attackers from hijacking data flows through forged routes, thus bolstering network security.

• Improves network reliability: RPKI enhances route reliability, stability, and reduces route leakage, thereby enhancing overall network reliability.

• Protects users' commercial interests: By preventing network attackers from exploiting forged routes to access sensitive user information, RPKI mitigates potential economic losses.

• Promotes the healthy development of the Internet: By ensuring route security, RPKI fosters the robust and healthy development of the Internet ecosystem.

How Does RPKI Work?

Key Concepts

The architecture of Internet Number Resource Allocation

The Internet Assigned Numbers Authority (IANA) is responsible for managing global Internet number resources, such as IP addresses, AS numbers, and domain names. Its primary role is to maintain the stability and security of the Internet by establishing regulations and standards for distributing these resources globally.

RPKI

Resource Public Key Infrastructure, operates as a digital certificate system providing cryptographically verifiable assurances for resources such as IP addresses and AS numbers.

Certificates

Any entity with resource allocation rights must be able to issue certificates for the reallocated resources.

RPKI certificates are issued by a certificate authority (CA) or an end entity (EE). CA certificates ensure the assignment of IP addresses and AS numbers, linking IANA with regional Internet registries (RIRs), national Internet registries (NIRs), and Internet service providers (ISPs). EE certificates validate Route Origin Authorization (ROA).

A CA, holding CA certificates, maintains a database for relying parties (RPs) to synchronize certificates and signature objects. These databases collectively form the RPKI database, a crucial component of the RPKI architecture.

ROA

Route Origin Authorization (ROA) authorizes an IP address's owner to an AS.

RPKI Database

The RPKI database stores certificates and signatures.

RPKI RP

An RPKI RP acts as a liaison between the RPKI system and the Internet's inter-AS routing system. It periodically retrieves certificates and ROA signatures from the RPKI database, validating them to establish the association between IP address prefixes and AS numbers.

RPKI Architecture

RPKI, developed by the IETF SIDR Working Group and delineated across approximately 30 RFCs, constitutes a specialized PKI framework. Among these RFCs is one that outlines the RPKI's architectural components: the certificate issuance system, certificate repository, and synchronization and validation mechanism. This architecture is pivotal in maintaining the operational integrity of the RPKI system.

The RPKI architecture comprises the following elements:

• Certificate issuance system: This system comprises RPKI certification centers distributed globally, responsible for issuing RPKI resource certificates.

• Certificate storage system: All RPKI certificates are stored within the RPKI database, which adopts a distributed storage structure composed of numerous databases.

• Certificate synchronization and validation mechanism: Relying Parties (RPs) synchronize and validate RPKI certificates and signature objects from the RPKI database. Subsequently, these RPs furnish the validation outcomes (depicting the binding relationship between IP address prefixes and AS numbers) to the Internet's inter-AS routing system, constituted of BGP routers positioned across different ASs. These routers then utilize the validation outcomes to filter routes.

  

Route Origin Validation Process

As depicted in the illustration below, the RPKI certificate issuance system aligns with the architecture of Internet number resource allocation. This system sequentially issues resource certificates, authorizing resources from higher to lower levels. These certificates delineate the association between IP address prefixes/AS numbers and recipient entities, affirming the authorization of resource utilization by the respective resource holder.

The Asia-Pacific Network Information Center (APNIC) issues a self-signed root certificate (1) with the following attributes: {issuer: APNIC; receiver: APNIC; number resource: 10.1.0.0/16, 10.2.0.0/16, AS 1-AS 99}. Upon generation, APNIC stores this certificate in its own database. APNIC then utilizes root certificate (1) to issue a resource certificate (2) to ISP1, containing the attributes: {issuer: APNIC; receiver: ISP1; number resource: 10.1.0.0/18, 10.2.0.0/20, AS 1-AS 9}. Once generated, ISP1 stores this resource certificate in its own database. Subsequently, ISP1 employs certificate (2) to issue an ROA signature (3) with the following details: {issuer: ISP1, binding relationship: 10.1.1.0/24 & AS 1}. This ROA signature delineates the binding relationship between an IP prefix and an AS number, authorizing the AS to initiate route origin advertisements.

In the network illustrated in the diagram below, Device B within AS 200 receives two route origin advertisements sharing the same prefix (10.1.1.0/24) but originating from different AS numbers. Absent RPKI, Device B cannot ascertain the valid origin AS. With the deployment of an RPKI RP, Device B can retrieve the ROA database from the RPKI database. Based on this database, Device B confirms the validity of the binding relationship <10.1.1.0/24 AS 100>. Upon receiving two routes with the same prefix (10.1.1.0/24) but differing AS numbers, one from AS 100 and the other from AS 300, Device B cross-references the origin AS numbers against the ROA database. The route originating from AS 100 is validated as its origin AS aligns with the ROA database, rendering the route advertisement from AS 100 valid. Conversely, the route from AS 300 is deemed invalid as its origin AS does not match the ROA database, rendering the route advertisement from AS 300 invalid.

In the absence of an RPKI RP, Device B can configure a static ROA database to facilitate ROA validation, which also serves to mitigate route hijacking to some extent.

RPKI Function Extension

As part of the RPKI validation mechanism, regional validation ensures route selection accuracy by verifying if routes received from EBGP peers in external regions belong to the local region. This safeguard prevents local region routes from being hijacked by external attackers, thereby ensuring secure access to internal services for hosts within the local region.

Regional validation is applicable in two main scenarios: the regional validation scenario and the regional confederation validation scenario.

Regional validation scenario

In the regional validation scenario, illustrated in the diagram below, AS 1, AS 2, and AS 3 are part of a carrier's network, with AS 3 connecting to AS 100 of another carrier's network. A user accesses a server at 10.1.0.0/16 in AS 2 via AS 1. Under normal circumstances, the user's path to the server is AS 1 -> AS 3 -> AS 2. However, if an attacker in AS 100 fabricates a route for 10.1.0.0/24, the user's traffic intended for the server may be diverted to the attacker due to the specificity of the route advertised. To mitigate this risk, regional validation can be configured on AS 3's border router, grouping AS 1, AS 2, and AS 3 into region 1. With regional validation in place, AS 3 would deem the fraudulent route invalid or assign it lower priority because although originated from AS 2 within the local region, the route was received from a BGP peer outside of region 1 (in AS 100).

Regional confederation validation scenario

In the regional confederation validation scenario depicted in the diagram below, AS 1, AS 2, and AS 3 form part of a carrier's network, while AS 4 and AS 5 are within a partner carrier's network. AS 3 and AS 4 connect to AS 100, belonging to yet another carrier's network. A user accesses a server at 10.1.0.0/16 in AS 5 via AS 1. Under normal circumstances, the user's path to the server is AS 1 -> AS 3 -> AS 4 -> AS 5. However, if an attacker in AS 100 fabricates a route for 10.1.1.0/24, the user's traffic intended for the server may be diverted to the attacker due to the specificity of the route advertised. To address this issue, regional validation can be configured on AS 3's border router, grouping AS 1, AS 2, and AS 3 into region 1, AS 4 and AS 5 into region 2, and then consolidating regions 1 and 2 into regional confederation 1. With regional validation, AS 3 would consider the attack route invalid or lower its priority because although originating from AS 5 within the local regional confederation, the route was received from a BGP peer outside the regional confederation (in AS 100).