AS7007 in 1997: The BGP Leak That Taught the Internet About Route Trust
The 1997 AS7007 incident showed how unfiltered BGP input, pathological deaggregation, and global route propagation could make one provider's mistake disrupt the wider Internet.
On April 25, 1997, networks began seeing their own routes originate from AS7007
Operators on the NANOG mailing list reported a startling symptom: prefixes belonging to unrelated networks were suddenly being advertised as more-specific routes associated with AS7007, MAI Network Services.[1] Because IP forwarding prefers the most specific matching prefix, those announcements could override legitimate aggregate routes even when the AS path looked worse. The incident disrupted connectivity across a significant portion of the Internet and demonstrated that BGP’s cooperative trust model could turn one provider’s mistake into everybody’s routing problem.
The routing system believed specificity before ownership
BGP distributes reachability claims, but classic BGP does not cryptographically prove that the announcing network is authorized to originate each prefix. Filtering policy has to provide much of that protection operationally.
A downstream full table entered AS7007 without sufficient filtering
MAI’s own explanation said a downstream customer sent something like a full routing table—about 23,000 routes—and that AS7007 lacked an inbound distribute list that would have constrained what the customer was allowed to announce.[3] That was the first containment failure. A customer session that should have carried a limited set of customer and customer-of-customer prefixes was allowed to inject a broad view of the Internet. Once those routes entered the provider’s control plane, a router defect or misbehavior made the situation far worse.
Customer boundaries are security boundaries
A transit provider should know the set of routes a customer is authorized to originate or pass through. Accepting an unconstrained table from a customer makes every upstream peer depend on that customer’s correctness.
The router deaggregated routes and stripped useful path history
Contemporary operator reports described the AS7007 router as turning many learned routes into more-specific /24 announcements and presenting them as though they originated from 7007.[2] MAI said it believed a Bay Networks software problem was involved, though the precise implementation behavior was debated in the operator community. The result was decisive regardless of the internal cause: more-specific routes with shortened apparent provenance spread outward and attracted traffic that should have followed legitimate aggregates.
Deaggregation multiplied the blast radius
One bad full table became tens of thousands of highly attractive specific routes. The transformation increased both the number of routing entries and their forwarding preference.
Removing the source did not immediately remove the bad routes
Operators observed that erroneous AS7007 routes continued circulating after the originating network had been isolated.[2] Route flap dampening and the distributed nature of BGP convergence complicated cleanup, leaving some networks with stale or suppressed paths after the source was gone. This is an important distributed-systems lesson: stopping a producer does not instantly erase state already replicated through a network. Recovery requires understanding how caches, timers, dampening, and peer-specific policy preserve information after the triggering system disappears.
Propagation creates historical state
Once a control update has crossed administrative boundaries, each recipient has its own lifecycle for that information. Recovery therefore depends on downstream behavior as much as on fixing the origin.
The incident strengthened the case for strict route filtering
Modern BGP operational guidance recommends explicit inbound and outbound policies at network borders. RFC 7454 says providers should apply filters to advertised and received routes and describes especially straightforward filtering for customers: accept only the prefixes the customer is supposed to announce.[4] AS7007 became an enduring example of why this seemingly mundane configuration work matters. The protocol cannot distinguish a catastrophic mistake from a legitimate business change unless operators encode policy.
The event also became a reference point for the formal idea of a route leak
RFC 7908 later defined classes of BGP route leaks in which routing information is propagated beyond the scope intended by policy.[5] AS7007 predates that terminology, but it helped establish the operational intuition behind it: a route can be syntactically valid BGP and still be disastrously wrong for the relationship between networks. Security therefore requires checking not only whether a message parses, but whether the route is plausible for the neighbor that supplied it.
Routing registries and origin validation address only part of the problem
The immediate 1997 debate asked whether route registries, filters, and backbone provider policy should have blocked the announcements. Those mechanisms can reduce the chance that an unauthorized origin is accepted, but route leaks can also preserve a valid origin while violating export policy. That is why BGP safety needs several layers: origin authorization, customer prefix filters, maximum-prefix limits, AS-path checks, and anomaly monitoring. No single database can substitute for disciplined border policy.
Why AS7007 belongs in software-failure history
The AS7007 incident belongs in software history because it showed how the Internet’s distributed trust model can amplify an ordinary configuration mistake and a router pathology into global disruption. A downstream full table crossed a boundary without adequate filtering, a router transformed the information into highly preferred more-specific routes, upstream networks propagated it, and stale state lingered after the source was disconnected. The lasting lesson is that routing correctness is an end-to-end property of policy. Every network that accepts and re-advertises a route participates in validating—or failing to validate—the claim it passes to the rest of the Internet.
Works Cited
- 01NANOG — Wow, AS7007! seclists.org
- 02NANOG — 7007: FROM THE HORSE'S MOUTH seclists.org
- 03NANOG — 7007 Explanation and Apology seclists.org
- 04RFC 7454 — BGP Operations and Security rfc-editor.org
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.