]> Tsinghua University

30 Shuangqing Road Beijing 100084 China qli01@tsinghua.edu.cn

Tsinghua University

30 Shuangqing Road Beijing 100084 China yh-chen21@mails.tsinghua.edu.cn

Tsinghua University

30 Shuangqing Road Beijing 100084 China xuke@tsinghua.edu.cn

Tsinghua University

30 Shuangqing Road Beijing 100084 China zhuotaoliu@tsinghua.edu.cn

Tsinghua University

30 Shuangqing Road Beijing 100084 China jianping@cernet.edu.cn

Operations and Management SIDROPS Working Group Resource Public Key Infrastructure Route Origin Validation BGP Hijacking This document describes how incomplete adoption of Route Origin Validation (ROV) makes certain forms of BGP hijacking less visible on the control plane while still capable of diverting traffic. We explain the underlying mechanism, define the form of the threat, analyze an real-world incident that exemplifies the issue, and discuss potential countermeasures to mitigate its impact.

Introduction BGP hijacking occurs when an Autonomous System (AS), accidentally or maliciously, mis-announces an address prefix it is not authorized to originate. ASes that accept such announcement may divert traffic destined for the prefix to an incorrect AS instead of the actual prefix holder. To mitigate this risk, Route Origin Validation (ROV) was introduced as part of the Resource Public Key Infrastructure (RPKI) . ROV-enabled ASes validate route announcements using Route Origin Authorizations (ROAs) , which specify which ASes are permitted to originate specfic prefixes. The best current practice suggests configuring routing policies to drop or give a very low preference to routes deemed invalid by ROV. However, ROV adoption across the Internet is incomplete and expected to remain so for the foreseeable future. In such a state, invalid announcements may still propagate through non-ROV ASes to a certain extent, before being dropped by ROV-enabled ASes. This limited propagation creates a situation where some ASes never receive the invalid routes and are therefore unware of the ongoing incident (e.g., potential BGP hijacking). Yet they are not fully protected either, as the traffic they originate, along the data forwarding path, may traverse a non-ROV AS that has accepted the invalid route. This non-ROV AS will forward traffic towards the incorrect origin AS. As a result, the traffic originating ASes unknowingly fall victim to BGP hijacking, unless they conduct active measurements (e.g., traceroute) or receive alerts from other network operators who spot the incident. In effect, BGP hijacking becomes stealthier in this case, due to incomplete adoption of ROV across global ASes. The objective of this document is to highlight the side effect of incomplete ROV adoption on BGP hijacking, which results in highly stealthy BGP hijacking that is invisible to victims on the control plane. This document defines this form of BGP hijacking, explains its underlying mechanisms, analyzes a real-world incident, and discusses possible detection and mitigation approaches. The rest of this document is structured as follows: Section 2 details the side effect of ROV in incomplete adoption. Section 3 defines the resulting stealthy BGP hijacking. Section 4 analyzes a representative real-world incident. Section 5 discusses potential detection and mitigation strategies. Finally, Section 6 concludes the document.

Side Effect of Incomplete ROV Adoption This section explains how BGP hijacking can still succeed and even become stealthier under incomplete ROV adoption. illustrates the control-plane behavior when a malicious AS initiates a BGP hijacking attempt. In this scenario, AS G (the hijacker) announces a (sub-)prefix legitimately owned by AS E (the target). ROV-enabled ASes B and D filter out the invalid announcement, so only AS C and F may accept the hijacker's route into their routing tables, depending on their routing policies.

| | | | <~~ <~~ ==> E's announcement | +------+ +------+ ~~> G's announcement +---------| AS F |------| AS G | +------+ +-Hijker ==> ==> ]]>

Consider AS A as an example. AS A only receives a route to the legitimate origin (AS E), since its upstream provider AS B rejects the invalid route. As a result, from AS A's control-plane perspective, the only available route is valid, and one can expect traffic destined for the target to be correctly delivered. However, as shown in , from a global perspective, AS A's traffic is forwarded through AS C, which accpets the hijacker's route. In this case, the traffic is silently redirected to the hijacker.

+------+ +------+ +------+ +------+ +------+ | AS A |------| AS B |------| AS C |------| AS D |------| AS E | +------+ +----ROV +------+ +----ROV +-Target | --------------------------+ | (Actual forwarding path) | | | | | | | | +------+ +------+ | +---------| AS F |------| AS G | | +------+ +-Hijker | +--------------------------------> ]]>

Because AS A lacks a route to the hijacker, it remains unaware of the attack unless it conducts active measurements (e.g., traceroute) or receives external notifications. Its local control-plane protections are ineffective in detecting or responding to the hijack in this case. This highlights an unexpected side effect of incomplete ROV adoption: it prevents certain ASes from observing invalid routes, making ongoing hijacking more difficult to detect. We refer to such BGP hijacking, which compromises traffic forwarding while remaining invisible to affected ASes on the control plane, as stealthy BGP hijacking. An AS is susceptible to stealthy BGP hijacking if: It has no route to the hijacker due to ROV filtering, and At least one non-ROV AS along the legitimate path accepts the hijacker's route. This vulnerability applies to both BGP hijacking that targets a prefix and a sub-prefix.

Definition of Stealthy BGP Hijacking From a control-plane-only standpoint, this section defines stealthy BGP hijacking under incomplete ROV adoption.

Notation and Terminology In this document, we use the following notation to describe BGP routes: p: V ... (M) ... O This notation represents a BGP route to prefix p as observed from a vantage point V. The sequence of ASes from V to the origin O may include one or more intermediate ASes M. The symbols used are defined as:

p:

The IP prefix being routed.

V:

The vantage point, i.e., the AS from which the route is observed (typically via a BGP route collector).

M:

An intermediate AS, representing any AS that appears on the path from V to the origin O. There may be multiple such ASes, or may be none.

O:

The origin AS, which originates the route and claims to originate the prefix p.

We also define the following terminology for clarity in later discussions:

Conflict:

Two routes are said to be in conflict if they refer to the same prefix or to overlapping prefixes (e.g., one is a more specific sub-prefix of the other), but their origin ASes differ. This indicates a potential inconsistency in prefix ownership or announcement.

RPKI-invalid:

A route is considered RPKI-invalid if its prefix matches an ROA, but the origin AS does not match the AS specified, or the prefix exceeds the max length specified allowable for origination. This typically signals an unauthorized or misconfigured route announcement, which may lead to BGP hijacking.

RPKI-valid:

A route is considered RPKI-valid if its origin AS matches an ROA for the prefix under RPKI, and the route is not RPKI-invalid.

Risk-critical:

An AS is said to be risk-critical if it chooses to forward traffic towards an invalid route to the hijacker, while it also has route to the legitimate origin in its routing table.

Stealthy BGP Hijacking Definition Given a pair of observed routes: p1: V1 ... (M1) ... O1 p2: V2 ... (M2) ... O2 A stealthy BGP hijacking is said to occur when the following conditions hold: The two routes conflict, i.e., p2 is equal to or a more specific sub-prefix of p1, and O2 does not equal to O1. Their authorization states disagree, i.e., the prefix-origin p2-O2 is RPKI-invalid, while p1-O1 is RPKI-valid. The invalid route is invisible to the victim, i.e., vantage point V1 has no observable route to prefix p2 that is originated by O2. A risk-critical AS redirects traffic to the hijacker, i.e., there exists M1 such that M1 equals V2. Under these conditions, O2 is a potential hijacker that announces the prefix p2, which is owned by O1. The invalid route does not propagate to vantage point V1. As a result, V1 observes only the legitimate route to p1 and remains unaware of the conflicting route to p2 originated by O1. However, due to the presence of a risk-critical AS M1, which appears in the legitimate path and also has a route to p2, traffic destined for p2 is silently diverted to the hijacker.

Real-World Incident Example This section presents an real-world incident consistent with the definition of stealthy BGP hijacking in . The incident was last observed on April 24, 2025. As illustrated in , both AS37100 (SEACOM) and AS6762 (TISparkle) observe the prefix 203.127.0.0/16 announced by its legitimate origin, AS3758 (SingNet). Meanwhile, the sub-prefix 203.127.225.0/24 is announced by an unauthorized origin, AS17894 (Innove Communications). The two origins are located in different countries and have no link between them ever observed during the most recent month. According to the APNIC's ROV filtering measurement , AS37100 adopts ROV with a 100% filtering rate. Therefore, it discards the RPKI-invalid /24 route. However, traffic from AS37100 (or its downstream customers) to the /24 prefix is still hijacked when it transits through non-ROV AS6762, which accepts the /24 route.

+---------+ +---------+ +---------+ +---------+ | AS37100 |--------| AS6762 |--------| AS7473 |--------| AS3758 | | SEACOM | |TISparkle| | SingTel | | SingNet | +---------+ +---------+ +---------+ +---------+ ROV-enabled @ | | | | | +----------+ +---------+ +-----------+ | +-| AS15412 |---| AS4775 |---| AS17894 | @: vantage point | | FLAG Tel | |Globe Tel| |Innove Comm| | +----------+ +---------+ +-----------+ | +------------------------------------------> Route to 203.127.225.0/24 ]]>

An examination using AS37100's looking glass "lg-01-ams.nl" corroborates the hijack. The command "show ip bgp 203.127.0.0/16" shows a valid route via the path 37100 6762 6461 7473 3758. Meanwhile, "show ip bgp 203.127.225.0/24" returns no matching routes, confirming that AS37100 does not have visibility of the route from the unauthorized origin AS17894. However, a traceroute from AS37100 to an address within 203.127.225.0/24 shows that the final hops traverse AS17894, indicating that traffic is indeed diverted to the illegitimate origin, demonstrating a successful hijack at the data plane, even though control-plane filtering is in place. We emphasize that the incident, while in the form of stealthy BGP hijacking, is likely caused by benign misconfigurations, given that AS17894 and AS3758 have business connections through their parent companies , We reported the incident to AS4775 (Globe Telecoms) on February 10, 2025, and received confirmationa that it would investigate. The original looking glass output is provided in .

Detection and Mitigation The definition of stealthy BGP hijacking naturally enables a practical detection method based on inconsistencies across routing tables. By comparing routing data from multiple vantage points, one can identify route pairs that satisfy the conditions outlined in , and thereby enable timely alert of ongoing incidents. The routing data can be collected from self-operated ASes or public platforms, such as RouteViews and RIPE RIS . The incident discussed in was discovered using this approach. In fact, an existing public monitoring service already applies this method to track stealthy BGP hijacking events in real time . We emphasize that increasing ROV adoption across global ASes remains essential for improving BGP security. As the adoption rate increases, the feasibility and impact of stealthy BGP hijacking are expected to diminish significantly. Meanwhile, immediate countermeasures are available. One such approach is ROV++ , which extends the standard ROV with proactive rerouting and blackholing capabilities. In this proposal, when an AS enforcing ROV++ detects an RPKI-invalid route, it not only drops the invalid route but also initiates a route selection process that tries to find an alternative route that does not contain any ASes appearing on the invalid path, thus avoiding any risk-critical ASes. If no such alternative route exists, the AS blackholes the corresponding prefix, as operators arguably prefer controlled blackholing over potential hijacking by malicious actors. Similarly, Cisco's patent describes a poison-path routing policy that can mitigate stealth BGP hijacking. In this proposal, when a BGP router detects a route to a hijacked prefix, it searches for alternative routes that cover the hijacked prefix but share no ASes with the hijacked route. The router then selects such an alternative route, avoiding ASes that might divert traffic. While conceptually similar to ROV++'s rerouting mechanism, this poison-path policy is applicable to any AS, not limited to ROV adopters. While the aforementioned proactive mitigations are available, they tend to be overly aggressive as they nondeterministically overwrite normal routing policies at runtime. Considering the cause of stealthy BGP hijacking, the lack of transparency into dropped routes is what makes such hijacking subtle and less visible. As such, it is important to note that dropped routes often carry valuable signals of abnormal events in the global routing system, yet these signals are simply dropped along with the routes. Therefore, improving transparency of dropped routes presents another viable approach to mitigate not only stealthy BGP hijacking but also more general routing anomalies. For example, an information-sharing platform, such as a dedicated mailing list where ROV adopters can publish digests of dropped routes, could help potential victims identify risk-critical ASes and determine response actions on their own. We anticipate drafts on such a scheme in the future.

Conclusion This document formalizes stealthy BGP hijacking, a threat enabled by incomplete ROV adoption that evades control-plane detection while still diverting traffic. We define its conditions, present a real-world case, and demonstrate how it can be detected via routing table comparisons across vantage points. While broader ROV adoption remains essential, mechanisms like ROV++ offer practical mitigation by enabling coordination among ROV-enabled ASes. Addressing this risk is critical for improving the security of interdomain routing.

IANA Considerations This document includes no request to IANA.

Security Considerations The stealthy BGP hijacking behavior described in this document can be actively exploited by malicious ASes to divert traffic with less likelihood of being detected. While the success of such attacks depends on factors like accurate knowledge of ROV deployment, their impact can be significant, particularly in scenarios involving non-ROV transit. Detection and mitigation strategies are discussed in . Network operators are advised to adopt ROV where possible, explore collaborative defenses such as ROV++, and monitor both control- and data-plane behavior to identify and respond to suspicious routing activity.

This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. 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. This document obsoletes RFC 6482. To help reduce well-known threats against BGP including prefix mis- announcing 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] Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations. This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. APNIC University of Oregon Route Views Project RIPE NCC University of Connecticut University of Connecticut University of Connecticut University of Connecticut University of Connecticut University of Connecticut Tsinghua University Cisco Technology, Inc.

Looking Glass Output All commands were executed on "lg-01-ams.nl" on February 10, 2025. shows the output for executing "show ip bgp 203.127.0.0/16". shows the output for executing "show ip bgp 203.127.225.0/24". shows the output for executing "traceroute ip 203.127.225.1".