Defending Against BGP Hijacking: Implementing RPKI And Route Filtering

📅 October 26, 2026  |  🏷 Cyber Security  |  Cyber Security, Information Security, Threat Management

In April 2010, China Telecom briefly hijacked roughly 15% of the global internet’s traffic—redirecting routes for major U.S. government sites, military networks, and Fortune 500 companies through Chinese infrastructure for approximately 18 minutes. No exploited zero-day. No elaborate malware. Just a few manipulated Border Gateway Protocol announcements that the global routing system accepted without question. Fourteen years later, the architectural vulnerability that enabled that incident remains largely intact, and threat actors—ranging from nation-state operators to financially motivated criminals—continue to exploit it with increasing sophistication.

BGP hijacking is not an obscure edge case. It is a persistent, structurally enabled attack class that can redirect, intercept, or black-hole traffic at scale. The defenses exist. RPKI (Resource Public Key Infrastructure) and disciplined route filtering are the two most consequential controls available to network operators today. Deploying them correctly, however, requires understanding both their mechanics and their limitations.

Understanding BGP Hijacking: The Trust Problem at the Internet’s Core

The Border Gateway Protocol was designed in 1989 on a cocktail napkin—a fitting metaphor for its foundational assumption: that every Autonomous System (AS) on the internet is trustworthy and accurately advertises the IP prefixes it legitimately originates. BGP has no native authentication mechanism. When AS64500 announces that it owns 192.0.2.0/24, every neighboring AS that receives that announcement has no cryptographic way to verify the claim. They rely on route policies, filters, and operational trust.

Attack Vectors: How Hijacking Manifests

BGP hijacking takes several distinct forms, each with different detection difficulty and threat actor profiles:

• Prefix hijacking: An AS announces a prefix it does not own, attracting traffic destined for the legitimate holder.
• Sub-prefix hijacking: The attacker announces a more-specific prefix (e.g., /25 vs. /24), leveraging BGP’s preference for longest-prefix matches to override legitimate announcements without completely suppressing them.
• AS-path manipulation: Attackers forge AS-path attributes to make malicious routes appear shorter or more preferred, influencing upstream route selection.
• Route leak amplification: A misconfigured AS re-advertises routes learned from one peer to another, unintentionally acting as a transit provider and causing widespread traffic misdirection.

According to the 2025 MANRS (Mutually Agreed Norms for Routing Security) Routing Security Report, there were over 14,000 documented BGP hijacking and route leak incidents in the preceding 12-month period. The majority were attributable to misconfiguration rather than deliberate attack—which underscores the point that even well-intentioned networks contribute to the problem without proper controls.

Real-World Impact: Beyond Traffic Misdirection

The 2022 Cloudflare incident involving BGP leaks from a peer AS demonstrated how even partial traffic redirection can degrade latency for millions of end users. More critically, the 2018 hijacking of Amazon Route 53 DNS service by attackers who redirected MyEtherWallet traffic through a rogue AS resulted in the theft of approximately $150,000 in cryptocurrency—all by manipulating routing advertisements, not breaking encryption. When traffic transits an attacker-controlled AS, TLS inspection, credential harvesting, and content injection become operationally feasible.

RPKI: Cryptographic Origin Validation for BGP Routes

Resource Public Key Infrastructure is the most structurally significant advancement in BGP security since the protocol’s inception. RPKI creates a cryptographically verifiable mapping between IP address blocks and the Autonomous Systems authorized to originate them, using a hierarchical Certificate Authority structure rooted in the five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC).

Route Origin Authorizations: The Fundamental Building Block

The core instrument of RPKI is the Route Origin Authorization (ROA). A ROA is a digitally signed object that asserts: “AS X is authorized to originate prefix P with a maximum length of L.” ROAs are published in RPKI repositories accessible to all routing participants.

When a router performs Route Origin Validation (ROV), it evaluates incoming BGP announcements against the RPKI repository data and assigns one of three states:

The critical operational decision is how aggressively to handle Invalid routes. NIST Special Publication 800-189 recommends dropping RPKI-Invalid routes, and this is increasingly the industry consensus. As of Q3 2026, approximately 47% of global BGP announcements are covered by ROAs, according to RIPE NCC statistics—a substantial increase from 28% in 2022, but still leaving a significant portion of the routing table unprotected.

Deploying RPKI: Operational Considerations

Implementing RPKI involves two parallel workstreams: creating ROAs for your own prefixes and enforcing ROV on routes received from peers.

For ROA creation, operators log into their RIR’s portal (e.g., ARIN’s Hosted RPKI service or RIPE NCC’s MyAPNIC) and create signed objects for each prefix/ASN pair. Key configuration considerations include:

• Max-length discipline: Setting max-length equal to the announced prefix length prevents sub-prefix hijacking. Operators who announce both /22 and /24 subnets must create separate ROAs or set max-length to /24—understanding that this explicitly authorizes more-specific announcements.
• Multi-origin AS scenarios: BGP anycast deployments (common in CDN and DNS infrastructure) require ROAs for each originating ASN.
• ROA expiration management: ROAs have validity periods. Expired ROAs cause your own prefixes to appear Invalid to enforcing peers—a self-inflicted outage risk that requires operational calendar management.

For ROV enforcement, modern router operating systems (Junos, IOS-XR, NX-OS, FRRouting) support RPKI via RTR (RPKI-to-Router) protocol connections to a local RPKI validator cache such as Routinator, OctoRPKI, or FORT Validator. The validator fetches and cryptographically verifies repository data, then serves a condensed prefix/origin table to routers via RTR sessions. Deploying multiple validators with RTR failover is essential for resilience.

Route Filtering: Defense-in-Depth Beyond RPKI

RPKI addresses origin authentication but does not validate the full AS path or prevent route leaks from misconfigured peers. Route filtering—the disciplined application of prefix-lists, AS-path filters, and routing policy—remains a foundational and complementary control.

IRR-Based Filtering and the MANRS Framework

Internet Routing Registries (IRRs) such as RADB, RIPE DB, and ARIN IRR store routing policy objects including route and aut-num objects that describe what prefixes an AS originates and which ASes it transits. Tools like bgpq4 automate the generation of prefix-lists from IRR data, allowing operators to build peer-specific inbound filters that reject any announcement not registered in the IRR.

The MANRS (Mutually Agreed Norms for Routing Security) initiative, backed by the Internet Society, defines four core actions that network operators should implement:

1. Filtering: Prevent propagation of incorrect routing information by implementing prefix and AS-path filters.
2. Anti-spoofing: Prevent packets with forged source addresses (BCP38/uRPF).
3. Coordination: Maintain globally accessible, up-to-date contact and routing policy information.
4. Global Validation: Facilitate validation of routing information by publishing ROAs.

MANRS participation has grown to over 1,100 network operators as of 2026, representing a significant but still minority fraction of global ASes. Networks that peer with MANRS-compliant participants benefit from measurably lower exposure to route leak events.

Practical Filtering Policies for Enterprise and Service Provider Networks

For network architects designing filtering policies, the following tiered approach provides structured defense:

• Bogon prefix filtering: Reject announcements for IANA-reserved, RFC 1918, and documentation prefixes (240.0.0.0/4, 10.0.0.0/8, etc.). These should never appear in eBGP sessions. Maintain updated bogon lists using resources from Team Cymru or the IANA Special-Purpose Address Registry.
• Maximum prefix limits: Configure hard limits on the number of prefixes accepted per BGP session. Exceeding thresholds triggers session shutdown or alert, protecting against route table flooding attacks.
• AS-path length filtering: Reject routes with excessively long AS-paths (e.g., >20 hops), which are statistically anomalous and often indicative of manipulation or misconfiguration.
• Prefix length filtering: Reject IPv4 prefixes more specific than /24 and IPv6 prefixes more specific than /48 from eBGP peers. This is a widely accepted operational norm that limits the effectiveness of sub-prefix hijacking.
• Peer-specific IRR-generated prefix lists: Build inbound filters for each peer using bgpq4 against current IRR data, and refresh these filters on a scheduled basis (weekly at minimum).

BGP Security Monitoring and Incident Response

Even with RPKI and route filtering deployed, real-time visibility into BGP announcements affecting your prefixes is indispensable. Detection capabilities transform your posture from reactive to proactive.

Monitoring Tools and Alerting Pipelines

Several purpose-built platforms provide BGP route monitoring:

• Cloudflare Radar and BGPStream: Public real-time BGP data aggregation from multiple route collectors (Route Views, RIPE RIS). BGPStream provides programmatic API access for custom alerting pipelines.
• RIPE NCC RIPEstat: Provides per-prefix routing history, visibility into RPKI validation state, and peer visibility analytics.
• Commercial platforms (ThousandEyes, Kentik): Offer integrated BGP path monitoring with alerting on unexpected origin AS changes, new route advertisements, or prefix withdrawals correlated with performance degradation.

A practical alerting policy should trigger immediate investigation when: (1) your prefixes are announced by an unexpected origin AS, (2) more-specific prefixes for your address space appear in the global routing table, or (3) your prefixes are withdrawn from a significant portion of the route collector vantage points (indicating a black-hole condition).

Incident Response for Active BGP Hijacking

When a BGP hijacking event is confirmed, the response sequence typically involves:

1. Verification: Confirm via multiple route collectors that the hijack is real, not a monitoring artifact. Identify the originating AS and upstream transit providers enabling the rogue announcement.
2. Upstream notification: Contact your own upstream transit providers to request prefix filtering against the rogue AS. Most Tier-1 and Tier-2 providers maintain NOC contacts and abuse procedures for exactly this scenario.
3. Network Operations Center escalation: Engage the RIR’s abuse contacts to initiate ROA validation review. If you have ROAs in place and the hijacking AS lacks one, enforcing peers will reject the announcement—demonstrating RPKI’s value in real-time.
4. Law enforcement engagement: For confirmed malicious hijacking (as opposed to misconfiguration), coordinate with CISA (in the U.S.) or relevant national CERTs for attribution and legal response.
5. Post-incident analysis: Document the event timeline, affected prefixes, estimated traffic volume, and any evidence of traffic interception. Update filtering policies to close any gaps revealed by the incident.

RPKI Limitations and the Road Ahead

Intellectual honesty demands acknowledging what RPKI does not solve. ROV validates the origin AS of a route announcement, but it provides no protection against AS-path manipulation once a route enters the BGP system legitimately. A threat actor who compromises a transit AS can still influence path selection through AS-path prepending or attribute manipulation without violating any ROA.

BGPsec, ASPA, and Emerging Standards

The IETF’s Secure Inter-Domain Routing (SIDR) working group has produced several standards addressing the path validation gap:

• BGPsec (RFC 8205): Extends BGP to include cryptographic signatures over AS-path segments, providing end-to-end path authentication. Deployment has been minimal due to performance overhead (cryptographic operations per-announcement), configuration complexity, and the requirement for universal adoption to provide meaningful protection—a classic network-effects bootstrapping problem.
• ASPA (Autonomous System Provider Authorization, RFC 9582): A lighter-weight approach that creates signed objects authorizing which upstream providers an AS uses. This enables detection of route leaks and valley-free routing violations without the full complexity of BGPsec. ASPA is gaining traction as a practical next step beyond ROV.
• Route Origin Validation with path constraints: Research into hybrid approaches that combine RPKI ROV with heuristic AS-path analysis is ongoing, with several IXP operators piloting combined detection frameworks.

The realistic near-term roadmap for most enterprise and service provider networks is: complete ROA creation and ROV enforcement today, implement IRR-based filtering with regular refresh cycles, deploy BGP monitoring with automated alerting, and track ASPA standardization for future deployment. BGPsec remains a long-term aspiration rather than an actionable near-term control for most operators.

Key Takeaways

• BGP’s trust model is structurally broken: The protocol was not designed for adversarial environments. Without controls like RPKI and route filtering, any AS can announce any prefix and attract global traffic—as events from 2010 through 2026 have repeatedly demonstrated.
• RPKI ROA creation and ROV enforcement are non-negotiable baselines: Creating ROAs for your prefixes costs nothing and protects you from origin hijacking by enforcing peers. Enabling ROV on your routers protects your network from accepting hijacked routes. Both steps
  

  ---

  💡 Enjoyed this article?

  Subscribe for more expert insights delivered to your inbox.

  Follow us or subscribe below xe2x80x94 free, no spam.