BGP

BGP (Border Gateway Protocol) is the protocol that makes the Internet, as a single connected network of networks, actually work. Every individual network you’ve read about elsewhere on this site — IP addressing, DNS, TCP/UDP — assumes traffic can somehow find its way from one end of the Internet to the other. BGP is the reason that’s possible: it’s the protocol responsible for exchanging routing information between the large, independent networks that together make up the global Internet.

Autonomous Systems (ASes)

The Internet isn’t one single network — it’s a collection of thousands of independently operated networks, each called an Autonomous System (AS). An AS might be a large ISP, a cloud provider, a university, or a big enough company running its own network infrastructure.

Every AS is identified by a unique Autonomous System Number (ASN) — a number assigned by a regional Internet registry, functioning much like a globally unique ID for that network. For example, an ASN might be written as AS15169 (Google) or AS5400 (BT).

Each AS owns and is responsible for one or more blocks of IP addresses (see the IP systems page), and BGP is the mechanism by which an AS tells the rest of the Internet “these IP address ranges belong to me, and here’s how to reach them.”

How BGP works

BGP is often described as a path-vector protocol. Rather than each network needing to know the full physical layout of the entire Internet, BGP works by each AS advertising which IP ranges it can reach, and through which sequence of other ASes.

  1. Each AS connects to one or more neighbouring ASes (called BGP peers), typically at physical interconnection points, and establishes a BGP session between them over TCP, on port 179.
  2. An AS advertises the IP ranges (prefixes) it owns, or that it has learned it can reach via another neighbour, to each of its BGP peers.
  3. Crucially, every advertisement includes the AS path — the full sequence of AS numbers a route has already passed through. For example, a route might be advertised with a path like AS15169 AS3356 AS6461, meaning traffic following this route would pass through those three networks in order.
  4. When an AS receives multiple possible routes to the same destination from different peers, it applies a best path selection process (considering factors like path length, various configured preferences, and other attributes) to decide which single route it will actually use and, in turn, advertise onward to its own peers.
  5. This process repeats across the entire Internet, with routing information rippling outward from AS to AS, until every network has built up its own view of how to reach every other reachable network — this collective, distributed process is what allows a packet to find its way across potentially dozens of independently operated networks with no single party controlling or even fully seeing the whole route in advance.

Why the AS path matters

Including the full AS path in every advertisement serves an important practical purpose: it gives each AS a simple built-in way to detect (and refuse) a routing loop — if an AS ever receives a route advertisement that already contains its own AS number somewhere in the path, it knows accepting that route would create a loop, and rejects it. This is part of why BGP can operate reliably across a decentralised network with no single central authority coordinating everything, but it also, as covered below, isn’t a security mechanism in the way it might first appear.

eBGP vs iBGP

BGP sessions come in two flavours, depending on whether they connect two different Autonomous Systems, or link routers within the same one:

  • eBGP (external BGP): A session between two different, separately operated Autonomous Systems — this is the “the Internet talking to itself” case described above.
  • iBGP (internal BGP): A session between routers within the same Autonomous System, used to distribute the routing information a network has learned via eBGP consistently across its own internal infrastructure, so that every router inside that AS has a consistent view of how to reach the wider Internet.

Checking BGP information yourself

Unlike most of the protocols covered elsewhere on this site, BGP isn’t something you’d typically query directly from an ordinary computer — it operates between routers, not end-user devices. However, BGP routing data is publicly viewable through several free tools:

  • bgp.he.net: Allows you to search for any ASN or IP prefix and see its current routing information, including which AS originates it and its observed AS path from various vantage points.
  • whois: Can be used to look up which organisation owns a particular ASN or IP range, directly from the command line:
whois AS15169

Your own BGP cheatsheet, linked on the Useful Resources page, covers the practical router-configuration side of BGP in more depth than this conceptual overview does.

BGP and security

BGP was designed in the 1980s, in an era when the small number of networks making up the early Internet largely trusted one another by default. That foundational assumption — that any AS advertising a route is telling the truth — remains true of BGP today, and is the source of its most serious security weaknesses.

BGP hijacking is the practice of an AS advertising IP prefixes it doesn’t actually own or have legitimate permission to route, either accidentally through misconfiguration, or deliberately and maliciously. Because BGP has no built-in mechanism to verify that an AS advertising a prefix genuinely has the right to do so, other networks generally have no automatic way to tell a false advertisement apart from a legitimate one. If enough of the wider Internet accepts a hijacked route (often because it appears to offer a shorter, more specific, or otherwise more attractive path than the legitimate one), traffic intended for the real destination can be silently redirected to the hijacking AS instead — a large-scale, Internet-infrastructure-level version of the Man in the Middle attacks covered elsewhere on this site. BGP hijacking incidents, whether accidental or deliberate, have periodically taken major services offline or rerouted their traffic through unexpected networks, and are a recurring example within the Critical Infrastructure & Real-World Attacks category on this site.

Route leaks are the more common, usually accidental cousin of a deliberate hijack — a misconfiguration causes an AS to advertise routes it learned from one neighbour onward to another neighbour it shouldn’t have, in violation of the normal business/routing relationships between them. A famous illustrative pattern: a smaller ISP accidentally advertises full Internet routing tables it learned from a large provider onward to another large provider, causing a significant, unintended surge of global traffic to briefly attempt to route through a network never designed to handle that volume — several major, widely-reported Internet outages have been traced back to exactly this kind of accidental misconfiguration rather than any malicious intent at all.

A good visualisation of a BGP route leak is the incident between Pakistan Telecom & YouTube

In February 2008, Pakistan Telecom (PTCL) accidentally took YouTube offline for much of the world.

The trigger

The Pakistani government ordered YouTube blocked domestically over a video it considered anti-Islamic. Pakistan Telecom’s engineers needed to implement that block at the ISP level.

What went wrong

The intended approach was to make YouTube’s IP range unreachable within Pakistan only, by having Pakistan Telecom’s own routers quietly drop traffic to it — a common censorship technique. To do this, an engineer configured a route for the specific block of addresses YouTube’s website resolved to. That part was fine in isolation — the problem was where else it went.

On 24 February 2008, Pakistan Telecom (AS17557) began an unauthorised announcement of the prefix 208.65.153.0/24 — a small slice of YouTube’s actual address space. This started at 18:47 UTC. Critically, this was a /24 — a much more specific route than the /22 YouTube itself was announcing. These more specific routes are generally preferred by BGP’s path-selection process, so networks worldwide started favouring Pakistan Telecom’s route over YouTube’s genuine one.

Pakistan Telecom passed this announcement to its upstream transit provider, PCCW (AS3491) in Hong Kong. This is the pivotal failure: PCCW did not validate that Pakistan Telecom actually had any legitimate right to announce that prefix.

PCCW then propagated it onward to its own peers, and from there it spread globally.

The spread

The propagation was remarkably fast. By 18:48:30 UTC, several major trans-Pacific providers were already carrying the hijacked route; by 18:49:00 most of the “default-free zone” (the core backbone providers) had it, and by 18:49:30 all 97 ASNs that would eventually carry the bad route had it — the whole thing had propagated across most of the global Internet in under two minutes. Once received, routers around the world redirected YouTube-bound traffic straight to Pakistan.

Instead of just being blocked within Pakistan as intended, YouTube became unreachable for a large portion of the entire world, since global traffic was now being routed to a Pakistani network with no intention (or capacity) of actually serving it — PTCL’s actual goal domestically had been to black-hole the traffic to enforce the block, not to serve it, so everyone whose traffic got redirected there simply got nothing back.

The recovery

YouTube’s own network operations team spotted the problem quickly and fought back using BGP’s own mechanics against the hijack. At 20:07 UTC, YouTube itself started announcing that same /24 prefix directly, competing head-to-head with Pakistan Telecom’s version. Since both were now equally specific, BGP fell back to other tie-breaking rules. YouTube then went further, splitting the block into two /25s — even more specific than Pakistan Telecom’s /24 — which gradually pulled more and more networks back to preferring YouTube’s legitimate route over the following tens of minutes.

Finally, at 20:59, PCCW disconnected Pakistan Telecom’s BGP session entirely, cutting off the bad route at its source, and the hijack was fully resolved. All told, the disruption lasted roughly two hours from the original announcement to PCCW’s disconnection

You can see a visualisation of this incident (ironically) on YouTube

RPKI (Resource Public Key Infrastructure) is the primary modern defence against both of the above. RPKI allows the legitimate owner of an IP prefix to create a cryptographically signed statement (called a Route Origin Authorization, or ROA) declaring which AS is authorised to originate routes for that prefix. Networks that perform RPKI validation can then automatically detect and reject route advertisements that don’t match this signed authorisation — directly closing the “any AS can claim anything” weakness described above, though RPKI’s real-world effectiveness still depends on enough of the Internet’s networks actually choosing to validate against it, rather than every network being required to.

BGP session security matters at a more local level too — an individual BGP session between two directly connected routers can itself be a target, and is typically protected using measures like TCP MD5 authentication (or the newer TCP-AO) between peers, and filtering to ensure a router only accepts route advertisements it has a legitimate reason to expect from a given neighbour, rather than blindly trusting everything a peer sends.

Given how much of the Internet’s basic function rests on mutual trust between independently operated networks, BGP is a strong, concrete example of a theme that runs through several pages on this site: a protocol can be foundational, essential infrastructure, and still carry security assumptions from a much smaller, more trusting era of the Internet’s history that don’t fully hold up today.