Historical Design Decisions and Their Security Consequences

Author

K19G

Updated

October 31, 2026

Historical Design Decisions and Their Security Consequences

The architectural weaknesses of interdomain routing are neither oversights nor accidental engineering flaws. They are the deliberate, logical consequences of design trade-offs made in the late 1980s and early 1990s under intense operational pressure to save a rapidly collapsing Internet.

EGP, CGE and the Origins of Interdomain Routing Protocols

In the early ARPANET and early NSFNET eras, the network was organized around a strict tree topology with a single centralized core backbone. The protocol used to connect external networks to this core was the Exterior Gateway Protocol (EGP, RFC 904).

EGP had severe limitations: - It was strictly a reachability protocol, incapable of detecting loops in arbitrary mesh topologies. - It required a single hierarchical root; it could not support horizontal peering between commercial networks. - As regional networks proliferated, the centralized architecture became an unsustainable bottleneck.

In 1989, during the “Three Dirt Clods” meeting (Kirk Lougheed of Cisco and Yakov Rekhter of IBM), BGP-1 was famously sketched on two ketchup-stained napkins (RFC 1105). BGP introduced the path-vector concept: by including the complete sequence of Autonomous Systems in the route announcement (AS_PATH), routers could detect and discard loops in arbitrary, uncoordinated mesh topologies without requiring a centralized backbone.

The Scalability Imperative: Why End-to-End Verification Was Abandoned

By 1993, the Internet faced an existential scaling crisis: the 32-bit IPv4 address space was depleting rapidly under classful allocation (\(A\), \(B\), \(C\)), and global routing tables were expanding exponentially. BGP-4 (RFC 1654, later RFC 4271) was developed specifically to introduce Classless Inter-Domain Routing (CIDR, RFC 1519), allowing route aggregation and supernetting.

At the time, typical backbone routers operated with CPU clock speeds measured in tens of megahertz and RAM measured in megabytes. Adding cryptographic signatures to routing updates: - Would have required asymmetric public-key cryptography (RSA or DSA) on every router. - Would have caused packet-processing engines and control processors to grind to a halt. - Would have required a global, authoritative Public Key Infrastructure (PKI) when even the commercial DNS infrastructure was barely nascent.

The engineering consensus was unequivocal: scalability and survival took absolute precedence over cryptographic verification.

The Trust Assumptions Embedded in BGP-4’s Design

BGP-4 was architected on fundamental trust assumptions reflecting the collegial academic environment of the early Internet:

  1. Physical Session Trust: It was assumed that if two organizations established a physical cable or leased line and configured a BGP peering session, they knew each other and could be trusted.
  2. Implicit Origin Authority: If a peer announced an IP prefix \(P\), the receiver assumed the peer had legitimate authority to originate \(P\).
  3. Implicit Path Honesty: It was assumed that intermediate transit networks would accurately append their own ASN to the AS_PATH and would not delete, reorder, or fabricate AS hops.
  4. Benevolent Operation: Routing anomalies were viewed as rare equipment failures, not malicious asymmetric attacks by state actors or cybercriminals.

Operational Flexibility Over Consistency: A Deliberate Choice

BGP was explicitly designed to allow operators to implement arbitrary, confidential business policies. An AS can modify attributes (LOCAL_PREF, MED, communities) arbitrarily on import and export without explaining its reasoning to its neighbors.

This design priority produced the Gao-Rexford model of Internet stability: routing converges stably if and only if commercial relationships follow strict hierarchical patterns (prefer customer over peer over provider). However, because policy expression is purely local and unauthenticated: - An operator cannot independently verify whether a path received from a neighbor represents the actual physical or topological path packets will take. - An operator cannot detect if an upstream peer is silently rewriting or stripping policy communities.

Why Security Was Added as an Afterthought

For nearly two decades, the Internet functioned on informal operator cooperation and out-of-band communication (the NANOG mailing list, IRC channels, telephone calls between network operations centers). When an operator misconfigured a router and hijacked traffic, people called each other to fix it.

This social trust model collapsed as the Internet transformed into critical economic infrastructure: - The rise of financial technology, cryptocurrency, and e-commerce created massive monetary incentives to steal traffic. - State-sponsored espionage groups recognized that interdomain routing could be used for covert surveillance without breaking end-to-end cryptography. - The sheer scale of the global network (over 75,000 ASes) rendered informal human relationships obsolete.

Because cryptographic security could not be retrofitted into the core BGP-4 state machine without breaking backwards compatibility across thousands of hardware vendors, security had to be built out-of-band: through Internet Routing Registries (IRR), the Resource Public Key Infrastructure (RPKI), and Route Origin Validation (ROV).