Border Gateway Protocol — How a 1989 Protocol Can Quietly Reroute Telegram
The internet routes on trust, not proof — here is what that means for Telegram, and for anything you build on top of it
In July 2018, traffic headed for Telegram from around the world quietly took a detour through servers in Tehran. Nobody hacked Telegram. Nobody broke its encryption. Iran’s state telecom simply reached for the internet’s core routing system, the Border Gateway Protocol (BGP), and announced to the rest of the internet, “Telegram lives here now,” and a big chunk of the internet believed it.
That is not a flaw in Telegram. It is how the internet was designed to work. And in June 2026, when India temporarily restricted Telegram around the NEET medical-entrance re-exam over fears of leaked question papers, the same old question came back: was this ordinary blocking, or was the internet’s routing layer being bent again?
This post is about BGP — the system that decides which path your data takes across the internet — and one uncomfortable fact: it runs on trust, not proof. I’ll keep it concrete: what BGP is, how a stranger can quietly claim your traffic, the Telegram incidents that show it happening, the defenses that exist, and — most important if you build software — why a layer you do not own should shape a few of your design choices. I’ll skip BGP’s message formats and its full path-selection math; those are a rabbit hole of their own.
What BGP is, in one picture
The internet is not one network. It is more than 70,000 separate ones — your home ISP, Google, a bank in Brazil, a university in Spain — none of them in charge of the others. For your message to reach a friend across the planet, dozens of these networks have to agree, hop by hop, on who hands the packet to whom. There is no central map, and no head office that knows where every address lives.
Each of these networks is called an autonomous system (AS) — a chunk of the internet under one organization’s control, with its own ID number (Google is AS15169). Each one owns blocks of IP addresses, written like 149.154.160.0/20, which is just a range of addresses that network is responsible for. BGP is the language these networks use to tell each other, "send me anything headed for this block." When a network says that, its neighbors write it down and pass the message along.
Here is the analogy that makes it click. Picture the global postal system before any central authority existed. Every regional post office knows only its immediate neighbors. To get a letter from Tokyo to a village in Portugal, Tokyo does not need a world map — each office along the way just shouts to its neighbors, “Mail for Portugal? Hand it to me, I know someone closer.” BGP is that shouting, formalized.
The Border Gateway Protocol is the routing protocol that autonomous systems use to tell each other which blocks of IP addresses they can deliver traffic to. Routers build their delivery decisions from the accumulated announcements of their neighbors.
Here is the detail everything else hangs on: when a network announces a block of addresses, its neighbors believe it by default. There is no step that checks “do you actually own those addresses?” BGP was sketched out in 1989 — the legend says on a couple of napkins at a meeting — back when every network operator knew the others by name. Trust was reasonable then. The internet kept that trust model and grew 70,000 times larger around it.
One more rule matters, because attackers pull this exact lever: when two networks both claim the same destination, the more specific claim wins. If one announces 149.154.160.0/20 (a big block) and another announces a smaller slice carved out of it, traffic follows the smaller, more specific one. It works like a mailing address - "Apartment 4B, 12 Oak Street" beats plain "Oak Street" because it is more precise.
How a stranger claims your traffic
Two things go wrong with “believe what you are told,” and from the outside they can look identical.
The first is a BGP hijack — a network announcing a block of addresses it does not own. Because the more specific claim wins, the attacker does not even have to be clever. If Telegram announces its big block and a hostile network announces a smaller slice of it, that smaller announcement quietly vacuums up traffic for those addresses — worldwide, from every network that accepts it. The traffic never reaches Telegram. It goes to whoever made the more specific claim, who can drop it, see who is talking to whom, and — if the traffic is not encrypted — read it before passing it on.
The second is a route leak — an announcement escaping the audience it was meant for. Imagine a small network that buys internet access from two big providers and is supposed to keep them separate. A misconfiguration makes it re-announce everything it hears from one provider to the other, effectively telling the internet, “route the whole world through me.” Suddenly a tiny network with a thin connection becomes the advertised shortest path for traffic it cannot possibly carry. Packets flood in, the link drowns, and connectivity collapses for everyone dragged through it.
Neither of these needs sophistication. BGP simply has no notion of “wrong.” An announcement is just a claim, and the protocol’s whole job is to spread claims fast, not to judge them. The dangerous scenario — a stranger claiming your address and the entire internet nodding along — is not prevented, because the protocol was never built to prevent it. It happens by accident constantly (a fat-fingered config) and on purpose occasionally.
The Telegram case study
Telegram is a useful lens because it was targeted at this layer twice within months, using two very different techniques. One was a sledgehammer. One was a scalpel.
These are publicly documented events, and where intent was never proven, I say so.
Russia’s sledgehammer (April 2018). After Telegram refused to hand its encryption keys to Russia’s security service, a court ordered the app blocked. This was not a BGP hijack — it was plain IP blocking, ordering Russian ISPs to throw away traffic to Telegram’s addresses. The catch: Telegram hid behind big cloud providers, so its traffic looked like ordinary traffic to Amazon or Google. To block Telegram, Russia had to block those cloud ranges too. The blocklist ballooned past 19 million addresses, and unrelated services riding the same clouds broke for Russian users. The punchline: Telegram stayed up anyway, hopping to fresh addresses faster than the blocklist could grow. A blunt weapon took down half the neighborhood and still missed its target.
Iran’s scalpel (July 2018). This one was surgical, and it is a textbook hijack. In July 2018, Iran’s state telecom started announcing ten of Telegram’s address blocks as if it owned them. Monitoring systems caught it as it happened, and for the duration, Telegram-bound traffic from around the world was pulled toward Iranian infrastructure. Iran’s ICT minister acknowledged the incident and said the telecom would be penalized “in the event of an error, whether inadvertent or intentional,” leaving intent officially open. What is not in dispute is the capability: once traffic lands on your infrastructure, you can block it, inspect it, or pass it along.
From Telegram’s seat, the app was flawless — encrypted, distributed, well-built. The encryption held, so the contents stayed private — but that was never the weak point. Reachability was, and that road belonged to someone else who could block it or watch who used it. That is exactly why the June 2026 India episode was so hard to call. India’s government ordered a temporary block on Telegram ahead of a NEET medical-exam re-test, arguing the app was being used by cheating networks — ordinary IP blocking. But Telegram’s founder, Pavel Durov, went further, publicly accusing Indian telecom operator Reliance of BGP-hijacking Telegram traffic for users outside the country, including in the UAE. Reliance Jio denied any involvement and said it followed global routing best practices. That ambiguity is not a gap in reporting. It is a property of the protocol — from the outside, a deliberate hijack and an honest misconfiguration look nearly identical, which is why the accusation was easy to level and hard to prove.
The defenses, and what they don’t fix
The good news: the trust model is being patched. The honest news: the patches are partial and slow.
Get Vivek Mittal’s stories in your inbox
Join Medium for free to get updates from this writer.
The main one is RPKI (Resource Public Key Infrastructure), a system of cryptographic certificates that ties each address block to the network allowed to announce it. The owner publishes a signed statement — “this network, and only this network, may originate this block” — and routers that check these records can reject announcements that do not match. What you gain: naive hijacks become detectable and droppable. What you do not get: RPKI only validates who announced the block last, not the full path the traffic actually takes, and it only protects you against networks that bother to check. A growing share of the internet now publishes and checks these records, but plenty still do not.
Around RPKI sit older, softer defenses. Networks filter what their customers are allowed to announce, which stops most garbage at the first hop — but it depends on humans keeping the filters current. Industry agreements like MANRS ask operators to commit to a security baseline, which raises the floor — but it is voluntary, so coverage is uneven. And BGPsec goes further by signing the entire path rather than just the origin, closing the gap RPKI leaves open — but it is heavy to run and almost nobody has deployed it. The throughline: none of these is free, and none is complete. The internet is still a long way from a routing layer that verifies before it trusts.
Why this matters if you design systems
Here is the part that should change how you think. You can build a beautiful distributed system — the right consistency model, clean failover, redundant regions — and all of it rides on a routing layer from 1989 that you do not own and cannot fully trust. Your careful CAP theorem trade-offs assume your packets actually reach the nodes you picked. BGP is the assumption underneath the assumption.
There is a specific trap worth burning into memory: a routing failure usually will not show up on your dashboards. Your health checks run inside your own cloud, so they stay green while the break sits on the public internet between your users and you, and the first you hear of it is a spike in support tickets from one region. Watching your reachability from outside your network matters as much as watching it from within.
I have watched this play out. On a multi-region service I worked on, every internal health check stayed green through an outage that, from the outside, left a whole region of users unable to reach the service — the break was a routing problem upstream, nowhere near my code. After that, putting a global front door in front of the origins stopped being a nice-to-have. I leaned on Azure Front Door for it, and I will dig into how that works in its own post; here, the point is simpler — one anycast entry point (one address announced from many locations, so users hit the nearest healthy one) can shed a bad region instead of letting it take the whole service down.
That is not a reason to despair. It is a reason to design for it. The moves split by which problem they actually solve:
- Anycast and a global front door shrink the blast radius of a regional outage or route leak. Put the front door ahead of your origins, and a bad route to one data center degrades that slice instead of stranding a whole region. What they do not do is stop a more-specific hijack — the attacker’s narrower announcement still wins everywhere, anycast or not.
- Publish RPKI records for your own address space, so networks that check reject naive hijacks at the door. This, not anycast, is what actually targets the hijack.
- Monitor your address blocks with a route-monitoring service (Cloudflare Radar, ThousandEyes, Kentik, or the open BGPStream feed), so a hijack reaches you from your tooling, not from a flood of support tickets.
None of this makes you immune. It moves you from “one route leak erases you” to “a routing problem degrades you,” and that gap is the entire game.
Wrapping up
- BGP is how 70,000+ independent networks tell each other which IP addresses they can reach, with no central authority and no built-in verification. It routes on trust, not proof.
- A BGP hijack is one network claiming addresses it does not own. Because the more specific claim always wins, an attacker can siphon a target’s traffic worldwide without ever touching the target.
- A route leak is an announcement escaping its intended audience, which can turn a small network into the internet’s advertised shortest path and collapse connectivity for everyone dragged through it.
- Telegram was hit two ways in 2018: Russia’s blunt IP block grew past 19 million addresses and still failed, while Iran’s surgical BGP hijack rerouted Telegram traffic from around the world.
- The defenses are real but partial: RPKI checks who announced a block but not the full path, BGPsec checks the path but is barely deployed, and filtering and MANRS depend on operator goodwill.
- Your system, however well designed, rides on a routing layer you do not control. Anycast, a global front door, RPKI records, and BGP monitoring turn an erasure into a degradation, which is the realistic goal.
BGP is one of computing’s quiet successes. A protocol sketched on napkins in 1989 still stitches together a planet-scale network of mutually distrustful operators, and it mostly just works, every second, invisibly. The same trust that made it simple enough to adopt is what makes it exploitable. There was no central authority to ask permission from, so there is no central authority to verify the truth either. That was the deal, and everyone online is still living inside it.
The Telegram story lands because it strips away the comforting idea that good engineering protects you. Telegram did the hard part right and still got rerouted at the border, because the border was never theirs to secure. For anyone building on the public internet, the lesson is not fear, it is humility about the foundation. Know that the layer beneath you trusts strangers by default, design so a betrayal there bruises instead of breaks, and lean toward an internet that one day checks before it believes.
Written & edited by — Vivek Mittal
