BGP: the trust fall the whole internet is standing on

BGP carries reachability between about 74,000 independently run networks and has no built-in way to check whether an announcement is authorised or a path is real. After reading, you can tell a hijack from a route leak as the standards define them, explain why a more specific route wins and why upstream filtering decides the damage, read the documented incidents in their owners' and regulators' records, and say which defence (filtering, signed route origins, peering roles, path signatures) answers which failure.

Series Part 10 of 11 in Traffic diversion and the man in the middle. Start from the opener

Next, part 11: Fiddler, Burp, Cain and the rest: the tools that read a conversation they were not part of →

The series: 11 parts

1 ARP poisoning on a switched LAN · in preparation
2 MAC flooding and STP root takeover · in preparation
3 VLAN hopping: switch spoofing and double tagging · in preparation
4 Rogue DHCP and rogue IPv6 Router Advertisements · in preparation
5 ICMP redirects and LLMNR, NBT-NS and mDNS spoofing · in preparation
6 The Kaminsky flaw: the summer eighty vendors patched the same bug on the same day
7 The evil twin and the wireless path · in preparation
8 SSL stripping and HSTS · in preparation
9 NTLM explained: three messages, three versions, and why it is still on your network
10 BGP: the trust fall the whole internet is standing on
11 Fiddler, Burp, Cain and the rest: the tools that read a conversation they were not part of

View as Markdown

is how the internet's networks tell each other which addresses they can reach. In 2024 the US Office of the National Cyber Director counted "approximately 74,000 independently operated but interconnected networks called Autonomous Systems (ASes)" (National Cyber Director, page 3), and BGP believes what each of them says. After reading, you can tell a hijack from a , explain why the more specific route wins, read the documented incidents in their owners' records, and match each failure to its defence. The protocol itself is in the BGP primer, and the series opens with routing tables.

What BGP believes, and why

The (RFC) that defined BGP-4 in March 1995 dealt with security in one sentence: "Security issues are not discussed in this document" (RFC 1771, Security Considerations). The 2006 analysis is blunt: "There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data" (RFC 4272, Abstract).

The assumption underneath is stated in the architecture of the Resource Public Key Infrastructure (): "BGP is based on the assumption that the AS that originates routes for a particular prefix is authorized to do so by the holder of that prefix" (RFC 6480, section 3). Nothing in an UPDATE proves it. A router picks routes by local policy (RFC 4271, section 9.1), and the base protocol's only origin-side check, that the first autonomous system (AS) in the path is the neighbour's own, is optional (section 6.3). Session authentication protects the connection, not the content: it cannot exclude bogus information from a legitimate peer (RFC 4272, section 1). The idea is in Dynamic routing compared.

Two ways to be wrong: hijacks and leaks

A prefix hijack, in the US roadmap's words, is "networks originating false or unauthorized announcements of destination addresses to cause misdelivery of Internet traffic" (National Cyber Director, page 5): a question of who may originate. A route leak, a genuine route in the wrong place, is "the propagation of routing announcement(s) beyond their intended scope" (RFC 7908, section 2). Most leaks are accidents (section 2), and the roadmap says the same of BGP incidents generally (page 5).

RFC 7908 sorts leaks into six types; is an Internet Service Provider:

Type	RFC 7908 name	What travels where
1	Hairpin Turn with Full Prefix	a multihomed AS passes a route from one upstream ISP to another
2	Lateral ISP-ISP-ISP Leak	ISP-B passes a route from ISP-A on to ISP-C
3	Leak of Transit-Provider Prefixes to Peer	routes from a transit provider go to a lateral peer
4	Leak of Peer Prefixes to Transit Provider	routes from a lateral peer go to the AS's own transit provider
5	Prefix Re-origination with Data Path to Legitimate Origin	the AS re-originates the route; packets still reach the real destination through it
6	Accidental Leak of Internal Prefixes and More-Specific Prefixes	internal routes go out to providers or peers

Types 1 to 4 all break policy and differ in the roles of the ASes involved (section 4); type 1 spreads because the second ISP prefers a customer's announcement to a peer's (section 3.1).

Why the more specific route wins

Forwarding follows the longest match: of the routes that cover a destination, the longest prefix wins, and BGP calls it the more specific route (RFC 4271, section 9.1.4). The Classless Inter-domain Routing () standard states the consequence: "Traffic can be hijacked by advertising a prefix for a given destination that is more specific than the aggregate that is normally advertised for that destination" (RFC 4632, section 12). A covering aggregate cannot outvote a longer route that a router has accepted.

The same section puts the defence at provider borders: route policy filters, and upper bounds on accepted prefix lengths taken from Regional Internet Registry (RIR) allocation sizes (section 12). So the damage depends on the first network that hears the mistake. Of 2019, Cloudflare wrote that the leak should have stopped at Verizon (Cloudflare, 24 June 2019); in 2024, networks that accepted and redistributed the announcements amplified the impact (Cloudflare, 4 July 2024).

The record, in the operators' own words

Pakistan Telecom and YouTube, 24 February 2008

The Réseaux IP Européens (RIPE) Network Coordination Centre (RIPE NCC) followed it through its Routing Information Service (RIS) collectors. Pakistan's aim was to block the YouTube website (RIPE NCC case study). At 18:47 , Pakistan Telecom (AS17557) started an unauthorised announcement covering part of YouTube's address space, and "One of Pakistan Telecom's upstream providers, PCCW Global (AS3491) forwarded this announcement to the rest of the Internet, which resulted in the hijacking of YouTube traffic on a global scale". Within two minutes the route "had spread to its largest extent in the RIS routing view".

The timeline records YouTube (AS36561) announcing the affected range itself at 20:07 and more specific routes at 20:18, and PCCW Global withdrawing every prefix AS17557 originated at 21:01. RIPE concluded that appropriate routing configuration stops such announcements spreading, and noted talk of certificates for number resources: the future RPKI.

China Telecom, 8 April 2010

The U.S.-China Economic and Security Review Commission reported that for about 18 minutes China Telecom advertised erroneous routes that other networks adopted, taking traffic for about 15 percent of the internet's destinations through servers in China (Commission report, page 244). On intent it was careful: "Evidence related to this incident does not clearly indicate whether it was perpetrated intentionally and, if so, to what ends" (page 243). RFC 7908 files the event as type 5 (RFC 7908, section 3.5).

2017 and after, in the FCC's record

The Federal Communications Commission (FCC) records that in 2017 "traffic from a number of financial institutions, including MasterCard, Visa, and others was also routed through a Russian government-controlled telecommunications company under 'unexplained' circumstances" (FCC 22-18, paragraph 6), without naming the company. A 2024 notice adds an unnamed, undated hijack against a cryptocurrency service to effect theft (FCC 24-62, paragraph 11).

Verizon and DQE, 24 June 2019

Cloudflare, one of the affected operators, wrote the same day: DQE Communications (AS33154) ran a BGP optimiser that produced many more specific routes, announced them to its customer Allegheny Technologies (AS396531), and that customer sent them to its other transit provider, Verizon (AS701), which passed them to the whole internet (Cloudflare, 24 June 2019). Cloudflare lost about 15% of its global traffic at the worst point.

Facebook, 4 October 2021: a withdrawal, not a hijack

Here the owner removed its own routes. Meta wrote that "This outage was triggered by the system that manages our global backbone network capacity": a maintenance command disconnected its data centres, and its DNS servers, built to withdraw their BGP advertisements when they cannot reach the data centres, did so (Meta, 5 October 2021). From outside, Cloudflare saw the routes to Facebook's DNS prefixes vanish at 15:58 UTC (Cloudflare, 4 October 2021).

1.1.1.1, 27 June 2024: a hijack and a leak at once

From 18:51 UTC the Brazilian network Eletronet (AS267613) originated a route for the resolver's address, which multiple networks accepted, at least one Tier 1 provider among them, although Cloudflare's Route Origin Authorization (ROA) allowed only AS13335 as the origin, and a route that origin validation would have marked Invalid (Cloudflare, 4 July 2024). At the same time Nova Rede de Telecomunicações (AS262504) leaked 1.1.1.0/24 upstream, and that route passed every origin check: "This BGP announcement is RPKI Valid, because the origin is correctly AS13335, but this is a route leak of 1.1.1.0/24 because the path itself is invalid". Over 300 networks in 70 countries lost the resolver; the resolver article covers what that meant for users.

Defences in layers

Filtering and session hygiene

"The main aspect of securing BGP resides in controlling the prefixes that are received and advertised on the BGP peerings" (RFC 7454, section 6). From customers, only their own prefixes and Autonomous System Numbers (ASNs) are accepted (sections 6.2.2.1 and 9), and a cap on routes per peer shuts the session if a peer suddenly sends the full table (section 8). Sessions should prefer the TCP Authentication Option (TCP-AO) and use Time to Live () security (section 5). Since 2017 external BGP (EBGP) defaults to reject: no route is imported or exported without an explicit policy (RFC 8212, sections 1 and 3). Mutually Agreed Norms for Routing Security (MANRS) makes prefix filtering, current contact data and routing intent published in an Internet Routing Registry (IRR) compulsory, and recommends source address validation and ROAs (MANRS actions, sections 4 and 5).

RPKI and route origin validation

The RPKI follows the allocation tree from the Internet Assigned Numbers Authority () to the five RIRs, and provides authorisation, not authentication (RFC 6480, sections 2 and 2.1). A ROA is a signed statement that a block's holder lets one AS originate routes for it; without maxLength, only the exact prefix is authorised (RFC 9582, Abstract and section 4.3.2.2).

Routers do not check signatures: validating caches verify the RPKI and feed routers (RFC 8210, section 3), and "the router cannot validate the data cryptographically from a well-known trust anchor. The router trusts the cache to provide correct data" (RFC 7115, section 3). The router compares each route with these Validated ROA Payloads (VRPs) and marks it Valid, Invalid or NotFound (RFC 6811, section 2). Illustrative, with documentation values (RFC 5398, section 4) and one VRP, 192.0.2.0/24, maxLength 24, AS64496:

Route	Origin	State	Reason
192.0.2.0/24	AS64496	Valid	covered, length within maxLength, origin matches
192.0.2.0/24	AS64497	Invalid	covered, origin differs
192.0.2.128/25	AS64496	Invalid	covered, longer than maxLength 24
198.51.100.0/24	AS64497	NotFound	no VRP covers it

Dropping is the operator's decision: "An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless explicitly configured to do so" (RFC 6811, section 2), a rule RFC 8481 restated for implementations (RFC 8481, section 5). The recommended policy is to discard Invalid routes (RFC 7454, section 6.1.2.2.2), since accepting them at a lower preference often amounts to treating them as Valid (RFC 7115, section 5). Holders should publish minimal ROAs, only the prefixes they really originate, and avoid maxLength (RFC 9319, section 5).

Leaks: roles and the OTC attribute

A leaked route has the right origin, so origin validation cannot see it. RFC 9234 (May 2022) has each EBGP session agree a role in the OPEN message (Provider, Customer, Route Server, Route Server Client or Peer) and adds the Only to Customer (OTC) attribute: "If a route already contains the OTC Attribute, it MUST NOT be propagated to Providers, Peers, or RSes" (RFC 9234, section 5). In 2024 the fault was where AS262504 announced the route to its upstream AS1031 (Cloudflare, 4 July 2024); for a route carrying OTC, that rule forbids exactly that step.

Path validation: BGPsec and ASPA

has each AS on the path sign the UPDATE (RFC 8205, Abstract). It became a standard in September 2017; one AS without it on the path loses the assurance (section 7.9), and it signs the control plane, not where packets go (section 8.1). In 2024 the US government found that "the standard has yet to be implemented by commercial router vendors" (National Cyber Director, Appendix A). Autonomous System Provider Authorization (), a signed list of an AS's transit providers, is still an of the Internet Engineering Task Force (IETF) on 19 October 2026 (ASPA verification draft, revision 29).

What origin validation cannot do

It does not validate the AS path (RFC 7115, section 7), and its own standard says "this system is only able to provide limited protection against a determined attacker" (RFC 6811, section 6). It protects only where networks enforce it.

How to see it

The RIPE NCC's RIPEstat checks a prefix and origin against the RPKI. Its documented call, run on 2026-10-19 for the RIPE NCC's own prefix, answer trimmed (RIPEstat documentation):

$ curl --location --request GET "https://stat.ripe.net/data/rpki-validation/data.json?resource=3333&prefix=193.0.0.0/21"
{
  "time": "2026-10-19T15:08:56.987208",
  "data": {
    "resource": "3333",
    "prefix": "193.0.0.0/21",
    "validating_roas": [
      {
        "origin": "3333",
        "prefix": "193.0.0.0/21",
        "validity": "valid",
        "max_length": 21
      }
    ],
    "status": "valid",
    "validator": "routinator"
  }
}

resource is the origin , prefix the route with its length, validating_roas the ROAs found. status is valid, invalid_asn (a covering ROA names another ASN), invalid_length (longer than the ROA's maximum) or unknown (no ROA).

Public route collectors show what routers saw. Cloudflare's 2021 post reproduces the Route Views server without Facebook's DNS prefix, and a covering route with its AS path and RPKI state (trimmed):

route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>show ip bgp 129.134.30.0
BGP routing table entry for 129.134.0.0/17, version 1025798334
3303 6453 32934
path 7FE1408ED9C8 RPKI State not found

That is the control plane, and the data plane may not follow it (RFC 7115, section 7); a traceroute shows the packets' real path.

The National Institute of Standards and Technology () data of 2026-10-19 00:00 show 70.86% of 1,262,159 IPv4 prefix-origin pairs Valid, 27.67% NotFound and 1.47% Invalid, and 79.42% of 310,354 IPv6 pairs Valid (NIST monitor); the IPv4 Valid share was 12.5% in April 2019. That counts signing, not filtering: "The monitor does not attempt to measure the extent of deployment of RPKI-ROV in operational networks" (NIST methodology), ROV being route origin validation. Cloudflare's test page checks whether your own provider drops Invalid routes; on 2026-10-19 its answer to its title was still "No" (Is BGP safe yet?).

The route origin validation calculator applies the table above to any route and VRP list you paste, and Route origin validation, worked by hand walks through each test. The CIDR / Subnet Calculator shows the "covered" relation, 192.0.2.128/25 inside 192.0.2.0/24, and the IPv6 Toolkit does the same prefix math for IPv6. The ASN lookup and the RDAP lookup ask the registry who holds an AS number or an address block: registration, not routing or ROAs.

What to remember

BGP has no internal way to check an announcement; its 1995 specification did not discuss security.
A hijack is an unauthorised origination; a route leak is a genuine route sent beyond its intended scope (six types in RFC 7908); most are accidents.
The more specific route wins wherever it is accepted, so the first upstream's filtering decides the damage, as in 2008 and 2019.
Routers do not verify RPKI signatures: caches do, routers mark routes Valid, Invalid or NotFound, and dropping Invalid routes is the operator's explicit policy.
Origin validation does not stop leaks (the 2024 leak was RPKI Valid); RFC 9234's roles and OTC address them, BGPsec is not in commercial routers, and ASPA is a draft.
On 2026-10-19 NIST counted 70.86% of IPv4 and 79.42% of IPv6 prefix-origin pairs RPKI Valid: signing, not filtering.