]> Beijing Zhongguancun Laboratory

Building 8, CourtYard 1, Zhongguancun East Road, Haidian District Beijing China wangsh@mail.zgclab.edu.cn

Beijing Zhongguancun Laboratory and Tsinghua University

Beijing China xuke@zgclab.edu.cn

Beijing Zhongguancun Laboratory and Tsinghua University

Beijing China liqi@zgclab.edu.cn

Beijing Zhongguancun Laboratory and Tsinghua University

Beijing China liuzhuotao@zgclab.edu.cn

Routing Area SIDROPS RPKI ROA VRP In the Resource Public Key Infrastructure (RPKI), validating prefix-origin pairs using Route Origin Authorizations (ROAs) globally and performing Route Origin Validation (ROV) locally at each Autonomous System (AS) with validated ROA payloads (VRPs) can lead to inconsistent results due to partial route visibility. This document highlights how partial route visibility can turn originally non-loose ROAs into loose VRPs, outlines the causes of partial route visibility, and discusses potential solutions to mitigate the issue.

Introduction Route hijacking is a significant vulnerability in the Border Gateway Protocol (BGP) due to lack of restrictions on prefix ownership claims. To combat this, the Resource Public Key Infrastructure (RPKI) was introduced to validate prefix-origin pairs. Prefix owners issue Route Origin Authorizations (ROAs) specifying the prefix-origin pairs to RPKI repositories. Relying parties (RPs) in each autonomous system (AS) then download the ROAs, generate Validated ROA Payloads (VRPs), and distribute them to border routers. These routers use VRPs to perform Route Origin Validation (ROV) . A common misconception is that without engineering errors (e.g., issues with the RPKI repository, RP malfunctions, or ROV execution failures), a secure ROA would yield a secure VRP in certain. "Secure" means each covered prefix is protected from route hijacking. However, in reality, routes from the origin AS and the corresponding ROAs travel through different channels. Routes are distributed via BGP and may be affected by transit AS policies. In contrast, ROAs are stored in global RPKI repositories, so they are accessible to RPs in all locations. This divergence can lead to inconsistencies between validation using ROAs from global repositories and ROV with local VRPs. This memo will first address the problem of route partial visibility: validation of routes could be inconsistent with either ROAs or VRPs. Then possible causes which could lead to route partial visibility are summarized. Finally, the memo will discuss potential solutions to resolve or mitigate the resulting vulnerabilities.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Problem Statement The concept of a "loose" ROA is defined as, a ROA whose sub-prefixes of the maximum length allowed by itself are not always advertised in BGP . For example, in Figure 1, within the prefix range 185.70.140.0/22-24, AS 201411 originates two prefixes, B (185.70.140.0/23) and D (185.70.140.0/24), and issues a ROA (AS 201411, 185.70.140.0/23-24), marked with asterisks (*). Any other prefixes in this prefix range are not announced by any AS. Since prefix E (185.70.141.0/24) is not announced, the ROA is considered loose.

Vulnerabilities of Loose ROAs A sub-prefix S which causes a ROA to be loose faces two primary vulnerabilities:

• Super-prefix Hijacking: An attacker can announce a super-prefix of S, such as A (185.70.140.0/22) in Figure 1, with the same origin AS. This route will be validated as "not-found" since its prefix length is shorter than the ROA's prefix range (23-24) and won't be filtered. Because prefix E (185.70.141.0/24) is not announced, the attack route will be the best route for addresses in prefix E, leading to traffic hijacking.
• Forged-Origin Hijacking: An attacker can announce a route with S and the original AS as the origin but with a fake AS path that includes the attacker’s AS. This type of hijacking can also affect non-loose ROAs but is guaranteed to succeed against loose ROAs. In Figure 1, if an attacker announces prefix E with an AS path ending in AS 201411, it will be validated as "valid" and selected as the best route for addresses in prefix E. Consequently, traffic will follow the attack route into the attacker's AS, resulting in hijacking.

Refined Definitions for Loose ROAs and VRPs The previous definition of loose ROAs misses certain corner cases. For example, in Figure 2, AS 201411 originates two prefixes, D (185.70.140.0/24) and E (185.70.141.0/24), but issues three ROAs: (AS 201411, 185.70.140.0/23-23), (AS 201411, 185.70.140.0/24-24), and (AS 201411, 185.70.141.0/24-24). These can be combined into one single ROA (AS 201411, 185.70.140.0/23-24). This ROA is not loose because all its sub-prefixes of the maximum length allowed are advertised in BGP. Therefore, for a strict definition, a ROA is non-loose if, for any address I covered by the ROA R, there exists an advertised route that:

1. Covers I.
2. Is validated as valid (not necessarily by R).
3. Has the longest prefix length among advertised routes whose prefixes cover I.
4. Has a prefix length greater than or equal to R’s MaxLength (Lm).

If these conditions are not met, the ROA R is considered loose. Since VRPs are derived from ROAs, "loose VRPs" can be similarly defined from "loose ROAs." The main difference is that for VRPs, "the route should be advertised" changes to "the route should be in the router’s local RIB" (Routing Information Base). This is because ROAs apply to globally announced routes, while VRPs are used within each AS and validate locally received routes. Therefore, only routes visible to the local router determine VRP looseness. Therfore, a VRP is non-loose if, for any address I covered by the VRP V on a border router, there always exists a route in the router's local RIB that:

1. Covers I.
2. Is validated as valid (not necessarily by V).
3. Has the longest prefix length among all routes in the local RIB whose prefixes cover I.
4. Has a prefix length greater than or equal to V’s MaxLength (Lm).

If these conditions are not met, the VRP V is considered loose.

Route Partial Visibility In theory, the origin AS can control its own ROA issuance to ensure consistency with its advertised routes but cannot ensure other ASes will receive these routes precisely. A route initially announced may fail to propagate to another AS. If this route's prefix is a sub-prefix within the maximum length allowed by the origin AS's ROA, the resulting VRP at the observer AS will be loose. We term this phenomenon, where a route announced with a ROA is not visible to all ASes, as route partial visibility. In conclusion, a key issue with ROV is that non-loose ROAs don't always produce non-loose VRPs due to the partial visibility of announced routes.

Causes of Route Partial Visibility The general process for the formation of route partial visibility is outlined as follows. For a given origin AS, it issues ROAs for all its active and advertised prefixes, ensuring these ROAs are initially non-loose. "Active" means that neither the prefixes nor their sub-prefixes are expired or revoked. However, when a route from the origin AS reaches a transit AS, certain BGP routing policies may alter it. This could involve dropping the route, or changing its prefix or origin AS and then propagating the modified route. If the route is dropped, any AS that does not receive it will likely have loose VRPs. Even if the route is altered but not dropped, the VRP at an observer AS may still become loose, since the prefix may no longer match with the VRP. These transit AS policies, which we term "policies with hidden danger," inadvertently disrupt RPKI ROV. Below are possible types of policies that may drop or alter passing routes.

Explicit Route Filtering The simplest type of policy is explicit route filtering, including import/export filtering, route blackholing, route damping, and similar mechanisms. When a transit AS applies such policies, it directly drops routes for specific prefixes. As a result, these prefixes will have no corresponding routes in the downstream ASes of the transit AS.

Implicit Route Filtering When certain policies combine, they can implicitly drop routes. Consider this scenario in Figure 3: a MOAS prefix is announced by different ASes (AS a and AS b), with only AS a issuing a ROA for the prefix. Both routes reach an ROV-disabled AS (AS d), where the route selection policy retains only one route per prefix. Due to a shorter AS path, AS d keeps the route from AS b and discards the valid route from AS a. This route from AS b continues spreading until it reaches an ROV-enabled AS (AS e). Since the prefix has a ROA only for AS a, the ROV policy at AS e marks the route from AS b as invalid and drops it. Consequently, there will be no route for the MOAS prefix in downstream ASes.

Route De-aggregation In addition to dropping routes, routing policies can also transform prefixes within routes. One such transformation is route de-aggregation. In this process, the origin AS remains unchanged, but the original route is replaced with one or more routes for the sub-prefixes. If any de-aggregated prefix exceeds the maxLength specified in its matching VRP, it will be validated as invalid and get dropped, making the de-aggregation ineffective. Additionally, the absence of routes for the de-aggregated prefixes can make the VRP loose.

Route Aggregation The opposite transformation is route aggregation. Route aggregation suppresses the original routes and generates a new route with a super-prefix encompassing all original prefixes. The ROV status of the aggregated route can vary:

1. Valid: If the aggregated prefix has a ROA and the origin AS matches the transit AS performing the aggregation.
2. Not Found: If no ROA exists for the aggregated prefix. For a successful super-prefix hijack, the attack route must be shorter than all original prefixes but not shorter than the aggregated prefix.
3. Invalid: If another ROA exists for a different origin AS for the aggregated prefix or any super-prefix of it, causing the aggregated route to be filtered and the aggregation to fail. Additionally, the absence of routes for the de-aggregated prefix may contribute to VRP looseness.

Potential Solutions Since there is no prior work formally addressing the problem, no solutions exist to systematically eliminate the issue in ROV with route partially visibility. Generally, there are two main approaches to address the problem: one is to eliminate potential risks by addressing policies with hidden dangers, and the other is to defend against damages when attacks occur due to these policies.

Report Policies with Hidden Danger To resolve the issue fundamentally, transit ASes must report policies with potential hidden dangers. The reporting approach depends on the policy type:

• Route Filtering: ROAs cannot prevent super-prefix hijacks since an attacker can always announce a route with a shorter prefix, making its ROV state "not found." Ideally, the transit AS should inform all its downstream ASes about the filtered routes, allowing them to inspect overlapping prefixes in their received routes.
• Route Transformation (Aggregation or De-aggregation): The transit AS should notify the origin ASes. For de-aggregation, origin ASes should issue additional ROAs for the de-aggregated prefixes. For aggregation, the transit AS should additionally obtain permissions from all origin ASes to announce a ROA itself for the aggregated prefix.

Implementing this proposal is challenging for several reasons. First, transit ASes may be reluctant to disclose routing policies for security reasons and see no benefit, as their own policies do not affect them negatively. Second, malicious transit ASes might provide false information about their policies. Additionally, other ASes may be unwilling to adjust their routing policies or ROAs based on claims from another AS.

Defend Against Attacks Exploiting Loose VRPs A more practical approach is to let each observer AS handle the defense, without involving the transit AS. While observer ASes may not know which routes are partially visible to them, they can still defend against potential forged-origin and super-prefix hijacks. There are already many recent studies focusing on defending forged-origin hijacks, and their main idea is combining the AS path feature and validating the AS path of received routes, such as using ASPA . For super-prefix hijacks, solutions fall into two categories:

• At RPKI Level: Observer ASes can independently add, delete, or modify local VRPs using techniques such as SLURM , which is effective for route transformations.
• At BGP Level: Observer ASes can add blocking rules or make blackhole announcements for routes that could trigger super-prefix hijacks, which is suitable for route filtering.

In summary, defending against the vulnerabilities of loose VRPs requires systematic efforts.

Security Considerations There is no security consideration in this draft.

IANA Considerations There is no IANA consideration in this draft.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK] This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol.[STANDARDS-TRACK] To help reduce well-known threats against BGP including prefix misannouncing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] Informative References The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed. To help reduce well-known threats against BGP including prefix misannouncing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] Yandex Qrator Labs Internet Initiative Japan and Arrcus, Inc. Arrcus Fastly USA National Institute of Standards and Technology This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This type of AS_PATH verification provides detection and mitigation of route leaks and some forms of AS path manipulation. It also provides protection, to some degree, against prefix hijacks with forged-origin or forged- path-segment.