The 1997 AS7007 Leak Made Route Filtering an Internet

Summary

Frozen incident boundary: This article examines the routes originated by AS7007 on 25 April 1997 and the resulting reachability disruption. It does not merge that event with later route leaks, malicious hijacks or unrelated failures at similarly named exchanges. Contemporary NANOG records show operators observing their own address space as more-specific routes with AS7007 at the origin. [3][4]
Bounded technical reconstruction: A later APNIC account describes classless eBGP routes entering a system, being redistributed into RIPv1, losing prefix-length information, and returning to BGP as deaggregated routes with rewritten origin information. [1] That is a strong explanatory reconstruction, not permission to invent one exact internal command sequence.
Why the routes won: Internet forwarding uses longest-prefix matching. A more-specific route can attract traffic before many BGP path attributes are compared. The leaked routes therefore created an operational reality that conflicted with resource ownership and expected origin information.
Responsibility follows control: AS7007 controlled redistribution, export policy, change validation, monitoring and withdrawal. Its upstream providers controlled customer filters, prefix limits and propagation. Importing peers controlled their own acceptance policy and emergency response. End users could report failures but could not repair the interdomain route state.
Registry evidence is not enforcement: ASN, address registry, IRR and later RPKI records can preserve evidence about expected resource holders and authorized origins. Routers still act on the routes and policies loaded into running systems. The incident is therefore a clear example of running-code primacy: written authority matters only when operational policy enforces it.
Modern controls are layered: Route-origin validation, explicit import and export policy, BGP Roles, customer-cone filtering, prefix limits, independent monitoring and tested rollback address different failure paths. No single mechanism should be presented as a universal retrospective cure.
Recovery must be demonstrated: Disconnecting or correcting the originating router is not the end of accountability. Operators need evidence of withdrawals, stale-route clearing, route-table normalization, peer coordination and restored forwarding from multiple vantage points.

The event boundary is 25 April 1997

An accountable technical history begins by freezing the event. On 25 April 1997, internet operators reported an extraordinary set of more-specific routes associated with AS7007, operated by MAI Network Services. NANOG messages from the day provide contemporaneous evidence of what operators saw: address blocks they expected to originate elsewhere appeared in smaller prefixes with AS7007 as the origin, and traffic followed those announcements into paths that could not carry it correctly. [3][4]

The event is often described in later summaries as the "AS7007 incident" or a major early internet route leak. That label is useful only if it remains attached to the evidence. It should not become shorthand for every routing error of the era, nor should it imply hostile intent. The strongest public record supports an accidental propagation failure with severe effects. It does not support a claim that AS7007 intended to intercept traffic or knowingly asserted ownership of every affected block.

Later technical histories commonly describe thousands of /24 routes and an acute disruption lasting roughly two hours. APNIC's retrospective gives an approximate count of 6,000 /24 announcements and reconstructs how classful routing behavior could have transformed a large external table into more-specific routes. [1] Secure Routing's incident catalog likewise records the event as a landmark routing failure. [2] These later sources help organize the history, but contemporaneous operator messages remain important because they show the externally visible route state while the incident was unfolding.

The precise number of announcements, the exact start and end time visible at every location, and the complete internal configuration are not established by one public document. BGP views are vantage-point dependent. A route can appear at one peer before another, remain stale in one table after it is withdrawn elsewhere, or be suppressed by a filter that another network lacks. A defensible account therefore attributes numeric estimates and avoids turning one collector's view into a universal clock.

The role of the Florida Internet Exchange also requires caution. Later narratives sometimes connect the event to exchange infrastructure or use the exchange name as a convenient location marker. The public evidence reviewed here does not justify assigning the complete failure to the exchange itself. The accountability thesis rests on route transformation, export, peer acceptance and recovery. It does not require an unsupported claim about one facility's ownership of the incident.

These boundaries matter because diagnosis controls remediation. If the event is inaccurately called a deliberate hijack, the response may focus on credentials and malicious-origin detection. If it is reduced to a generic outage, the response may focus only on availability. The evidence instead points to a route-policy transformation that escaped an internal boundary and was accepted across several external boundaries.

Classless BGP met a classful interior protocol

The technical mechanism is unusual enough to require careful explanation. BGP carries network-layer reachability information between autonomous systems. Modern BGP routes include a prefix and prefix length, such as a /16 or /24, plus path attributes that operators use in selection and export policy. RFC 4271 describes the base protocol and decision process. [8]

RIPv1 was designed for an earlier classful model. It did not carry subnet masks in route advertisements. In a classful interpretation, an address could be treated according to broad historical network classes rather than the explicit prefix length present in a classless BGP route. When routes move between protocols with different information models, redistribution is not a neutral copy operation. It is a transformation.

APNIC's reconstruction describes routes learned through classless eBGP being redistributed into RIPv1. Because RIPv1 could not preserve the original classless prefix lengths, the routes were represented in a way that led to deaggregation. When those routes were redistributed back into BGP, the resulting announcements appeared as many more-specific prefixes and the original AS-path information was no longer preserved as external history. [1]

That reconstruction explains two observations at once. First, it explains the volume of /24 announcements. A smaller number of broader routes can produce many narrower routes when the prefix semantics are transformed. Second, it explains why AS7007 appeared as the origin for address space that operators associated with other networks. If the external path information is stripped during redistribution and the route is reintroduced into BGP, the reintroducing autonomous system can become the visible origin.

The public record does not disclose every software version, router entity, redistribution command, route-map or administrative action. It would be irresponsible to turn the reconstruction into a fabricated terminal transcript. The evidence supports a mechanism class: information was lost or transformed across a protocol boundary, and the transformed routes were exported into interdomain BGP.

That distinction is important for accountability. A post-incident review should not stop at "RIP was old" or "redistribution was dangerous." It should ask who authorized the protocol boundary, which attributes were expected to survive, what generated route set was tested, which export invariant should have rejected the result, and what alarm should have fired when route volume and origin changed.

Protocol translation is a recurring infrastructure risk. The two protocols can each work as designed while the composition violates system intent. A route that is valid inside one representation may become materially different when imported into another. The control owner must therefore validate the output of the transformation, not merely the syntax on each side.

More-specific routes turned bad information into forwarding reality

BGP path selection matters, but forwarding specificity comes first. Routers forward packets using the longest matching prefix in the forwarding table. A /24 route matches a narrower range of addresses than a covering /16. When both exist, traffic for addresses inside the /24 follows the /24 route even if the covering route remains available.

This behavior helps networks implement traffic engineering and multihoming. It also makes accidental deaggregation powerful. If AS7007 originated thousands of more-specific routes, those routes could attract traffic away from the legitimate covering routes. The internet did not need to believe that AS7007 legally owned the address space. It only needed enough routers to accept the announcements and install the more-specific paths.

The distinction between ownership and reachability is central. Address registries can record which organization received a block. Routing registries can record intended policy. Later RPKI systems can let a resource holder authorize an origin ASN for a prefix. None of those records automatically changes a forwarding table. The running network follows routes accepted under configured policy.

During the incident, operators reported paths for their own networks showing AS7007 as origin. [3][4] If traffic followed those more-specific routes toward a network unable to deliver it to the intended destinations, the result was a large black hole. Some paths may have behaved differently because networks applied filters, preferred other routes, or had not yet received the announcements. That variation does not weaken the mechanism; it shows that the incident's scope was determined by distributed policy.

The word "leak" is more precise than "hijack" here. RFC 7908 later supplied a taxonomy for route leaks as propagation beyond intended scope. [9] The 1997 event predates that standard, and its unusual deaggregation does not need to be forced into one modern category for the accountability question to remain clear. The routes escaped the intended operational boundary, carried misleading specificity and origin information, and were propagated widely enough to disrupt reachability.

Security discussions sometimes treat any wrong-origin route as evidence of an attacker. That inference is not supported here. Operational controls should detect the harmful route state regardless of intent. A prefix-limit alarm, an authorized-origin check or an export-set comparison does not need to decide whether the operator is careless, compromised or malicious before it blocks the announcement.

This is why route evidence is valuable. It lets investigators describe what the network asserted and accepted without speculating about motivation. Accountability then follows the systems and organizations that controlled those assertions and acceptance decisions.

Responsibility was distributed, but it was not ownerless

Interdomain routing is decentralized. That does not mean responsibility disappears. It means responsibility should be assigned to the controls each organization could operate.

AS7007 controlled the internal redistribution boundary. It controlled whether external BGP routes entered an interior protocol, whether attributes and prefix semantics were preserved, whether transformed routes could return to BGP, and which announcements were exported to upstreams. It also controlled change approval, deployment, monitoring, rollback and incident communication.

The upstream providers that accepted AS7007's routes controlled a different boundary. They could maintain a list of expected customer prefixes, reject origins outside an authorized set, cap the number of prefixes, limit accepted specificity, or require an exception for unusual announcements. They also controlled whether accepted routes were exported onward to peers and customers.

Importing peers and downstream networks controlled their own policies. Some may have had filters that contained parts of the event. Others may have relied on broad trust in an upstream relationship. Their responsibility is not identical to the originator's, because they did not create the transformed routes. But route acceptance is still an operational act.

Operators of critical services and enterprise networks controlled resilience around the routing system. They could monitor external route state, use diverse providers, retain out-of-band communication and test whether supposed path diversity shared the same upstream dependencies. Those controls could reduce impact or improve detection, but they could not correct the global route set at the source.

End users and ordinary customers had almost no practical control. They could retry, switch access networks where alternatives existed, or report failures. They could not inspect every BGP path, change provider filters or force withdrawals. Blaming users for not routing around the event would confuse exposure with responsibility.

The division of control suggests a layered finding:

The originating network had the primary duty to prevent an internal transformation from becoming an external claim.
Direct upstreams had a strong containment duty because they knew the customer relationship and could define expected routes.
Other networks had a general duty to maintain defensible import policy and monitor anomalies.
Service operators had a continuity duty to understand route dependencies and detect external failures.
Public evidence providers had an observation role, not a production-control role.

This model avoids two errors. It avoids placing every consequence on one engineer who may have executed a change inside a weak system. It also avoids calling the internet too decentralized for accountability. The relevant question is always practical control: who could prevent, contain, detect, withdraw or verify?

Export modeling should test the generated route set

A written rule that says "do not announce other networks' prefixes" is not enough. The system needs a machine-checkable representation of expected exports and a comparison against the routes the configuration will actually generate.

For a customer or edge network, an export model can define:

the prefixes the network is authorized and expected to originate;
the maximum number of routes in normal and emergency states;
permitted prefix lengths;
which routes may be advertised to each relationship;
whether customer, peer and provider learned routes may be re-exported;
which AS paths and communities are expected;
which exceptions exist, who approved them and when they expire.

The generated configuration should be tested before deployment. A test should not merely confirm that a route-map exists. It should feed representative routes through the policy and examine the resulting announcements. If classless routes cross a classful or lossy representation, the test should compare prefix count, prefix length, origin and path before and after the transformation.

The AS7007 event illustrates a high-value invariant: a routing process must not export a more-specific route for an external prefix unless that route is explicitly authorized. Another invariant could cap the difference between the expected and generated route count. A jump from an ordinary customer announcement set to thousands of /24s should stop deployment even if every individual route is syntactically valid.

Prefix limits provide a second layer. An upstream can configure a maximum number of prefixes accepted from a customer. A sensible threshold includes operational headroom but remains low enough to catch a major leak. The threshold should be relationship-specific. A transit provider, content network and small access customer have different normal route sets.

Prefix limits are not sufficient alone. A leak can cause serious harm while remaining below a generous maximum. A customer might announce the expected number of routes but the wrong routes. Limits should therefore be combined with prefix and origin authorization.

Customer filters can be derived from registry, contract, IRR and RPKI data, but those sources have gaps. A defensible system records which data source authorized each route, when it was refreshed, and how conflicts are handled. Emergency exceptions should be explicit and temporary rather than invisible bypasses.

RFC 7454 provides operational security guidance for BGP, including filtering and prefix limits. [13] MANRS frames related practices as operator actions. [14] BITAG and NIST also describe routing-security controls and deployment realities. [15][16] These documents should inform a control system, not replace evidence that the control is active on the relevant session.

The strongest evidence is a test record: the expected route set, the generated route set, the policy decision for each difference, the approved exception list, the canary result and the live route observation after deployment.

The Heng.lu doctrine separates records from enforcement

The AS7007 incident is a direct network-control case for the Heng.lu doctrine. Number resources require uniqueness, accurate records, transfer history, security metadata and operational continuity. Those records are essential, but the registry is a ledger and recordkeeper, not a sovereign controller of running routers.

An ASN record can identify AS7007. Address registry data can identify expected holders of the prefixes that appeared under AS7007. An IRR route object can describe intended origin policy. A ROA can authorize an ASN to originate a prefix. These are evidence surfaces.

The reality layer is the route accepted by a router and installed for forwarding. On 25 April 1997, the operational truth was not only what the registries said. It was that more-specific routes with AS7007 as origin were accepted and propagated, and traffic followed them.

This does not make records irrelevant. Without records, a peer has less reliable evidence for building filters and an investigator has less evidence for identifying anomalies. The point is that a record becomes operational protection only when policy consumes it, exceptions are controlled, and deployment is verified.

Running-code primacy also applies to written procedures. A procedure may require peer review and prefix filtering. If a generated configuration bypasses the filter, the running system defines the result. An audit that checks only the procedure will report a control that did not constrain the incident.

The doctrine therefore maps to three practical requirements:

Accurate ledger: Resource and policy records must identify expected prefixes, origins and responsible operators.
Enforced policy: Routers and route servers must transform that evidence into import and export decisions.
Operational continuity: Monitoring and rollback must show that erroneous state can be removed and correct reachability restored.

The article does not need to turn those principles into advocacy for one registry organization or product. The evidence is narrower. The incident shows that uniqueness and ownership records do not prevent harm when routing policy accepts contradictory running state.

Removing the BGP redistribution, prefix specificity, AS origin, peer filtering and withdrawal facts would destroy the article's thesis. That is why this is not a generic corporate-risk story with network terminology added later. It is an accountability analysis of network infrastructure itself.

RPKI, RFC 8212 and BGP Roles solve different problems

Modern routing-security discussions often ask whether RPKI would have prevented an old incident. The responsible answer is conditional.

Route-origin validation compares an observed prefix and origin ASN with Route Origin Authorizations. RFC 6811 defines the validation states used by routers. [12] If a prefix has a valid ROA authorizing another origin and AS7007 announces a conflicting more-specific route, the route can be classified invalid, depending on prefix coverage and maximum length.

Many AS7007-style wrong-origin announcements would therefore be easier to identify and reject in a fully covered, correctly configured RPKI environment. That is a meaningful control improvement. It is not proof that every route in the 1997 incident would have been rejected.

Coverage matters. A route without a covering ROA is not found invalid merely because an observer finds it suspicious. Maximum-length settings matter. A covering authorization can make a more-specific route invalid if it exceeds the authorized length, but an overly broad authorization can permit harmful specificity. Deployment policy matters because a network may calculate validation state without rejecting invalid routes.

Origin validation also does not reconstruct relationship intent. A route with an authorized origin can still leak from a customer to a provider or peer in violation of expected export policy. RFC 7908 describes several leak forms where the origin may be legitimate but propagation is wrong. [9]

RFC 8212 changes the default posture for eBGP by requiring explicit import and export policy. [10] That reduces accidental propagation caused by an implicit accept-all default. It does not guarantee that an explicit policy is correct. An operator can write a permissive policy, authorize an unsafe transformation or attach the wrong policy entity.

RFC 9234 introduces BGP Roles and an OTC attribute intended to help networks identify and prevent certain route leaks based on relationship roles. [11] It addresses relationship-aware propagation. It does not replace origin authorization, generated-policy testing, prefix limits or rollback.

Customer-cone approaches infer or maintain the set of routes expected from a customer and its downstreams. Peerlock-style filters constrain paths involving major networks. Research has shown that partial deployment can still provide useful protection, while also documenting limits and operational complexity. [17]

The layered lesson is:

RPKI and route-origin validation address authorized origin.
IRR and registry data support expected prefix and policy records.
RFC 8212 requires explicit policy.
BGP Roles and OTC address relationship-aware leak prevention.
Customer-cone and path filters constrain propagation.
Prefix limits constrain volume.
Configuration modeling detects generated-policy defects.
Independent monitoring detects departures in running state.
Rollback and coordination restore service.

Treating one control as a complete answer creates a new accountability gap. Operators should state which failure modes a control covers, what happens when data is missing, how exceptions are reviewed, and how the control is tested against a representative fault.

Recovery did not end when the originating router was disconnected

The most revealing contemporary evidence concerns recovery. An apology posted to NANOG described difficulty clearing the bad routes even after the originating router was disconnected. [4] That observation turns recovery from a simple switch-off narrative into a distributed-state problem.

BGP routes propagate through many autonomous systems. When the origin withdraws a route or a session goes down, neighbors process the change, update their selected paths and advertise resulting changes. Timers, route flap damping, session state, implementation behavior and local policy can affect how quickly tables normalize.

The original source can stop emitting bad routes while stale information remains elsewhere. A peer may retain a path temporarily, a route reflector may process changes at a different pace, or an operator may need to reset a session to clear unexpected state. Public reports from one vantage point cannot prove that every router has converged.

An accountable recovery record should therefore include:

when the origin stopped generating or exporting the bad routes;
when each direct upstream observed withdrawals;
whether sessions were reset and why;
whether route flap damping or stale-route mechanisms affected cleanup;
when collectors stopped seeing the bad origins;
when legitimate origins and covering routes regained expected visibility;
when forwarding tests reached the intended destinations;
when major peers confirmed normalized tables;
which routes remained anomalous and for how long;
who declared service restored and on what evidence.

The incident also shows why rollback plans need route-state validation. Restoring a previous configuration is not enough if the bad routes remain installed beyond the source. A rollback checklist should include expected withdrawals, table comparison and external confirmation.

CAIDA's BGPStream makes historical and live routing data accessible for analysis. [18] Route collectors are valuable for independent confirmation, but they are samples. A mature recovery process combines internal RIB and FIB data, direct peer reports, public collectors and forwarding probes.

Recovery communication should separate source containment from global restoration. "The router was disconnected" is a containment event. "All affected routes were withdrawn from direct peers" is a propagation milestone. "Independent vantage points no longer see the routes and forwarding is normal" is closer to restoration evidence.

That structure prevents premature closure. It also helps organizations measure the part of recovery they control directly and the part that depends on coordination.

Public route evidence is strong but incomplete

The public record for a 1997 routing event is unusually useful, but it still has limits. NANOG messages provide direct operator observations and an apology. [3][4] Contemporary reporting captures the scale and surprise of the outage. [5] Later technical accounts explain the protocol interaction. [1][2][6] Standards and guidance describe the controls that operators can apply. [8]-[17]

No public source reveals every private routing table, configuration diff, support ticket, peering contract or decision log. The evidence cannot identify the exact first device that accepted every route or the exact number of users affected. It cannot show which filters silently worked and prevented wider propagation.

Historical reconstruction also faces terminology drift. In 1997, operators described the incident using the language and tools available at the time. Later accounts use route leak, hijack, deaggregation and origin validation in ways shaped by later standards. A careful article should not make a 1997 operator appear to have followed or violated a standard that did not yet exist.

Modern standards are lessons for current control design, not retroactive compliance requirements. RFC 4271 was published later than the event, though it documents the mature BGP-4 model. RFC 7908, RFC 8212 and RFC 9234 came much later. [8]-[11] They help explain failure classes and prevention layers, but they do not prove what AS7007 or its upstreams were contractually required to deploy in 1997.

The evidence supports several high-confidence findings:

AS7007 originated a large number of more-specific routes for address space associated with other networks.
The route state caused substantial reachability disruption.
The event was accidental according to the available record.
Internal-to-external redistribution was central to the later technical reconstruction.
Peer acceptance and propagation expanded the impact.
Withdrawal and cleanup were not instantaneous.

It supports several moderate-confidence findings:

Classless-to-classful redistribution plausibly explains the deaggregation and rewritten origin.
A direct upstream filter or prefix limit could have contained a large portion of the route set.
Better export modeling would have exposed a major difference between intended and generated announcements.

It leaves important unknowns:

the exact configuration sequence;
the full device and software topology;
every direct peer's filter state;
the complete incident timeline;
decision ownership and approval;
the full effect by network and geography;
remediation implemented after the event.

Accountability is stronger when these confidence levels remain visible. Overclaiming would make the article easier to criticize and harder to use as an audit standard.

A verifiable remediation agenda

The public record does not establish which controls MAI Network Services or every upstream later implemented. The correct response is to define evidence that would show the failure path is now controlled.

1. Freeze expected exports

For every eBGP session, preserve a versioned expected export set. The set should include prefix, maximum specificity, origin, path constraints, relationship and approved exceptions. It should be generated from authoritative records plus explicit operational intent.

Evidence: repository commit, approval record, data-source timestamps, exception owner and expiry.

2. Test protocol transformations

Where routes move between BGP, an IGP, a static route system or another representation, test whether prefix length, origin, path and policy attributes survive as intended. Reject lossy transformations unless the resulting route set is explicitly bounded.

Evidence: representative input routes, generated output routes, invariant results and negative tests.

3. Compare generated and expected announcements

Before deployment, compute the route delta. Stop if the generated set introduces unauthorized prefixes, unexpected more-specifics, origin changes or a route-count increase beyond the approved boundary.

Evidence: pre-deployment diff and stop-condition result.

4. Enforce direct-customer filters

Upstreams should filter customer routes against an expected set, apply relationship-specific prefix limits and log every exception. Registry and RPKI data can inform the set, but unresolved conflicts should fail safely or require explicit review.

Evidence: live policy attachment, test announcements accepted and rejected, refresh history and exception list.

5. Deploy explicit relationship policy

Every eBGP session should have explicit import and export policy. Where supported, BGP Roles and relationship-aware controls should match the operational relationship. The configuration should reject a missing or inconsistent role rather than silently accepting a broad default.

Evidence: session inventory, role mapping, policy attachment and conformance test.

6. Monitor from outside the network

Monitor origin, specificity, path, route volume and reachability from independent vantage points. Alerting should connect route anomalies with forwarding tests so responders can distinguish a visible update from a user-impacting event.

Evidence: collector queries, alert chronology, probe results and incident linkage.

7. Set automatic rollout stops

A deployment should halt when route count, unexpected origin, more-specific volume, peer visibility or forwarding impairment exceeds a defined threshold. The stop should not depend entirely on a human noticing public complaints.

Evidence: canary policy, threshold, trigger and exercised stop.

8. Exercise withdrawal and cleanup

Run safe lab or isolated tests showing that a faulty route is withdrawn, sessions converge, stale state is detected and independent probes return to normal. The exercise should include peer communication and out-of-band access.

Evidence: timestamps for origin withdrawal, peer receipt, table normalization and forwarding recovery.

9. Preserve incident evidence

Retain route updates, configuration diffs, policy-generation inputs, approval records, alerts, commands, peer messages and recovery checks. Time synchronization should make the sequence auditable.

Evidence: immutable incident bundle with hashes and access controls.

10. Verify remediation against the original failure class

Do not close remediation with a generic statement that monitoring improved. Recreate a safe representation of the classless-to-classful transformation or an equivalent unauthorized deaggregation and show where the current control chain stops it.

Evidence: test design, expected failure point, observed result and independent review.

This agenda is deliberately product-neutral. It does not require one vendor, registry or security service. It requires an operator to show that expected policy is accurate, running policy enforces it, anomalies stop deployment and recovery is independently visible.

Governance questions should follow the route

Boards, regulators, service buyers and auditors do not need to operate BGP to ask useful questions. They need to follow the route through the control chain.

Boards should ask which changes can alter public announcements, how generated exports are tested, who can approve exceptions and how quickly rollback can be executed. They should receive results from exercises, not only policy documents.

Transit providers should ask whether customer filters are derived from current evidence, how many sessions have prefix limits, which sessions accept broad exceptions and whether those exceptions expire. A control applied to most customers can still leave the highest-risk session exposed.

Enterprise buyers should ask whether dual providers are operationally independent, whether external route monitoring covers critical prefixes and whether incident communications distinguish routing failure from application failure. Contractual diversity is not the same as path diversity.

Auditors should sample actual session policy, generated route sets and route observations. They should trace one registry or RPKI record into a router decision and test what happens when the data is missing or conflicting.

Regulators should avoid defining routing accountability as deployment of one technology. A requirement to create ROAs can improve origin security, but it does not prove relationship-aware filtering, change validation or recovery. Evidence-based obligations can ask operators to document the controls appropriate to their role and test them.

Incident reviewers should separate root cause, contributing conditions, trigger, detection, response and recovery. "Human error" is not a sufficient root cause. It does not explain why the system generated thousands of unexpected routes, why upstreams accepted them, why monitoring did not stop propagation or why cleanup remained difficult.

The governance objective is not to make every route change risk-free. It is to ensure that organizations with practical control can show how they reduce, contain and repair the risk their network position creates.

The accountability test is observable enforcement

The 1997 AS7007 incident remains important because it compresses several network-infrastructure duties into one event. An internal protocol boundary transformed route information. The transformed output crossed an external policy boundary. More-specific routes changed forwarding reality. Multiple networks accepted and propagated the claims. Recovery required distributed withdrawal and coordination.

The public record does not justify a malicious-intent claim or one exact undocumented command sequence. It does justify a strong operational conclusion: expected resource ownership and written routing intent did not constrain the running route state.

Responsibility was layered. AS7007 controlled the transformation and export. Direct upstreams controlled customer acceptance and containment. Other networks controlled import policy. Service operators controlled external monitoring and resilience. End users bore consequences without meaningful routing control.

Modern mechanisms improve the control environment, but only when their limits are explicit. RPKI can help reject unauthorized origins. RFC 8212 can eliminate implicit eBGP policy. BGP Roles and OTC can help constrain relationship leaks. Prefix limits can catch abnormal volume. Customer filters can constrain expected routes. Modeling can compare generated exports with intent. Monitoring and rollback can contain and repair failures.

The Heng.lu doctrine provides a concise final standard. Registry and routing-policy records preserve accountable evidence, but they do not rule the forwarding plane. Running code, configured policy and accepted routes determine what the internet does. Operational continuity requires that bad state can be detected, removed and independently verified.

A credible remediation record would therefore show the expected export set, generated-policy tests, direct-customer filters, prefix limits, live anomaly detection, withdrawal timing, peer confirmation and forwarding recovery. It would reproduce the original failure class safely and show which control now stops it.

The lasting question from 25 April 1997 is not whether today's operators know that route leaks are dangerous. It is whether they can prove that a transformed, unauthorized and highly specific route set cannot cross their boundaries unnoticed, and whether they can prove recovery when it does. That is the internet accountability test AS7007 made visible.

The 1997 AS7007 Leak Made Route Filtering an Internet Accountability Test