Why BGP Is Still the Internet's Single Point of Failure

For something so central to the modern internet, Border Gateway Protocol is built on an almost naive assumption: that the networks speaking to each other are telling the truth.

That assumption made sense in 1989. The internet was smaller, more academic, and run by a community that still behaved more like a federation of engineers than a battlefield of states, telecoms, cloud operators, criminal groups, and automated attack infrastructure.

It does not make sense now.

And yet BGP is still the control system underneath nearly everything we rely on: ecommerce, banking, collaboration platforms, payment processing, critical infrastructure, security services, and large parts of national digital resilience. It is still fundamentally a trust-based routing protocol in a world that has already moved to zero-trust thinking almost everywhere else.

That is why I keep coming back to a hard conclusion: BGP remains the internet's single most uncomfortable point of failure. Not because it always breaks. In fact, most days it works remarkably well. But because when it fails, it fails at a layer so deep that almost everything above it becomes irrelevant.

The internet still runs on route announcements and trust

At a high level, BGP is how autonomous systems tell each other, “I know how to reach this part of the internet.” One network announces reachability to a set of IP prefixes. Its neighbors decide whether to trust and propagate that information. Eventually, traffic flows according to the best path selected across many independent networks.

That sounds elegant. It is elegant. It is also fragile.

The weakness is not that BGP is poorly engineered. The weakness is that it was optimized for connectivity, not adversarial verification. The protocol is excellent at spreading routing information. It is much less opinionated about whether that information should have been believed in the first place.

So when a route leak happens, bad paths can spread fast. When a hijack happens, traffic can be diverted to the wrong operator. When a policy mistake happens at a major network, the blast radius can move from “annoying” to “continental” in minutes.

This is the uncomfortable part: the internet's routing plane is both decentralized and coupled. No single operator controls it, but everyone depends on everyone else behaving competently enough, securely enough, and transparently enough to keep the global system stable.

Why this matters more now than it did ten years ago

There was a time when a routing incident mostly meant degraded connectivity and a flood of angry emails. Today, routing instability carries much heavier consequences.

• Business dependency is deeper. Revenue, operations, and customer trust are more tightly bound to always-on digital systems than ever before.

• Attack incentives are higher. Diverting traffic is no longer just a prank or a misconfiguration risk. It can support espionage, interception, disruption, or targeted economic damage.

• System complexity has exploded. Multi-provider architectures, edge services, APIs, identity dependencies, and global SaaS chains mean a routing issue can cascade across layers that were designed by completely different companies.

• Trust assumptions have broken everywhere else. We now design applications around least privilege, short-lived credentials, segmentation, and defense in depth. Routing is one of the few foundational layers still carrying legacy trust assumptions from a friendlier era.

That gap matters. Once the control plane beneath your application is manipulated, many of your elegant architectural decisions above the network stop helping.

Why we still have not “fixed” BGP

People outside infrastructure often assume that if a protocol is this important and this risky, surely there must be a clean fix. There isn't.

The hard truth is that internet routing is not one system. It is an agreement surface between thousands of independently governed systems with different incentives, budgets, political constraints, and operational maturity.

That makes every improvement path messy.

Yes, we have better filtering. Yes, we have IRR-based validation. Yes, we have RPKI and Route Origin Validation. Yes, operators have become more disciplined. All of that helps, and all of it should continue.

But none of those measures magically turns BGP into a fully verified, globally enforced, cryptographically coherent routing fabric. Adoption is uneven. Policy is inconsistent. Misconfigurations still happen. And the internet, by design, keeps rewarding reachability even when the trust model underneath is incomplete.

This is why I am skeptical whenever someone talks about “solving” routing insecurity as if it were a product feature rollout. The issue is not just technical. It is economic, political, and operational. The internet inherits the discipline of its participants, and participants vary wildly.

The real lesson: stop expecting the routing layer to be perfect

In cybersecurity and reliability, the most dangerous mistake is building strategy around an assumption you do not control. For many teams, BGP is exactly that assumption. They treat upstream routing as if it were a stable utility. It isn't. It is a dynamic, human-operated, globally shared control plane with plenty of sharp edges.

So the more useful question is not “How do we make BGP flawless?” The more useful question is “How do we build businesses that survive when routing is imperfect?”

That mindset changes everything.

How we work around an unfixable foundation

At Link11, years of operating in front of critical services taught us something simple: you do not get paid for admiring the internet's fragility. You get paid for engineering around it.

That means accepting that route leaks, hijacks, propagation delays, upstream mistakes, and regional instability are not theoretical events. They are design inputs.

Practically, that pushes you toward a few principles.

• Design for path diversity. If your service depends on one transit path, one geography, or one provider relationship, you do not have resilience. You have hope.

• Minimize hidden dependencies. Teams often build redundancy at the application layer while centralizing DNS, identity, telemetry, or routing assumptions somewhere else. Real resilience starts by finding the invisible choke points.

• Instrument the control plane, not just the app. Many teams can tell you their API latency to the millisecond but cannot tell you when route visibility shifts in a meaningful way. That is backwards.

• Prepare for graceful degradation. When reachability becomes asymmetric, partial service is far better than total confusion. Degrade intentionally before the network degrades you accidentally.

• Shorten detection-to-decision time. Routing incidents are unforgiving because they compound fast. The organizations that recover best are the ones that compress the time between anomaly, validation, and action.

None of this is glamorous. It is not a keynote narrative. It is operating discipline. But discipline is what turns an internet-wide weakness into a survivable local event.

Why CEOs should care about this, not just network engineers

One of the biggest leadership mistakes in technology is assuming infrastructure risk belongs exclusively to infrastructure teams. It doesn't.

BGP risk is a board-level topic disguised as a network engineering topic. Why? Because it sits directly underneath customer trust, service continuity, revenue protection, regulatory exposure, and brand credibility. If your company depends on digital delivery, routing resilience is not a backend detail. It is a strategic assumption in your business model.

That does not mean every CEO needs to understand path selection attributes or policy communities. It does mean leadership needs to ask harder questions:

• What routing assumptions are embedded in our architecture?

• Where is our real concentration risk?

• How quickly would we detect a global or regional routing anomaly?

• What happens to customers if one major upstream path becomes unreliable?

• Which parts of our response are practiced versus merely documented?

Those are not abstract resilience questions. They are business survival questions.

The strategic takeaway

The internet is not failing because BGP exists. In many ways, the remarkable thing is that the system still works as well as it does. But we should stop confusing historical success with structural safety.

BGP is still one of the clearest examples of inherited fragility at internet scale: foundational, indispensable, globally shared, and still more trust-based than the modern threat environment deserves.

We may keep improving it. We should. We may incrementally reduce abuse and error. We should. But the smartest operators are not waiting for a perfect routing future that will never fully arrive.

They are building architectures, playbooks, and companies that remain legible and resilient even when the underlying map of the internet shifts beneath them.

That, to me, is the mature posture: not blind trust, not fatalism, but disciplined adaptation.

The protocol may be old. The responsibility is not. If you build on the internet, routing is part of your threat model-whether you acknowledge it or not.

---