Resource Public Key Infrastructure (RPKI) has become a cornerstone of internet routing security. By cryptographically binding Internet Protocol (IP) prefixes to authorized origin Autonomous Systems (ASes), RPKI lets networks detect and filter illegitimate Border Gateway Protocol (BGP) announcements and significantly reduce the risk of route hijacking. Adoption of RPKI has accelerated rapidly: Today, more than 60 percent of IPv4 prefixes are covered by Route Origin Authorizations (ROAs), according to the National Institute of Standards and Technology (NIST) RPKI monitor.

However, an uncomfortable reality remains.

Thousands of RPKI-invalid prefixes continue to appear in global routing tables every day, and that number has barely declined over time. For years, network researchers and practitioners have worked to understand why these invalid prefixes persist and what impact they have on real-world network operations.

Last week at the Network and Distributed System Security (NDSS) Symposium, a new paper was presented that explains why RPKI-invalid routes persist, what operational practices cause them and how they affect the internet’s data plane.

The paper, “Demystifying RPKI-Invalid Prefixes: Hidden Causes and Security Risks,” which I co-authored with Dr. Weitong Li and Dr. Taejoong Chung from Virginia Tech, builds on work conducted by Dr. Li at CableLabs in 2024 and is the most comprehensive study to date on this topic. The work was done in collaboration with some CableLabs members as well, including Charter, Comcast, Cox, GCI and Midco.

Below, I’ll summarize the key findings of the paper and explain what network operators and BGP practitioners may need to know about RPKI-invalid prefixes.

What Are RPKI-Invalid Prefixes?

An RPKI-invalid prefix is a BGP-announced IP prefix that fails Route Origin Validation (ROV). Under ROV, each BGP route is classified as valid, invalid or unknown. A route is considered invalid when its prefix is covered by at least one ROA, but the announcement doesn’t match any authorized ROA, either because the origin AS isn’t permitted to announce the prefix or because the announced prefix length exceeds the ROA’s maxLength constraint.

How Common Are RPKI-Invalid Prefixes?

Despite the rapid rollout of RPKI across the internet, RPKI-invalid prefixes are surprisingly common. Analyzing global BGP data from January 2023 through July 2024, the authors found that more than half of all announced prefixes were protected by ROAs, yet more than 6,000 prefixes were still flagged as RPKI-invalid on any given day.

Over this roughly 18-month period, 42,654 unique RPKI-invalid prefixes appeared in the global routing system, underscoring that invalid routing announcements continue to persist alongside widespread RPKI adoption.

What Are the Root Causes of RPKI-Invalid Prefixes?

In addition to well-known and easily detectable misconfigurations, such as incorrect or overly restrictive maxLength settings, the paper identifies two major, less visible root causes of RPKI invalidity: IP leasing and opaque IP transit services.

• IP leasing without ROA updates. As IPv4 scarcity intensifies, IP leasing becomes increasingly common. In most leasing arrangements, address ownership doesn’t change: The lessor retains control of the IP prefixes and the associated ROAs, whereas the lessee announces the leased prefixes in BGP. Problems arise when ROAs aren’t updated to authorize the lessee’s ASN. This situation is particularly common when IP brokers are involved, because ROA updates often rely on manual, cross-organizational coordination. As a result, legitimate announcements by lessees are frequently flagged as RPKI-invalid, even though no hijack has occurred.
• Opaque IP transit services. Modern transit services increasingly obscure the true origin of a prefix, such as for Distributed Denial of Service (DDoS) scrubbing or traffic tunneling. In these opaque IP transit services, the ROA is not updated to reflect the route announcements in BGP. For example, a provider may announce a customer’s prefix under the provider’s own ASN while forwarding traffic back to the customer internally. From a BGP perspective, the customer ASN doesn’t appear in the AS_PATH. If the ROA still authorizes the customer ASN rather than the provider’s ASN, the announcement becomes RPKI-invalid.

What Are the Impacts of RPKI-Invalid Prefixes?

To measure the real-world impact of RPKI-invalid prefixes, the authors first identified live hosts within these prefixes using Internet Control Message Protocol (ICMP) scans. We then launched ping and traceroute measurements from more than 5,000 RIPE Atlas probes across more than 1,600 ASes worldwide, spanning both ROV-enforcing and non-ROV networks.

These measurements revealed two primary data-plane consequences: connectivity loss and unintended path divergence.

• Connectivity loss. Measurements showed that 3.1 percent of RPKI-invalid prefixes experienced connectivity loss from at least one network vantage point. These outages were most common for leased prefixes. Even when alternative routes existed to the lessor, connectivity wasn’t always preserved, because the lessor might not have forwarded traffic to the lessee. This observation challenged the assumption that invalid routes are harmless as long as a fallback path is available.
• Unintended path divergence. Even when connectivity is preserved, ROV filtering can silently reroute traffic away from its intended path. Measurements showed that 18.5 percent of RPKI-invalid prefixes experienced unintended routing changes. These reroutes frequently bypassed upstream networks that were meant to provide security services such as DDoS mitigation or traffic inspection. The performance impact was significant: Nearly all affected prefixes experienced increased latency, and 39.2 percent incurred latency increases exceeding 100 milliseconds. Many also traversed substantially more AS hops, increasing exposure to congestion and attack surfaces.

RPKI is also widely used as a foundation for BGP hijack detection. Evaluating two prominent systems the authors found that more than 80 percent of RPKI-invalid prefixes flagged as hijacks were actually benign misconfigurations. The resulting false positives contributed to alert fatigue, making it harder for security teams to identify genuine incidents.

Toward Stronger Operational Practices

The paper’s findings show that RPKI-invalid prefixes are likely to persist even as RPKI adoption continues to expand, reflecting the growing complexity of modern internet operations rather than a failure of RPKI itself.

As discussed in the paper, addressing these challenges requires moving beyond cryptography toward stronger operational practices:

• Transit providers can reduce risk through automated ROA–BGP consistency checks.
• Leasing brokers can improve reliability with better ROA monitoring and faster update workflows.
• Regional Internet Registries (RIRs) can help by supporting more flexible delegation models that align with today’s address usage.

At CableLabs, we’re committed to working with our members and the broader community to strengthen internet routing security. By improving coordination, tooling and operational awareness among BGP and RPKI community stakeholders, the ecosystem can significantly reduce the impact of RPKI-invalid prefixes.

For more details, I invite readers to explore the full paper or reach out to the authors to continue the conversation.

You can also find additional CableLabs resources related to RPKI here:

• Cybersecurity Framework Profile for Internet Routing
• Resource Public Key Infrastructure (RPKI) Deployment Best Common Practice