DiskSpy: Exploring a Long-Range Covert-Channel Attack via mmWave Sensing of μm-level HDD Vibrations

ImpROV: Measurement and Practical Mitigation of Collateral Damage in RPKI Route Origin Validation

Speakers: Weitong Li, Researcher, Virginia Tech; Yuze Li, Researcher, Virginia Tech; Taejoong Chung, Assistant Professor, Virginia Tech

Conference: USENIX Security

YouTube: No video available; this article is based on the peer-reviewed conference paper.

Overview

The internet's foundational routing protocol, the Border Gateway Protocol (BGP), was not designed with robust security in mind, leaving it vulnerable to various attacks, most notably prefix hijacking. To combat these vulnerabilities, the Resource Public Key Infrastructure (RPKI) was introduced, providing a cryptographic framework to authenticate the origin of IP prefix announcements. A key component of RPKI is Route Origin Validation (ROV), where routers validate incoming BGP announcements against authorized RPKI records to filter out invalid routes. While ROV significantly enhances routing security, its partial deployment across the internet has introduced a complex side effect known as collateral damage. This phenomenon occurs when an Autonomous System (AS) that performs ROV inadvertently directs traffic to an incorrect origin if subsequent hops in the path fail to perform proper validation, essentially undermining the security benefits of ROV for the validating AS.

This paper, "ImpROV: Measurement and Practical Mitigation of Collateral Damage in RPKI Route Origin Validation," by Weitong Li, Yuze Li, and Taejoong Chung from Virginia Tech, presents the first comprehensive study to quantify the extent of collateral damage in real-world RPKI deployments. Their research reveals a significant vulnerability: a staggering 85.6% of RPKI-invalid announcements are susceptible to collateral damage attacks, and alarmingly, 34% of ROV-enabled ASes remain vulnerable. To address this critical security gap, the authors introduce ImpROV, a novel, lightweight system designed to detect and avoid next hops that are likely to cause collateral damage for specific RPKI-invalid prefixes. ImpROV operates by intelligently steering traffic away from unsafe paths without impacting other unaffected IP address spaces on the data plane.

The work is crucial because it not only provides a deep, data-driven understanding of a significant, often overlooked, vulnerability in current internet routing security but also offers a practical, deployable solution. By demonstrating ImpROV's effectiveness in reducing hijack success ratios with minimal performance overhead, the authors provide a vital tool for network operators. Their findings underscore the necessity of a lightweight, deployable ROV add-on for routers to mitigate collateral damage, thereby strengthening the overall resilience of global internet routing against sophisticated hijacking attempts.

Background

The internet's global connectivity relies heavily on the Border Gateway Protocol (BGP), which enables Autonomous Systems (ASes)—independent networks—to exchange routing information and determine optimal paths for data transmission. BGP announcements specify an IP prefix and the sequence of ASes (AS PATH) traffic must traverse to reach that prefix. For example, a route might be 86.38.220.0/24, AS PATH: AS3320 AS9121 AS48678, where AS 48678 is the origin. Routers prioritize the most specific prefix match when forwarding packets. However, BGP’s original design lacked security features, making it vulnerable to attacks like prefix hijacking, where an attacker announces a legitimate prefix, or sub-prefix hijacking, where a more specific prefix is announced to divert traffic. These attacks have severe consequences, as evidenced by over 1,400 sub-prefix hijacking attacks detected during the first month of the Russia-Ukraine war alone.

To counter these threats, the Internet Engineering Task Force (IETF) developed the Resource Public Key Infrastructure (RPKI). RPKI provides a cryptographically verifiable method to map IP prefixes to their legitimate origin ASes. It consists of two main components:

1. Route Origin Authorizations (ROAs): Digital certificates created by network resource owners that authorize a specific AS to announce particular IP prefixes. These ROAs are published in public RPKI repositories managed by Regional Internet Registries (RIRs).
2. Route Origin Validation (ROV): The process by which network operators validate incoming BGP announcements against these ROAs. Relying Party (RP) software, like Routinator, fetches RPKI objects, performs cryptographic validation, and produces a list of Validated ROA Payloads (VRPs) (ASN, ROA prefix, prefix length). These VRPs are then sent to routers, allowing them to perform ROV.

When an RPKI-validating router receives a BGP announcement, it checks against the VRPs:

• Valid: The announcement matches a VRP (prefix covered, AS matches, prefix length criteria met).
• Invalid: The announcement is covered by a VRP but does not match (e.g., wrong origin AS or prefix length too specific).
• Unknown: The announcement is not covered by any VRP.

ROV-enabled ASes typically filter out RPKI-invalid announcements, preventing them from accepting or propagating malicious routes. This provides a "collateral benefit" to downstream ASes. However, a significant limitation arises because ASes usually control only the next hop, not the entire routing path. This leads to collateral damage: even if an ROV-enabled AS forwards traffic intending to reach the legitimate origin, if the next hop (or any subsequent hop) does not perform ROV, packets can still be misdirected to an invalid destination.

The paper identifies two primary types of collateral damage:

1. RPKI-invalid prefixes with more specific length: An RPKI-invalid announcement is more specific than a legitimate, RPKI-valid announcement. Due to the longest-prefix-match routing principle, a non-ROV next hop will prefer the more specific, invalid route, leading to misdirection. Figure 1 in the paper illustrates a real-world example from April 2022, where AS 36947 announced an RPKI-invalid /24 prefix more specific than AS 5511's valid /20. Even though AS 3292 (ROV-enabled) filtered the /24, it forwarded /20 traffic to AS 3320 (non-ROV), which then chose the more specific /24 path to the invalid origin.
2. RPKI-invalid prefixes with the same prefix length: An RPKI-invalid announcement has the same length as a valid one but originates from an unauthorized AS. A non-ROV next hop might choose the invalid path based on local preferences (e.g., perceived shorter path, AS relationships). Figure 2 shows an example where AS 48678 announced an RPKI-invalid 86.38.22.0/24 matching a valid prefix. AS 3292 (ROV-enabled) forwarded traffic to AS 3320, which, being non-ROV, chose an invalid path leading to AS 48678.

These examples highlight a critical vulnerability: current ROV implementations, while filtering invalid routes at the local AS, do not adapt routing decisions based on the likelihood of downstream collateral damage. ImpROV aims to address this by allowing ROV-enabled ASes to infer and avoid next hops that are prone to causing collateral damage.

Key Findings

The research conducted by Li et al. presents several crucial findings regarding the prevalence, characteristics, and impact of collateral damage in RPKI:

1. Prevalence of RPKI-Invalid Announcements: A substantial number of RPKI-invalid announcements are observed daily. Analyzing BGP update datasets from RouteViews collectors from January 2023 to March 2024, the researchers found an average of 7,934 unique RPKI-invalid prefixes announced each day. In their latest snapshot, 6,609 unique prefixes, covering 3.2 million IPv4 addresses, were RPKI-invalid. Notably, spikes in invalid announcements were attributed to specific ASes, such as AS 39891 (Saudi Telecom) and AS 35913 (DediPath), which made 646 and 921 invalid announcements respectively during certain periods.

1. Categorization of RPKI-Invalid Prefixes and Collateral Damage Vulnerability: RPKI-invalid prefixes were categorized based on their potential to cause collateral damage (Figure 4):

• Covered by RPKI-valid (66.1%): These RPKI-invalid announcements are more specific than a legitimate, RPKI-valid announcement. This category is particularly alarming as attackers can exploit the longest-prefix-match routing principle to launch highly successful hijacking attacks, even if some ASes in the path perform ROV.
• Exact match (19.5%): Both RPKI-valid and RPKI-invalid announcements exist for the same prefix. Collateral damage can occur if a non-ROV next hop prefers the invalid path based on local policies.
• No RPKI-valid coverage (14.4%): No RPKI-valid announcements cover or exactly match the RPKI-invalid ones. ROV-performing routers will drop these, meaning they do not contribute to collateral damage.

The study concludes that a staggering 85.6% (66.1% + 19.5%) of RPKI-invalid announcements are vulnerable to creating collateral damage attacks.

1. Real-World Susceptibility of ROV-Enabled ASes: Using the PEERING testbed and RIPE Atlas probes, the researchers conducted active measurements to assess real-world susceptibility. They announced both RPKI-valid (/23 from AS 47065) and RPKI-invalid (/24 from AS 61574) prefixes. Out of 3,036 ASes analyzed, 307 (34.0%) of ASes that initially couldn't reach the invalid prefix became able to reach it when the RPKI-valid covering prefix was also announced. This directly demonstrates the prevalence of collateral damage caused by upstream ASes not performing ROV, undermining downstream ROV deployments.

1. Impact of Upstream ROV Policy: The likelihood of an AS being susceptible to collateral damage is strongly influenced by its upstreams' ROV policies (Figure 5). For ASes with a single upstream, 75% were susceptible if their sole upstream did not perform ROV, whereas this dropped to 24% if their upstream did perform ROV. This highlights that even with ROV-enabled direct upstreams, collateral damage can occur if other upstream providers further along the path do not perform ROV, emphasizing the need for widespread ROV adoption and inter-AS coordination.

1. Simulation of RPKI-Covered Hijacking Incidents: Analyzing 1,376 hijacking incidents from BGPMon between January and September 2023, the study found that 729 (53.0%) were protected by RPKI. Simulations based on CAIDA AS relationship datasets and BGP route computation (local preference, shortest AS Path) revealed that 4,328 (91.5%) of the 4,730 identified ROV ASes remained vulnerable to collateral damage attacks. Specifically, more than 50% of these ASes could become victims of at least 535 attacks.

1. Attack Type Impact on Hijack Success: The type of attack significantly influences the success ratio (Figure 6). Attacks employing more specific prefixes are far more effective: 87.0% of ROV ASes were not protected against over half of such attacks. In contrast, only 4.7% of ASes were vulnerable to 50% of attacks involving same-length prefixes. This underscores that attackers can strategically craft more specific RPKI-invalid prefixes to bypass ROV, making it a critical vulnerability.

In summary, the key findings paint a sobering picture: despite the growth of RPKI/ROV, a vast majority of RPKI-invalid announcements can still cause collateral damage, and a significant portion of ROV-enabled ASes remain vulnerable, especially to more specific prefix hijacking attacks. These findings lay the groundwork for the necessity of solutions like ImpROV.

Technical Deep Dive

ImpROV (Improved Route Origin Validation) is designed as a lightweight extension to existing BGP implementations, aiming to identify and mitigate collateral damage without introducing significant performance overhead or new attack surfaces. It specifically targets BGP hijacking scenarios where an adversary announces RPKI-invalid prefixes that cause Multiple Origin ASes (MOAS) conflicts, meaning the adversary uses an ASN not legitimately authorized for the IP prefixes. ImpROV does not address AS path prepending or route leaks that do not result in MOAS.

The core principle of ImpROV is to prevent collateral damage by detecting and avoiding next hops that are likely to forward RPKI-invalid routes. Since an AS has no control over the entire path, ImpROV focuses on intelligently selecting the next hop by generating special mitigation routes, called ImpROV routes (iRoutes), and installing them into the router's Forwarding Information Base (FIB). These iRoutes are more specific than existing valid routes, effectively steering traffic away from potentially compromised paths.

ImpROV's design is guided by three goals:

• Select safe next hops for IP spaces prone to collateral damage.
• Avoid data-plane impact on IP spaces not under hijack.
• Be easily deployable with minimal performance degradation and no new attack surface.

ImpROV Mechanism for Different Collateral Damage Types

ImpROV adapts its iRoute generation based on the nature of the RPKI-invalid announcement:

1. RPKI-invalid announcement with a more-specific prefix: When an RPKI-invalid prefix is more specific than an existing RPKI-valid route, ImpROV creates an iRoute with the same more specific length, directing traffic towards a "safer" next hop. For example, if a valid /23 route exists, and an RPKI-invalid /24 is announced, ImpROV creates a /24 iRoute pointing to a safer upstream (Figure 7). This ensures that traffic for the /24 prefix is routed correctly, leveraging the longest-prefix-match principle.

1. RPKI-invalid announcement with the same-length prefix: If an RPKI-invalid announcement has the same prefix length as an existing RPKI-valid route, ImpROV deaggregates the prefix. It creates two iRoutes, each one bit longer than the original prefix, to cover the entire IP space of the RPKI-invalid prefix. These two more specific iRoutes are then directed to a safer upstream (Figure 8). For instance, an RPKI-invalid /24 would trigger the creation of two /25 iRoutes, each covering half of the /24 address space, both pointing to a safe next hop.

Overall ImpROV Operation (Figure 9)

ImpROV integrates into the BGP routing process after a BGP message is received and stored in the adj-RIB-In (Adjacent Routing Information Base - Inbound).

1. RPKI Validation: The initial RPKI validation process occurs, marking routes as valid, invalid, or unknown. Valid entries proceed to the Loc-RIB (Local Routing Information Base) for best path selection.
2. Identifying Collateral Damage: For each RPKI-invalid announcement, ImpROV checks its adj-RIB-In to see if there are any existing RPKI-valid routes that cover the announced invalid prefix. If such covering routes exist, it indicates a potential for collateral damage, and ImpROV proceeds to the next step. If no covering routes are found, or if the invalid announcement is of a type ImpROV cannot handle, the process stops for that announcement.
3. Finding the Safe Next Hop: Among the available alternative routes that cover the RPKI-invalid prefix, ImpROV must identify the "safest" next hop. Instead of relying on static lists of ROV-enabled upstreams (which can be outdated), ImpROV dynamically monitors the RPKI status of its neighbors. It prioritizes next hops that have never propagated RPKI-invalid announcements. If multiple such safe routes exist, ImpROV uses the router's standard BGP best route selection process (e.g., bgp best selection() in BIRD) to choose the optimal next hop for the iRoute.
4. Creating iRoutes: Based on the type of RPKI-invalid prefix (more specific or same-length) and the identified safe next hop, ImpROV generates the appropriate iRoutes (as described above). A crucial design decision is that these iRoutes are not propagated to neighbors (i.e., they are not installed in the adj-RIB-out). This local mitigation strategy prevents unintended consequences of propagating more specific routes across the internet.
5. Installing iRoutes: The newly created iRoutes are installed directly into the router's Forwarding Information Base (FIB), ensuring that traffic for the affected IP space is steered towards the safer next hop.

Updating iRoutes

Maintaining the integrity of the FIB requires dynamic management of iRoutes. ImpROV includes logic to update or remove iRoutes in two primary scenarios:

1. RPKI-Invalid Updates:

• Withdrawal: If the original RPKI-invalid route is withdrawn, ImpROV consults an internal iRoute Table (a pair of hash tables indexed by invalid and valid prefixes) to find and withdraw the corresponding iRoute from the FIB and the iRoute Table.
• Valid Update: If the next hop of the RPKI-invalid route updates its announcement to a valid origin AS, ImpROV recognizes that the original invalid announcement is effectively over and removes the corresponding iRoute.

1. Best Route Updates:

• New Best Route: If a new BGP update for a prefix covered by an iRoute is received and becomes the new best route, ImpROV updates the iRoute to reflect this new best next hop.
• Next Hop Withdrawal: If the next hop associated with an iRoute withdraws its route, ImpROV must update the iRoute accordingly. If no other RPKI-valid or unknown alternative route exists, the iRoute is removed from the FIB.

By implementing these mechanisms, ImpROV provides a dynamic, adaptive layer of protection against collateral damage, allowing ROV-enabled ASes to proactively mitigate risks introduced by non-ROV-enabled upstreams.

Demo / Proof of Concept

While this work is presented as a peer-reviewed conference paper rather than a recorded talk with a live demonstration, the authors provide a robust proof of concept through their implementation and extensive evaluation of ImpROV. They implemented ImpROV on two widely-used open-source BGP implementations: BIRD v.2.14 and GoBGP v.3.19.0.

The implementation details highlight the lightweight nature of ImpROV:

• Lines of Code: ImpROV required only 365 additional lines of code for GoBGP and 283 for BIRD. This minimal code footprint underscores its ease of integration and low maintenance.
• Leveraging Existing Features: A key aspect of ImpROV's design is its ability to reuse existing BGP software functionalities. For instance:
• RPKI-invalid route retention: Both BIRD and GoBGP already retain RPKI-invalid routes and validation results in their adj-RIB-In, as recommended by RFC 9324 [8]. This avoids the need for ImpROV to drastically alter the core BGP pipeline or issue frequent route refreshes.
• Route querying: Functions like fib get chain() in BIRD, which retrieve all routes covering a certain prefix, are leveraged for identifying collateral damage, avoiding the need for new data structures or search algorithms.
• FIB manipulation: Existing functions like fib insert() in BIRD are used to deploy iRoutes into the FIB.
• iRoute Table: ImpROV introduces a new table, the iRoute Table, implemented as a hash table, specifically for managing iRoutes. This structure is efficient for exact prefix matches needed for iRoute updates.

The evaluation environment consisted of an Intel® Xeon® Silver 4210R @ 2.40GHz with 187 GB of RAM, running Linux Kernel 5.4.0-54, with upstreams running on identical hardware connected via 100Gbps Ethernet. This setup allowed for realistic assessment of ImpROV's performance impact under various conditions, including BGP table convergence and continuous BGP update processing. The authors provided their code for measurement and ImpROV implementation at https://improv.netsecurelab.org.

Defensive Implications

The findings and the ImpROV system have significant implications for network defenders and operators seeking to enhance routing security:

1. Prioritize ImpROV Deployment in Conjunction with ROV: Network operators who have already deployed Route Origin Validation (ROV) should consider ImpROV a critical add-on. The study clearly demonstrates that ROV alone is insufficient, with 34% of ROV-enabled ASes remaining vulnerable to collateral damage and 91.5% of ROV ASes susceptible to specific hijacking attacks. ImpROV provides an essential layer of protection by intelligently steering traffic away from compromised paths.

1. Strategic Deployment for Maximum Impact: The collateral benefits analysis (Figure 12) shows that deploying ImpROV on even a small percentage of higher-ranked ASes (e.g., top 10% of ROV ASes) can dramatically reduce the average hijack success ratio from 37.4% to 19.54%. This suggests that prioritizing ImpROV adoption among influential ASes that serve as major internet hubs can yield disproportionately large benefits for global routing security.

1. Understanding the Evolving Threat Landscape: Defenders must recognize that attackers can leverage the longest-prefix-match routing principle by announcing more specific RPKI-invalid prefixes. ImpROV's design specifically addresses this by creating more specific iRoutes, making it a robust defense against such targeted attacks.

1. Minimal Overhead, High Return: ImpROV's lightweight implementation (minimal lines of code, reuse of existing BGP functions) and low performance overhead (2.2-2.7% memory, 2.1-3.8% CPU, 3-7% convergence time) make it a highly practical solution for integration into existing router infrastructure. The benefits in terms of reduced hijack success (50% of ASes reduce >72.6% of attacks) far outweigh the marginal resource consumption.

1. Collaboration and Widespread ROV Adoption Remain Crucial: While ImpROV offers significant local protection, the study also highlights that collateral damage decreases as more upstreams perform ROV. ImpROV's effectiveness and the number of ASes capable of deploying it grow with ROV adoption, peaking when about 50% of ASes have deployed ROV (Figure 13). This reinforces the ongoing need for broader ROV deployment across the internet. ImpROV is particularly relevant during the transition phase to widespread ROV, which is still below 18% globally.

1. Addressing DoS Concerns: The paper meticulously addresses potential security concerns, such as the use of iRoute creation as a DoS vector. It demonstrates that even under extreme scenarios (e.g., 8,800 hijacked prefixes), the additional memory usage is negligible (34.6 MB). Furthermore, even if every IPv4 prefix were hijacked and ROA-covered, memory usage would remain under 3 GB, well within the capacity of modern routers. Standard mitigation techniques like rate limiting and prefix count limits remain effective against large-scale flooding, regardless of ImpROV's presence.

In conclusion, ImpROV offers network operators a practical, effective, and resource-efficient mechanism to mitigate collateral damage in RPKI deployments. Its adoption, especially by key internet players, can significantly enhance the resilience of the internet's routing infrastructure against sophisticated prefix hijacking attacks.

Key Takeaways

• Widespread Collateral Damage: Despite ROV deployment, 85.6% of RPKI-invalid announcements are vulnerable to collateral damage, and 34% of ROV-enabled ASes remain susceptible, undermining the intended security benefits.
• More Specific Prefixes are a Major Threat: Hijacking attempts using more specific RPKI-invalid prefixes are significantly more successful, leveraging the longest-prefix-match rule to bypass ROV in downstream non-validating ASes.
• ImpROV as a Targeted Mitigation: ImpROV is a lightweight system that detects and avoids next hops likely to cause collateral damage by intelligently generating "iRoutes" (ImpROV routes) that are more specific or deaggregated, steering traffic to safer paths.
• Minimal Performance Overhead: ImpROV introduces negligible overhead, with less than 3% additional memory usage, 4% CPU usage, and 7% BGP table convergence time, making it practical for real-world deployment on BGP implementations like BIRD and GoBGP.
• High Effectiveness in Reducing Hijacks: ImpROV significantly reduces hijacking success; 50% of ASes deploying ImpROV can prevent more than 72.6% of potential collateral damage attacks.
• Strategic Deployment Amplifies Benefits: Deploying ImpROV on just 10% of top-tier ROV ASes can reduce the average successful hijack ratio from 37.4% to 19.54%, highlighting the critical role of influential ASes in enhancing global routing security.

About the Speaker(s)

The research presented in "ImpROV: Measurement and Practical Mitigation of Collateral Damage in RPKI Route Origin Validation" was conducted by a team from Virginia Tech.

Weitong Li is a researcher at Virginia Tech. His work, as demonstrated by this paper, focuses on practical aspects of network security, particularly in improving the resilience and security of internet routing protocols.

Yuze Li is also a researcher at Virginia Tech, contributing to advancements in network security. His involvement in this study underscores a commitment to understanding and mitigating real-world vulnerabilities in critical internet infrastructure.

Taejoong Chung is an Assistant Professor at Virginia Tech. His research interests lie in network security, with a strong emphasis on inter-domain routing security, RPKI, and BGP. As a lead author, Professor Chung guides efforts to bridge theoretical security concepts with practical, deployable solutions for the internet. Their collective expertise at Virginia Tech drives innovative solutions to complex routing security challenges.