BGP, the Border Gateway Protocol, is the routing protocol that holds the internet together. Every autonomous system (AS) — every major ISP, cloud provider, content network, and enterprise with an internet presence — uses BGP to advertise which IP prefixes it can reach and to learn routes to reach prefixes advertised by other autonomous systems. BGP was designed in 1989 for a trusted community of network operators where mutual trust was a reasonable assumption. The modern internet is not that environment.
BGP route hijacking — the deliberate or accidental advertisement of IP prefixes that belong to another organization — has caused some of the most significant internet disruptions in history and continues to occur with regularity. Understanding how hijacking works, what Resource Public Key Infrastructure (RPKI) does to prevent it, and what enterprise network engineers should do about it is essential knowledge for anyone responsible for internet-facing network infrastructure.
How BGP Works: The Foundation
BGP operates between autonomous systems — collections of IP networks under common administrative control, identified by a unique Autonomous System Number (ASN). An AS uses eBGP (external BGP) to exchange routing information with neighboring ASes and iBGP (internal BGP) to distribute those routes internally.
When an AS wants to advertise reachability to its IP prefixes, it sends BGP UPDATE messages to its peers containing the prefix, the AS path (the sequence of ASNs the route traverses), and various path attributes. Receiving routers evaluate these advertisements against their routing policy and, if accepted, add the route to their BGP RIB (Routing Information Base) and propagate it to their own peers.
The critical weakness: BGP has no built-in mechanism to verify that the AS advertising a prefix actually has the authority to originate that prefix. Any AS can send a BGP UPDATE claiming to be the originator for any IP prefix. Neighboring routers will evaluate this advertisement based solely on BGP path attributes and local routing policy — not based on whether the advertisement is legitimate.
High-Profile BGP Hijacking Incidents
Pakistan Telecom vs. YouTube (2008)
In February 2008, Pakistan Telecom (PTCL, AS17557) advertised a more-specific prefix for YouTube's IP ranges (208.65.153.0/24) in an attempt to comply with a government order to block YouTube domestically. Due to a misconfiguration, this advertisement propagated globally via PCCW (a transit provider) and was accepted by routers worldwide. YouTube became unreachable globally for approximately two hours until PCCW manually nulled the route.
Rostelecom Hijacking (2020)
In April 2020, Russian state-owned carrier Rostelecom (AS12389) originating approximately 8,800 prefixes belonging to major US providers — including Akamai, Cloudflare, and Amazon — for a period of about an hour. BGPmon monitoring confirmed the hijack. Traffic destined for these providers was briefly routed through Russian infrastructure before the hijack was corrected.
AWS Route 53 BGP Hijack (2018)
Attackers hijacked BGP routes for Amazon Route 53 DNS service, redirecting DNS queries for MyEtherWallet (a cryptocurrency wallet service) to a malicious server. Users connecting to what appeared to be legitimate MyEtherWallet were served a phishing site that stole cryptocurrency credentials. This attack demonstrated that BGP hijacking can enable direct financial losses, not just service disruption.
RPKI: Resource Public Key Infrastructure
RPKI establishes a cryptographic binding between IP address resources and the ASNs authorized to originate them. The system consists of:
Route Origin Authorizations (ROAs)
A ROA is a cryptographically signed object that states: "AS number X is authorized to originate prefix Y with a maximum prefix length of Z." ROAs are issued by the Regional Internet Registry (RIR) that allocated the IP address block — ARIN for North American address space. Organizations that hold address space from an RIR can create ROAs through the RIR's portal (ARIN's RPKI management interface, RIPE NCC's portal, etc.).
Creating a ROA for your address space takes minutes and directly prevents the most common form of route hijacking: an unauthorized AS advertising your prefix. With a ROA in place, any router performing RPKI validation will mark an advertisement of your prefix from an unauthorized AS as "RPKI Invalid" and can route-policy the invalid advertisement to be rejected.
RPKI Validation at the Router Level
RPKI validation is performed by routers against a local RPKI cache (also called an RTR server or validator). The validator fetches the current RPKI repository data from the RIRs, validates the cryptographic chain of trust, and makes the ROA database available to routers via the RPKI-to-Router (RTR) protocol. Routers query the validator and receive origin validation state for each prefix-ASN pair in their BGP table.
Routers can be configured to: accept valid routes (ROA exists, AS matches), accept routes with no ROA (RPKI unknown — the majority of the internet still lacks ROA coverage), and reject RPKI-invalid routes (a ROA exists, but the originating AS does not match). The "reject invalid" policy is the key action — without it, RPKI validation is informational only.
BGPsec
BGPsec extends RPKI to provide AS path validation — cryptographic verification that each AS in the announced path actually forwarded the advertisement. BGPsec prevents not just origin hijacking but also AS path manipulation. BGPsec deployment remains extremely limited due to its requirement for all routers in the path to support the protocol and the computational overhead of signature verification at scale. It is an important long-term direction but not a near-term operational reality for most networks.
MANRS: Mutually Agreed Norms for Routing Security
The MANRS initiative, coordinated by the Internet Society, defines four concrete routing security actions that network operators should implement: filtering (preventing propagation of incorrect routing information), anti-spoofing (preventing IP address spoofing by validating source addresses against routing information), coordination (maintaining up-to-date contact information and operating a publicly accessible route filtering policy), and global validation (participating in RPKI). Organizations participating in MANRS publicly commit to these practices and are listed in the MANRS participant registry.
What Enterprise Network Engineers Should Do
For organizations with their own ASNs and IP address blocks, the highest-priority actions are:
- Create ROAs for your address space: Log into your RIR portal (ARIN for US organizations) and create ROAs for every prefix you originate. Specify exact maximum prefix lengths — if you originate a /20, do not set max-length to /24 unless you actually need to advertise more-specific prefixes.
- Enable RPKI validation on border routers: Deploy an RPKI validator (RIPE NCC's Routinator, NLnet Labs Routinator, or commercial validators from vendors including Cisco and Juniper are available). Configure border routers to reject RPKI-invalid routes from eBGP peers.
- Implement IRR filtering: Internet Routing Registry (IRR) objects — ROUTE and ROUTE6 objects in RADB, ARIN's IRR, or RIPE DB — provide an additional layer of route filtering. Configure route filters on eBGP sessions using IRR-derived prefix lists to reject prefixes not registered for the peer's ASN.
- Monitor your prefixes: Services including BGPmon, RIPE's RIS (Routing Information Service), and commercial BGP monitoring tools alert when your prefixes are originated by unexpected ASNs. Rapid detection is essential — hijacking events can cause significant damage in minutes.
For organizations that do not operate their own AS but are concerned about the security of their internet-facing infrastructure, ensuring that your ISP and hosting providers participate in MANRS and enable RPKI validation provides indirect protection. When evaluating ISP or cloud provider relationships, RPKI policy is a reasonable security question to include in vendor assessment. Contact Fortress MSSP to discuss BGP security as part of a broader network security assessment.