3 Common Pitfalls in RPKI Deployment and How To Avoid Them

By Dr. Bahaa Al-Musawi, MANRS Fellow (2020 cohort)

Despite its critical role in Internet connectivity, Border Gateway Protocol (BGP) is still highly vulnerable to different types of attacks. While widespread adoption of Resource Public Key Infrastructure (RPKI), one of the standard ways to improve BGP security, can help, not enough network operators know about it. In this post, we explore three common knowledge gaps and give our recommendations.

Figure 1 shows the main components of the RPKI system from the perspective of a network service provider managing its Route Origin Authorization (ROA) entries from APNIC. RPKI enables autonomous systems (ASes) to validate that an AS advertising an IP Prefix in BGP is authorized to do so and thus detect and discard prefix hijacks. This form of RPKI-based filtering is termed Route Origin Validation (ROV).

1. Human error

Human error is one of the main security concerns in RPKI. Over 5% of the records in RPKI repositories conflict with legitimate long-lived BGP announcements and around 30% of the records are misconfigured. While the conflict would cause ROV-enforcing ASes to discard legitimate BGP route advertisements, hence disconnecting from thousands of legitimate destinations, the misconfiguration leaves the issuer unprotected from prefix hijacks.

There is a special risk that an inexperienced engineer using an RIR-managed RPKI portal may face when configuring ROAs for the network. This risk is to only associate the prefix to ASes they have no relationship with. For example, the network engineer could create a single ROA authorizing AS0 to announce its network prefix. As this ROA will propagate to the various networks deploying RPKI origin validation “reject invalid”, the network prefix will stop being propagated on the Internet. At that point, it might become difficult for the engineer to fix this problem, as they might not be able to connect anymore to the RIR servers to correct the configuration.

Recommendations: Even though it rarely happens, the designers and/or providers of such user interfaces should provide warnings to draw the user’s attention to the risks of using special types of ASes.

Another proposal is the designers and/or providers should give warnings by providing the name of the organization of the AS to which the owner is willing to assign its prefix. Another recommendation is using DISCO, a system for certifying ownership of IP address blocks that yields substantial security benefits while circumventing the obstacles to adoption facing RPKI and ROV.

2. The Use of MaxLength in the RPKI

The MaxLength is an attribute that provides a shorthand that authorizes an AS to originate a set of IP prefixes rather than requiring the ROA to list each prefix the AS is authorized to originate. Network operators use MaxLength for different reasons, such as providing more flexibility or easily reconfiguring their networks without modifying their RPKI objects, as well as the ability to reduce the load on routers.

However, measurements of current RPKI deployments have found that the use of the MaxLength in ROAs tends to lead to security problems. Specifically, measurements have shown that 84% of the prefixes specified in ROAs that use the MaxLength attribute are vulnerable to a forged origin sub prefix hijack.

When the MaxLength attribute is used to issue ROAs that are not minimal (a ROA is minimal when it includes only prefixes that the AS announces in BGP and no other prefixes) then they are subject to a forged-origin sub prefix hijack. The forged-origin prefix or sub prefix hijack involves inserting the legitimate AS (as specified in the ROA) as the origin AS in the AS_PATH and can be launched against any IP prefix/sub-prefix that has a ROA.

Recommendations:

Avoid using the MaxLength attribute in ROAs except in some specific cases. Whenever possible, operators should use “minimal ROAs” that authorize only those IP prefixes that are originated in BGP, and no other prefixes.

Furthermore, designers and/or providers of such user interfaces should provide warnings to draw the user’s attention to the risks of using the MaxLength attribute. Indeed, some of the user interfaces such as RIPE NCC already help operators to configure minimal ROAs, by using data from the RouteViews project to inform operators about the set of prefixes that their AS originates in BGP. The option to configure MaxLength directly could be made available for “expert users” but should come with a warning of the risks of forged-origin sub prefix hijacks.

3. Deleting ROAs from repositories

It has become a fairly common practice to leave in place the ROA associated with the exact RIR-allocated prefix length after more specific ROAs have been introduced. Although deleting ROAs from the repositories is possible, it is not an easy task. Examples of this kind of awareness were recorded on 19 December 2013 and on 26 February 2020. Both examples show operational difficulties in deleting ROAs in one of the RIRs using the RIR-hosted RPKI toolset.

Recommendation: The current recommendation from the IETF SIDROPS Working Group is that whenever possible, operators should use “minimal ROAs” that include only those IP prefixes that are originated in BGP, and no other prefixes.

In summary, it is a good idea to follow the best current practice to deploy RPKI taking into consideration the knowledge gaps and the recommendations we outline in this post.

Editor’s note: This is a guest post by a MANRS fellow. Viewpoints expressed in this post are those of the author’s and may or may not reflect official positions.