Built to Survive Nukes, Not Spam

Paul Baran's 1964 RAND memorandum, RM-3420, opens with a problem that concentrates the mind: how do you build a communications network that nuclear weapons cannot sever? [S1] His answer eliminated the center. A centralized hub can be killed with one missile; a distributed mesh of nodes, each routing traffic as independent data fragments, survives the loss of any subset because there is nothing essential to destroy. [S1][S2] The mathematics — proven in the memorandum — held. [S1]

That logic migrated into ARPANET's architecture and eventually into TCP/IP itself. Internet historians have since contested the nuclear framing: ARPANET's actual mandate from DARPA was resource-sharing among research universities, and the specific nuclear-hardening requirement belonged to Baran's separate Air Force–commissioned study, not the network as built. [S3] The structural consequence, though, was the same regardless: a global network built on the assumption that any node might be gone tomorrow, and that no node could be trusted with authority over the rest. [S3]

From that single design choice, three defining pathologies follow directly — not as bugs, but as features.

The identity problem

TCP/IP routes packets by address. It has no mechanism to verify who sent them. [S8] SMTP — the protocol carrying email, built atop the same foundational model — means your mail server announces its own identity and the underlying protocol accepts that announcement without verification. [S8]

Every mechanism ever invented to fight spam — SPF, DKIM, DMARC, greylisting — is an optional, application-layer patch sitting above a foundation that was never designed to care about identity. [S8] These patches work tolerably when major providers deploy them. They fail the moment an attacker routes through one that doesn't. The underlying layer still has no concept of sender verification. [S8]

BGP: the routing layer that believes anyone

The Border Gateway Protocol governs how every router on Earth learns how to reach every other network. [S4] Its operating principle is cooperative announcement: any network tells its neighbors which IP address blocks it can deliver traffic to, and neighbors accept and propagate that information without cryptographic verification. [S4][S8] BGP was built for mutually trusting administrative peers. [S8]

February 24, 2008, 18:47 UTC. Pakistan Telecom was attempting to block YouTube only within Pakistan, pursuant to a domestic government order. It misconfigured a route announcement, advertising a more-specific /24 prefix for YouTube's address space. [S4] Its upstream provider, PCCW Global, propagated the announcement to the global internet without filtering. [S4] Under BGP's longest-prefix-match rule, more-specific routes win. Routers worldwide began sending YouTube traffic to a 2-Gbps pipe in Islamabad. [S4] Service was interrupted for approximately 30 minutes to over two hours depending on region. [S4] No exploit was used. No credential was stolen. A single misconfigured router advertisement, accepted by one upstream provider without scrutiny, black-holed a global platform. [S4][S5]

YouTube's engineers countered by announcing an even-more-specific /25 prefix — outbidding the Pakistani /24 within BGP's own logic. [S5] The only defense the protocol offers is to play the same game the problem used.

On April 8, 2010, China Telecom's network announced approximately 37,000 unique IP prefixes, rerouting all traffic destined for approximately 15 percent of the internet's destinations through Chinese infrastructure for roughly 18 minutes. [S6] Affected networks included the US Senate, all four branches of the US military, the Office of the Secretary of Defense, and NASA, alongside Dell, IBM, Microsoft, and Yahoo. [S6] The US-China Economic and Security Review Commission explicitly declined to clear China Telecom of deliberate action, acknowledging it had no way to determine what was done with the hijacked data. [S7] That ambiguity is not a failure of investigation — it is a design consequence: BGP makes attribution as technically impossible as prevention. [S7]

RPKI — Resource Public Key Infrastructure — allows networks to publish signed records of which autonomous systems are authorized to announce which IP blocks. [S8] Available since approximately 2012, it now covers a majority of IPv4 routes. [S9] But coverage and enforcement are different problems. Only a minority of global networks actually filter routes that fail RPKI validation — meaning the authenticated records exist and are routinely ignored in practice. [S9]

DDoS: the defense always arrives downstream

Because TCP/IP requires no sender verification, IP source addresses can be freely spoofed. [S8] An attacker can flood a target with packets claiming to originate from millions of addresses simultaneously, and the network carries them without inspection. [S8]

BCP 38, the IETF best-practice document recommending ingress filtering that would prevent most source-address spoofing, was published in May 2000. [S8] More than 25 years later, it remains incompletely deployed globally. [S8] The economics are structurally familiar: implementation costs each individual network operator time and capacity; the benefit accrues to everyone else on the internet. A tragedy of the commons, baked into a protocol that never required validation. [S8]

The result: a DDoS flood cannot be distinguished from legitimate traffic until it has already arrived and consumed the bandwidth. Every defensive layer — scrubbing centers, rate limiting, upstream filtering — operates downstream of the attack. [S8]

The inversion

The nuclear threat that shaped the architecture's founding logic has since dissolved. [S3] The architecture has not.

What remains is a multi-trillion-dollar global economy running on a protocol stack with no identity layer, no mandatory trust verification, and no central kill-switch. [S8] The blast-hardened logic is now the load-bearing substructure of finance, logistics, healthcare, and governance.

Retrofitting authentication onto a protocol designed, as a first principle, to need none is not a software engineering problem — it is an architectural contradiction. You cannot add a central identity authority to a system whose every design choice assumed that central authorities are the first thing the enemy destroys. [S3] The patches accumulate. The foundation keeps not caring.

Your spam folder already knew that.