BGP hijacking happens when an Autonomous System announces IP address space it is not authorized to originate. Because BGP is built on trust between networks, the false route may be accepted and propagated, causing traffic to be misdirected, intercepted, delayed or dropped.
RPKI reduces this risk by allowing address holders to publish Route Origin Authorizations that prove which AS is allowed to originate a prefix. When networks validate routes and reject invalid announcements, many accidental route leaks and malicious origin hijacks can be stopped before they spread.
Executive Summary
BGP is the routing protocol that connects the Internet’s autonomous systems. It tells networks which prefixes are reachable and which AS Path traffic should follow. The problem is that BGP was built on operational trust, not strong origin authentication.
BGP hijacking occurs when a network incorrectly or maliciously announces address space it does not own. Prefix hijacking, sub-prefix hijacking and route leaks can redirect traffic, cause outages, degrade cloud and SaaS connectivity or expose traffic to interception.
RPKI helps strengthen routing security by allowing address holders to publish signed Route Origin Authorizations. Routers and validators can then classify routes as Valid, Invalid or Not Found. A route marked Invalid should be rejected or heavily de-preferenced according to policy.
RPKI does not solve every BGP security problem. It validates route origin, not the full AS Path. Network teams still need prefix filtering, maximum-prefix limits, IRR hygiene, monitoring, upstream coordination and incident response procedures.
Why Internet Routing Security Matters
Every packet that leaves your network depends on routing to reach its destination. Internet routing is the system that makes that decision, and it works so quietly that most teams only notice it when something breaks.
The global Internet is not a single network. It is made up of tens of thousands of independent networks, called autonomous systems, that agree to carry each other’s traffic. The Border Gateway Protocol (BGP) is the language these networks use to announce which destinations they can reach. When an AS announces a block of addresses, its neighbors generally trust the announcement, propagate it, and update their own routing tables accordingly.
That trust is both the strength of BGP and its weakness. Because a router generally accepts what a neighbor advertises, a single incorrect announcement can ripple outward within seconds. A misconfiguration in one data center can pull traffic for thousands of unrelated networks toward the wrong destination, or nowhere at all. Understanding how BGP hijacking happens, and how RPKI reduces that risk, is now essential knowledge for any team operating public infrastructure.
What Is BGP?
The Border Gateway Protocol (BGP) is the routing protocol that connects the Internet’s autonomous systems. Its job is to exchange reachability information: which network can reach which destinations, and along what path.
An Autonomous System (AS) is a network under a single administrative control, identified by a unique number such as AS64500. Large ISPs, cloud providers, universities and enterprises each operate one or more autonomous systems.
BGP runs in two modes. eBGP (external BGP) speaks between different autonomous systems and is how the Internet actually interconnects. iBGP (internal BGP) carries the same information inside a single AS so that all of its routers share a consistent view of the network.
Routers exchange route advertisements. Each advertisement contains a prefix, a block of addresses such as 203.0.113.0/24, and an AS Path, the ordered list of autonomous systems the route has traversed. When choosing between competing routes, two rules dominate in practice: the most specific prefix always wins, and among equally specific routes, the shorter AS Path is usually preferred. These two rules explain almost every hijack described in this article.
Diagram 1. Normal BGP route advertisement. The legitimate owner announces its prefix, neighboring networks propagate it, and traffic converges on the rightful AS.
What Is BGP Hijacking?
BGP hijacking is the advertisement of address space by an AS that does not legitimately own it. Because neighboring networks generally trust what they hear, the false route can be accepted and propagated, silently pulling traffic away from its rightful destination.
Hijacks generally fall into two categories of intent. Accidental route leaks happen when a network unintentionally re-announces routes it should have kept to itself, for example when a customer learns routes from one provider and passes them to another, briefly becoming an unintended transit path for traffic it cannot handle. Malicious hijacking is deliberate: an operator announces someone else’s prefix in order to intercept, inspect or black-hole traffic.
Prefix Hijacking, Sub-Prefix Hijacking and Route Leaks
In prefix hijacking, the attacker announces the exact same prefix as the legitimate owner. Networks that are topologically closer to the attacker may prefer its shorter AS Path and send traffic to the wrong origin.
Sub-prefix hijacking is more effective and more damaging. The attacker announces a more specific block than the legitimate owner. If the owner advertises 203.0.113.0/23 and the attacker advertises 203.0.113.0/24, every router prefers the /24, because the most specific prefix always wins. This can drain an entire address block toward the attacker.
A route leak is different again. It occurs when a network re-advertises routes to another network where those routes should never have been propagated, most often because of missing filters or an undocumented routing policy. Route leaks are usually accidental, but they can still cause the same outages and traffic misdirection as a deliberate hijack.
Diagram 2. Prefix hijacking. Two autonomous systems claim the same block; downstream networks split, and part of the Internet routes to the wrong origin.
Diagram 3. Sub-prefix hijacking. A more specific announcement wins globally because longest-prefix match takes priority over path length.
Prefix Hijack vs Sub-Prefix Hijack vs Route Leak
| Type | What Happens | Why It Works |
|---|---|---|
| Prefix hijack | A false AS announces the same prefix as the legitimate owner | Some networks may prefer the shorter or more attractive AS Path |
| Sub-prefix hijack | A false AS announces a more specific prefix than the legitimate owner | Longest-prefix match wins over less-specific routes |
| Route leak | A network re-advertises routes where it should not | Missing filtering or poor routing policy causes unwanted propagation |
| Mis-origination | A prefix is announced by the wrong AS by mistake | BGP accepts the announcement unless validation or filtering stops it |
Common Causes of BGP Hijacking
Most routing incidents are not sophisticated attacks. They are ordinary operational failures amplified by BGP’s willingness to trust. The most common causes include:
- Human configuration mistakes: a typo in a prefix list, an incorrect AS number, or a filter applied to the wrong session.
- Incorrect prefix advertisements: announcing a block that belongs to another organization, often left over from a lab environment or a migration.
- Missing route filtering: sessions with no inbound or outbound filters that accept whatever a neighbor sends.
- Lack of prefix validation: no mechanism in place to check whether an origin is actually authorized for a prefix.
- ISP routing errors and third-party peering mistakes: an upstream provider or peer that leaks or mis-originates routes on your behalf.
- Poor routing policy: policy that is vague, undocumented or inconsistent across routers.
Business Impact of BGP Hijacking
When a prefix is hijacked or leaked, the effects are rarely subtle. Traffic to affected services may be black-holed, producing Internet outages and website downtime. Because so much business activity now depends on the public Internet, the impact spreads quickly: cloud connectivity degrades, VPN tunnels drop as endpoints become unreachable, and SaaS applications stall mid-session.
Even a partial hijack increases latency as traffic detours through the wrong network. If the hijacker forwards traffic on rather than dropping it, users may notice nothing while their sessions are quietly subject to interception. The commercial impact follows close behind: lost revenue, contractual penalties, and lasting damage to customer trust once an incident becomes public.
Real-World BGP Hijacking Examples
These public incidents shaped how the industry thinks about routing security.
Pakistan Telecom and YouTube (2008)
Ordered to block YouTube domestically, Pakistan Telecom announced a more specific route for a YouTube prefix. The announcement leaked to an upstream provider and propagated globally, taking YouTube largely offline worldwide for roughly two hours. Lesson: a local action combined with missing filters can cause a global outage, and more specific routes travel far.
Route Leaks Affecting Google
On multiple occasions, Google bound traffic has been misdirected when a network leaked routes it should have contained, briefly steering large volumes of traffic through networks that were never meant to carry it. Lesson: even non-malicious leaks by a distant network can disrupt a major destination.
Cloudflare and Other Routing Incidents
Cloudflare and many other providers have documented incidents in which a third-party mis-originated their prefixes, causing regional reachability failures. Reporting has repeatedly shown that networks with valid ROAs and neighbors that reject invalid routes were shielded, while others were not. Lesson: validation only helps when the origin publishes ROAs and downstream networks actually enforce them.
What Is RPKI?
Resource Public Key Infrastructure (RPKI) lets address holders cryptographically prove which AS is authorized to originate their prefixes. It attaches verifiable ownership to routing, so a router can ask one simple question: is this origin allowed to announce this prefix?
The core object is the Route Origin Authorization (ROA), a signed statement that AS X may originate prefix P, up to a defined maximum length. A ROA is issued under a digital certificate tied to the Regional Internet Registry (RIR) that allocated the address space, anchoring the trust chain: RIR to resource certificate to ROA. A validator checks these objects and builds a table of authorized prefix and origin pairs that routers consult during best path selection.
Route Origin Authorization and Validation States
After checking a received route against RPKI data, a router assigns one of three validation states, then applies local policy to decide what to do with the route.
| State | Meaning | Typical Router Treatment |
|---|---|---|
| Valid | A ROA exists and the origin AS and prefix length match it. | Accept, often with a preference boost. |
| Invalid | A ROA exists but the origin or prefix length does not match. | Reject (recommended) or heavily de-preference. |
| Not Found | No ROA covers this prefix at all. | Accept, treated neutrally during migration. |
The key policy decision is reject-invalids. A route marked Invalid has failed an explicit ownership check and should be dropped. Not Found simply means the owner has not published a ROA yet, so the route is typically accepted to avoid breaking the large portion of the Internet that remains unsigned.
How RPKI Helps Prevent BGP Hijacking
RPKI does not encrypt traffic and does not secure the full AS Path. It validates the origin. Origin errors cause the overwhelming majority of routing incidents, so the effect of validation is significant. When a hijacker announces a prefix from an unauthorized AS, a validating router sees a ROA that does not match, marks the route Invalid, and drops it. The false announcement never enters the routing table and cannot propagate further.
This closes the door on both malicious mis-origination and the accidental variety, since a mistaken origin looks identical to an attacker’s from the protocol’s point of view. Every network that publishes accurate ROAs and rejects invalid routes raises the baseline trust of the routing system and improves overall Internet stability. The benefit compounds as adoption grows.
Diagram 4. Internet routing with ROA validation. Valid origins pass; invalid origins are rejected at the router.
BGP and RPKI Best Practices for Network Teams
Routing security is a set of habits, not a single switch. The practices below form a practical baseline for any team that originates public prefixes.
| Action | Why It Matters |
|---|---|
| Create ROAs for all public prefixes | Lets other networks validate and reject impostors of your address space. |
| Enable RPKI validation and reject invalids | Stops unauthorized origins from entering your routing table. |
| Apply prefix filtering on every eBGP session | Blocks unexpected prefixes regardless of RPKI status. |
| Configure maximum-prefix limits | Caps the damage from a leak by tearing down runaway sessions. |
| Use explicit, documented route policies | Keeps behavior consistent across all routers. |
| Monitor BGP announcements | Detects unexpected origins and sub-prefixes early. |
| Maintain IRR records and audit policies | Keeps registry data aligned with reality for peer filtering. |
| Monitor upstream providers and document procedures | Ensures a fast, repeatable response when something goes wrong. |
Monitoring and Troubleshooting BGP Hijacks
You cannot protect what you cannot see. Effective routing operations continuously watch several signals: BGP session health such as flaps and resets, the validation status of received routes, the prefixes you advertise, and any AS Path changes or unexpected updates involving your address space. A sudden new origin AS or a more specific announcement of your own prefix is the classic hijack signature.
Pair internal telemetry, logging of BGP events and alerting on threshold breaches, with external Internet routing monitoring tools that watch your prefixes from many global vantage points. Internal logs show what your own routers did. External monitors show what the rest of the world sees, which is often where a hijack is first noticed.
Diagram 5. Route leak between ISPs. A multi-homed customer leaks provider A’s routes to provider B, hijacking transit for traffic it cannot sustain.
BGP Hijack Incident Response Workflow
When monitoring flags a possible hijack, speed and sequence matter. A workable response playbook includes:
- Verify your own advertisements: confirm what you are actually announcing and rule out a self-inflicted error.
- Contact your upstream ISP: they can often filter or block the offending announcement upstream faster than anyone else.
- Withdraw incorrect prefixes: if the fault is yours, then re-announce cleanly.
- Update or correct ROAs: so validating networks begin rejecting the false route automatically.
- Validate route propagation: from external vantage points to confirm the fix is taking effect globally.
- Review logs and perform root cause analysis: and document corrective actions so the same failure does not recur.
Diagram 6. Monitoring and incident response flow. Detection through documentation, closing the loop back into policy.
Common BGP and RPKI Misconceptions
“RPKI eliminates all routing attacks.” It does not. RPKI validates the origin of a route, not the full AS Path. A determined attacker can still forge a plausible path with a valid looking origin. RPKI removes a large, common class of problems, but it is not a complete shield.
“Only ISPs need RPKI.” Any organization that originates public address space benefits from publishing ROAs, because ROAs are what let other networks reject impostors of that address space.
“Internal enterprise networks never need routing security.” Any network that speaks BGP to the outside world, including multi-homed enterprises and cloud tenants, is exposed to leaks and hijacks and should validate and filter accordingly.
“BGP filtering alone is enough.” Filters are essential but depend on accurate, maintained data and can still be bypassed by more specific announcements. Filtering and RPKI are complementary layers, not substitutes for one another.
BGP vs RPKI Quick Reference
| Aspect | BGP | RPKI |
|---|---|---|
| Role | Exchanges routes between autonomous systems | Validates who may originate a prefix |
| Trust model | Implicit, believes neighbors | Cryptographic, signed ROAs |
| Protects | Reachability | Route origin |
| Stops on its own | Nothing by default | Unauthorized origins (invalids) |
| Relationship | RPKI adds an authorization layer on top of BGP | It does not replace BGP |
Common Hijacking Types
| Type | What Happens | Why It Works |
|---|---|---|
| Prefix hijack | Same prefix announced by a false origin | Nearer networks prefer the shorter path |
| Sub-prefix hijack | More specific prefix announced | Longest-prefix match wins everywhere |
| Route leak | Routes re-advertised where they should not be | Missing outbound filtering or policy |
| Accidental mis-origination | Wrong prefix announced by mistake | Configuration error plus no validation |
BGP Hijacking and RPKI Checklist
Network teams responsible for public routing should validate the following controls:
- Create ROAs for all public prefixes that your organization originates.
- Ensure ROAs use the correct origin AS and maximum prefix length.
- Enable RPKI route origin validation where supported.
- Reject or strongly de-preference invalid routes according to routing policy.
- Apply prefix filtering on every eBGP session.
- Configure maximum-prefix limits to reduce route leak impact.
- Maintain accurate IRR records and routing registry data.
- Use explicit, documented routing policies across routers and peers.
- Monitor for unexpected origin AS changes.
- Monitor for unexpected more-specific announcements of your prefixes.
- Track BGP session flaps, resets, route changes and AS Path anomalies.
- Monitor upstream providers and confirm their RPKI validation posture where possible.
- Maintain an incident response workflow for route hijack or leak events.
- Document escalation contacts for upstream providers and peering partners.
- Review BGP and RPKI configuration after major network or provider changes.
How ServQual and SUSAN Help
ServQual helps organizations strengthen network security through routing review, firewall and network architecture assessment, incident response, managed security, cloud security and GRC readiness.
BGP security should not be treated as a one-time configuration task. Prefix ownership, ROAs, route filters, upstream providers, peering relationships and monitoring procedures can drift as networks change.
SUSAN can help teams connect routing security findings, remediation ownership, control evidence and audit readiness into a structured governance view. This helps network, security, infrastructure, SOC and GRC teams track whether BGP and routing security risks are identified, assigned, remediated and evidenced.
With ServQual and SUSAN, organizations can:
- Review routing security posture and BGP exposure
- Track RPKI, ROA and prefix validation readiness
- Identify gaps in route filtering and prefix controls
- Track remediation ownership for routing security findings
- Support audit-ready evidence for network security reviews
- Connect routing security issues with GRC and compliance workflows
- Improve leadership visibility into internet routing risk
- Move from ad hoc routing review to continuous assurance
Explore Cybersecurity Services: srql.com/services/cyber-security-solutions
Explore Incident Response & Managed Security: srql.com/services/incident-response-managed-security
Explore Governance, Risk, Compliance & Audits: srql.com/services/governance-risk-compliance-audits
Explore SUSAN: srql.com/services/susan
"BGP trusts what networks announce. RPKI helps prove who is allowed to announce it."
Rohan Kanthe
Sr. IT Engineer | ServQual
FAQ
Most frequent questions and answers
BGP hijacking occurs when an Autonomous System announces IP address space it is not authorized to originate, causing traffic to be redirected, delayed, intercepted or dropped.
A route leak occurs when a network re-advertises routes to another network where those routes should not be propagated. Route leaks are often caused by poor filtering or routing policy mistakes.
Sub-prefix hijacking happens when an attacker announces a more specific prefix than the legitimate owner. Because routers prefer the most specific route, traffic may be redirected to the attacker.
RPKI, or Resource Public Key Infrastructure, is a system that allows IP address holders to cryptographically authorize which Autonomous System may originate their prefixes.
A Route Origin Authorization is a signed statement that says a specific AS is authorized to originate a specific prefix, up to a defined maximum length.
Invalid means a ROA exists for the prefix, but the route announcement does not match the authorized origin AS or prefix length. Many networks reject invalid routes.
No. RPKI validates route origin, not the full AS Path. It reduces many origin hijacks and route leaks but should be combined with filtering, monitoring and incident response.
Enterprises that originate public prefixes should publish ROAs and consider route origin validation where supported. Multi-homed enterprises and cloud-connected networks can also benefit from RPKI-aware routing practices.
SUSAN can help teams connect routing security findings, remediation ownership, control evidence and audit readiness into a structured GRC and continuous assurance workflow.
Strengthen Internet Routing Security with BGP and RPKI Review
BGP hijacking and route leaks can redirect traffic, degrade services, disrupt cloud connectivity and expose organizations to serious availability and trust risks. RPKI, ROA validation, prefix filtering, maximum-prefix limits and monitoring help reduce routing exposure.
ServQual can help review your BGP and RPKI posture, validate ROA coverage, assess routing filters, improve monitoring and build incident response procedures for route hijack or leak events. Explore ServQual Cybersecurity Services or contact ServQual to connect routing security findings, remediation ownership, control evidence and audit readiness into one Continuous Assurance view.
Disclaimer: This article is provided for general informational and educational purposes only. It does not constitute professional, technical, legal or security advice and should not be relied upon as a substitute for a qualified assessment of your organization’s specific network, infrastructure or regulatory environment. Routing protocols, RPKI tooling, vendor implementations and industry best practices continue to evolve, and some details described here may change over time. ServQual makes no warranty as to the completeness or current accuracy of this content and accepts no liability for actions taken based on it. Organizations should consult qualified network security professionals before implementing changes to production routing infrastructure.
