Diagnosing BGP Hijacking and Route Leaks: Detection Guide
A security engineering guide to identifying unauthorized BGP route announcements, differentiating intentional prefix hijacking from accidental route leaks, and deploying defenses.
Quick Answer
BGP hijacking occurs when a rogue Autonomous System unauthorizedly announces an IP prefix belonging to another organization, diverting or blackholing Internet traffic. In sub-prefix hijacks, the attacker exploits the fundamental Longest Prefix Match rule to steal 100% of traffic. Detection relies on real-time BGP monitoring (BGPStream, RIPEstat) and cryptographic RPKI validation.
- Longest Prefix Match Rule: A more specific announcement (/24) always defeats a broader (/22) legitimate route.
- RFC 7908 Route Leaks: Accidental misconfigurations re-advertising peer routes as transit paths.
- Cryptographic Defense: RPKI Route Origin Validation (ROV) automatically discards unauthorized BGP origins.
1. The Mechanisms of BGP Route Anomalies
Because BGP was engineered without built-in cryptographic origin verification, routers accept route advertisements at face value unless strict filters are applied:
2. Comparison of BGP Anomaly Types
Compare the operational vectors, traffic impacts, and detection indicators across BGP incidents:
| Anomaly Type | Attacker Action | Traffic Impact | Detection Signal | Primary Mitigation |
|---|---|---|---|---|
| Sub-Prefix Hijack | Announces more-specific prefix (e.g. /24) | 100% traffic diversion to rogue network | New prefix appears in global DFZ table | De-aggregate to matching prefix; RPKI MaxLength |
| Exact-Prefix Hijack | Announces identical prefix (e.g. /22) | Partial traffic diversion (geographic split) | Conflicting Origin ASN detected for same prefix | Upstream Tier-1 filter enforcement; RPKI ROV |
| BGP Route Leak (RFC 7908) | Leaked peer routes advertised to transit | Severe congestion, latency spikes, dropped packets | Impossible AS-Path sequences in BGP tables | BGP Open Policy (RFC 9234); Peerlock filters |
| BGP Man-in-the-Middle | Intercepts, inspects, and re-routes packets | Subtle latency increase; traffic not dropped | Traceroute hops reveal unexpected transit ASNs | mTLS / End-to-end encryption; RPKI enforcement |
BGP Hijack & Route Leak Incident Triage Decision Tree
[ Suspicious Traffic Drop or Anomaly Detected ]
|
+----------------------------+----------------------------+
| |
[ Outbound Blackhole ] [ Traffic Interception ]
Traffic vanishes globally Intercepted via malicious proxy
Prefix announced by rogue ASN More-specific prefix announced
| |
[ Exact-Prefix Hijack ] [ Sub-Prefix Hijack ]
Both announce same prefix length Attacker announces /24 against /22
50/50 split based on proximity Longest prefix match wins 100%
| |
+----------------------------+----------------------------+
|
[ Incident Remediation ]
1. Announce emergency /24 more-specifics
2. Verify RPKI ROA state (RFC 6480)
3. Contact Tier-1 NOCs to filter rogue ASN
3. Real-Time Detection Platforms
Security teams monitor prefix integrity using automated telemetry collectors:
- Cisco / CAIDA BGPStream: An open-source framework for live BGP measurement analysis and historical event extraction.
- Cloudflare Radar BGP Alerts: Real-time alerts notifying network owners when prefix origin anomalies or route leaks are observed by Cloudflare's global edge.
- RIPE NCC BGP Routing Information Service (RIS): Globally distributed route collectors peering with hundreds of networks to record live routing tables.
4. Practical Diagnostics: Checking BGP Origin Status via API
Detect unauthorized origin ASNs announcing your IP prefix:
Frequently Asked Questions
Why is a Sub-Prefix BGP Hijack more dangerous than an Exact-Prefix Hijack?
Under the fundamental Longest Prefix Match rule of IP routing, a more specific route always takes precedence over a less specific route regardless of AS-Path length or Local Preference. If a legitimate owner announces a /22 subnet and an attacker announces a /24 sub-prefix, 100% of global Internet traffic destined for that /24 will divert directly to the attacker.
What is the technical difference between a BGP Hijack and a BGP Route Leak?
A BGP Hijack is the unauthorized origination of an IP prefix (claiming ownership of someone else's address space). A BGP Route Leak (RFC 7908) is the propagation of legitimate routing announcements beyond their intended scope—such as an ISP accidentally re-advertising routes learned from Provider A to Provider B, causing massive accidental transit congestion across un-sized circuits.
How does RPKI prevent BGP route hijacking?
Resource Public Key Infrastructure (RPKI, RFC 6480) uses digital signatures to create Route Origin Authorizations (ROAs). A ROA cryptographically binds an IP prefix to an authorized origin ASN. When border routers enforce Route Origin Validation (ROV), any unauthorized BGP announcement is marked "RPKI Invalid" and immediately discarded by Tier-1 backbones.
What is the immediate emergency response if my network is being hijacked?
First, announce more-specific prefixes (e.g. split a /23 into two /24s) to recapture traffic via longest-prefix match. Second, immediately contact your upstream transit carriers' NOCs to apply manual BGP filter blocks against the rogue ASN. Third, sign valid RPKI ROAs through your RIR portal.
Data & Technical Sources
- IETF RFC 7908 — Problem Definition and Classification of BGP Route Leaks
- IETF RFC 6480 — An Infrastructure to Support Secure Internet Routing (RPKI Architecture)
- IETF RFC 7454 — BGP Operations and Security (Prefix Filtering and Hijack Prevention)