China Telecom's 2010 Route Leak Made Prefix-Volume Claims an Acco

Summary

The event boundary is specific: This article covers the abnormal AS23724 announcements observed through AS4134 on 8 April 2010. It does not combine that event with the 2019 Safe Host leak, the 2008 Pakistan Telecom-YouTube hijack or later allegations involving China Telecom.
The strongest public number is an attributed observation: BGPMon reported that AS23724, which normally originated about 40 prefixes, announced roughly 37,000 unique prefixes for about fifteen minutes. Different collectors and definitions can produce different counts.
Prefix share was not traffic share: BGPMon later stressed that a count representing about eleven percent of the routing table did not establish that eleven or fifteen percent of global Internet traffic moved through China Telecom.
Control-plane evidence has limits: A BGP collector can show that a route announcement was visible and selected by one of its peers. It cannot alone prove packet volume, packet inspection, one physical path, universal propagation or malicious intent.
Responsibility followed distinct controls: AS23724 controlled the abnormal export. AS4134 controlled the first visible import and onward-propagation boundary. Other networks controlled their own acceptance, preference, filtering and export.
No single routing-security control was a complete cure: Prefix filters, maximum-prefix limits, explicit relationship policy, RPKI origin validation, BGP Roles and anomaly monitoring address different failure modes.
Registry evidence mattered but did not enforce reachability: ASN, prefix, IRR, ROA and contact records supported attribution and policy generation. Running router configuration determined what the network accepted and propagated.
A credible repair must be falsifiable: Operators should bind authorized route data to generated policy and running state, replay the failure class, preserve alert and decision records, and prove withdrawal from independent control-plane and data-plane observations.

Freeze the event before interpreting the headline

On 8 April 2010, BGPMon reported an abnormal set of Border Gateway Protocol announcements associated with AS23724. The public routing identity in the report described AS23724 as a China Telecom data-centre network. According to BGPMon, the autonomous system normally originated about 40 prefixes but, during the event, originated approximately 37,000 unique prefixes that were not assigned to it. [1]

BGPMon recorded a common path segment of 4134 23724 23724. AS4134 is China Telecom's backbone autonomous system. The report said networks peering with AS4134 received and, in some cases, propagated the abnormal announcements to their customers. BGPMon's first observed announcement was at 17:54:31 UTC and its last was at 18:10:14 UTC. Those timestamps define the observation window in that report. They do not establish the first or last abnormal state on every router. [1]

The event was not globally uniform. BGPMon estimated that only about ten percent of the abnormal prefixes propagated outside Chinese networks. It also reported that 28 percent of the RIPE Routing Information Service collectors in its monitoring set detected at least part of the event. Some prefixes appeared at many observation points; others appeared only through a small number of peers or countries. [1]

Those details are important because the phrase "hijacked the Internet" compresses several different claims. One claim is that AS23724 announced prefixes for which it was not the normal origin. Another is that AS4134 and other networks accepted and exported at least some of those routes. A third is that routers selected those routes over alternatives. A fourth is that packets followed the selected paths. A fifth is that users experienced delay, loss or unexpected transit. A sixth is that someone intended the result.

The public record strongly supports the first two claims for a large route set and supports selected observations of the third. It does not supply universal evidence for the fourth or fifth, and it does not establish the sixth.

Later debate often merged these layers. Reports converted a percentage of routing-table prefixes into a percentage of Internet traffic. Security commentary sometimes moved from abnormal path visibility to assumed interception. Political discussion sometimes treated uncertainty about cause as evidence of malicious purpose.

BGPMon's later clarification rejected that compression. It said the approximately 37,000 prefixes represented roughly eleven percent of the total number of prefixes at the time, but that prefixes did not equal traffic. It also said intent remained unknown and that what happened, if anything, to redirected data remained unknown. [2]

An accountable article therefore begins by freezing the event. It covers the AS23724-AS4134 announcements on 8 April 2010, the propagation visible to bounded observation points, the controls available at each routing boundary and the evidence needed to prove repair. It excludes later China Telecom events because a shared company name does not create one causal chain.

Prefix volume was a warning signal, not a traffic meter

The approximately 37,000-prefix figure is operationally significant. A network that normally originates about 40 prefixes suddenly appearing as the origin for tens of thousands of others is a severe anomaly. The ratio alone should have triggered containment, escalation and investigation.

That does not make the count a traffic measurement.

Internet prefixes differ dramatically in traffic volume. A route covering a lightly used network may carry little traffic. A route for a major content, cloud, access or public-service network may carry much more. More-specific prefixes can be selected over less-specific routes even when the less-specific origin remains visible. Local preference, path length, policy, communities, peering relationships and existing alternate routes affect what each network selects.

A count of control-plane entities therefore cannot be converted directly into a share of bytes, packets, sessions, users or revenue. A prefix count can describe the scope of abnormal routing information. It cannot describe the weight of the services behind each route.

Collector visibility adds another limit. A route collector peers with selected networks. It records what those peers send to it, not the complete state of every router. A collector peer may advertise its selected best route rather than every available path. A route visible to one collector may not be selected elsewhere. A route absent from a collector may still exist in another part of the network.

BGPMon's report was careful about those limits. It noted that some announcements were detected globally while others appeared only at a few peers. It inferred that impact was likely larger in China and Asia than elsewhere. It did not publish a universal packet-flow reconstruction. [1]

The later clarification made the measurement boundary explicit. The roughly eleven-percent figure described the share of prefixes, not traffic. It also noted that the affected prefix set included many Chinese networks, undermining a simplistic story in which one country redirected only foreign destinations. [2]

Different later sources cited counts around 37,000, 40,000 or 50,000. Those differences do not necessarily mean one observer acted deceptively. Measurements can vary with the collector set, start and end time, treatment of duplicate or more-specific routes, definition of an affected route, and whether a report counts unique prefixes, announcements or networks.

The responsible method is attribution. State which observer produced the count, what its vantage points were, what entity it counted and which interval it covered. Preserve disagreement rather than averaging incompatible measurements into a false precision.

This lesson extends beyond the 2010 event. Routing-security dashboards often favor one large number because it is easy to communicate. A maximum-prefix alert may count routes. An RPKI dashboard may count valid, invalid and not-found states. A collector may count origin changes. An active-measurement platform may count failed probes. Each metric describes a different layer.

Good accountability does not reject metrics. It assigns each metric a claim boundary.

Control-plane observation did not prove data-plane interception

BGP is a control-plane protocol. It distributes reachability information between autonomous systems. When a router accepts an announcement and selects it as the best route, that decision can influence where packets are sent. But a BGP update is not itself a packet trace.

Several conditions separate a visible route from a proved data-plane path.

First, the collector's peer must use the route for forwarding rather than merely export it to the collector. Second, routers along the path must have consistent forwarding state. Third, the destination must be reachable through the announced origin or an onward path. Fourth, return traffic may follow a different route. Fifth, filtering, tunnelling, caching, anycast, load balancing or application behavior may change the observed result.

Active measurement can narrow the uncertainty. Traceroute, latency, packet loss, service probes and flow telemetry can show that selected traffic changed behavior from particular sources. Even those methods have limits. Router interfaces may not respond. IP geolocation may be wrong. MPLS can conceal hops. A traceroute path is a sample, not proof for every flow.

The 2010 event generated concern that sensitive traffic might have passed through unexpected infrastructure. That concern is a legitimate risk question. It is not a confirmed historical fact merely because abnormal BGP routes existed.

BGPMon said it was unknown what, if anything, was done with data. It also said intent was unknown. [2] The original author considered accidental configuration error more likely because the event was brief, the route set was extremely broad and many Chinese networks were affected. He explicitly called that assessment speculation because he had not spoken with the relevant engineers. [1]

Those statements define the permissible conclusion. The event created an opportunity for unexpected forwarding and demonstrated a capability boundary in interdomain routing. Public evidence does not prove inspection, storage, alteration or a nation-state operation.

The distinction is not semantic caution for its own sake. It changes remediation. If the primary claim is abnormal route propagation, the immediate controls are export policy, import filters, maximum-prefix thresholds, relationship constraints, origin validation, anomaly detection and withdrawal coordination. If the claim is confirmed packet interception, the evidence and response must also address data handling, encryption, endpoint compromise and legal jurisdiction.

Conflating the claims can weaken both responses. Operators may focus on geopolitical narratives while leaving ordinary route-policy defects unfixed. Investigators may overstate intent and make later corrections easier to dismiss. Customers may assume encryption solves availability when it does not, or assume route filtering solves confidentiality when it does not.

An accountable report should publish separate findings for control-plane propagation, selected-path evidence, active forwarding observations, service impact and intent. Unknown is a valid result when the evidence does not resolve a layer.

The first control boundary was the exporter

AS23724 controlled the route announcements attributed to it. That control included which routes entered its local routing information base, which routes were eligible for export, which neighbors received them and which policy generated the resulting announcements.

The public record does not disclose the initiating command or configuration. It does not show whether a route map was attached incorrectly, whether learned routes were redistributed, whether an intended filter was absent, whether a session role was misclassified or whether a software behavior contributed. Calling the event "human error" would therefore add little.

The important design question is why one initiating condition could create a table-scale export.

An external BGP session should have an explicit relationship and a bounded export contract. A customer session, peer session and transit-provider session should not receive the same route set by default. The operator should know which locally originated and customer-authorized prefixes may cross each boundary.

RFC 7454 documents operational security practices for BGP, including filtering and limits. [14] RFC 8212 later standardized a safer default expectation: external BGP routes should not be imported or exported without explicit policy. [15] These documents were not incident reports and do not prove which controls AS23724 used in 2010. They define the class of safeguards that makes an accidental broad export harder.

The exporter should generate policy from a frozen, reviewable source of authorization. That source may include internal inventory, route objects, registry records and customer contracts. Generated configuration should be diffed before deployment. An expansion from roughly 40 expected originated prefixes to tens of thousands should fail a pre-deployment check.

Maximum-prefix controls can help, but direction matters. A receive-side maximum limits how many prefixes a router accepts from a neighbor. An export-side volume check prevents a router from sending an implausible set. Both are useful. Neither replaces semantic policy.

A session may stay below its numerical threshold and still announce a strategically important unauthorized prefix. A threshold may also be set so high that it does not contain a leak. Conversely, an aggressive hard shutdown can cause a customer outage during legitimate growth. Operators need warning thresholds, hard limits, owned alerts, documented exceptions and capacity review.

The exporter also controls evidence. It should retain the pre-change configuration, generated policy, approval record, commit identity, device response, exported route set, alert chronology and rollback action. Without those artifacts, a later statement that a configuration error occurred cannot be independently tested.

The durable question for AS23724 is not whether an engineer made a mistake. It is whether the running policy made an extraordinary export possible without an independent control stopping it.

The second control boundary was the direct neighbor

The observed common path placed AS4134 between external networks and AS23724. BGPMon reported that AS4134 peers picked up and propagated at least part of the abnormal route set. [1]

That made AS4134 the first visible external containment boundary.

A direct neighbor has information that more distant networks may not have. It knows the configured relationship for the session. It can maintain the expected customer or downstream cone. It can apply prefix and path filters. It can impose volume limits. It can compare a received route set with previous baselines and route authorization data.

This does not mean AS4134 could infer every customer's legitimate route from public records alone. IRR data can be incomplete or stale. Customer relationships can be complex. Emergency exceptions can exist. A provider may carry a customer's customers. Policy generation has operational risk.

Those limits argue for layered controls, not the absence of controls.

The direct importer can require a documented route set, reject routes outside it, warn on unusual growth, use maximum-prefix limits, inspect unexpected AS paths and quarantine a session when the change is orders of magnitude above baseline. It can preserve the received update stream and contact the exporter before propagating the anomaly widely.

RFC 7908 classifies route leaks according to relationship and propagation patterns. [13] It helps explain why a route can be originated by one network yet become a broader incident through acceptance and export by others. The RFC was published later and cannot retroactively classify every private relationship with certainty. Its value is analytical: route-leak accountability follows the path through multiple policy boundaries.

The direct neighbor's obligation is not perfect foreknowledge. It is proportionate containment. A table-scale announcement from a network with a tiny normal origin footprint is the sort of anomaly that volume and relationship controls should make visible.

Onward export is a separate decision. A network may accept a route for one purpose but should not automatically advertise it to every other relationship. Export policy must reflect where the route was learned and where it is going.

This is why responsibility cannot stop at the origin. AS23724 controlled the abnormal export. AS4134 controlled whether that export crossed the first external boundary and how much of it travelled onward. The controls were different, and both mattered.

Other networks still controlled their own route selection

BGPMon listed several large networks among the paths through which its collectors observed the announcements. [1] That evidence shows visibility through specific peers and transit relationships. It does not prove that every named network selected every abnormal route for every customer.

Each network controlled its own import policy, local preference, path selection, export policy, monitoring and escalation. Some networks may have rejected parts of the set. Others may have accepted a route but preferred an alternative. Others may have selected and propagated it.

The distinction matters for fair responsibility. A distant network may not know the private AS23724-AS4134 relationship or the exact authorized prefix set. It can still apply origin validation, customer-cone checks, route-leak heuristics, path plausibility controls, prefix limits and anomaly monitoring.

Networks also control resilience. A content or service operator can monitor its prefixes from external vantage points, maintain emergency routing contacts and coordinate with upstream providers. It cannot configure a remote transit network, but it can detect an unexpected origin or path and provide authoritative information that shortens containment.

End-user access networks can observe reachability and path changes affecting their customers. They may choose different routes, but commercial and technical constraints limit that flexibility. A small access provider may depend on one transit path. A large provider may have more options but still prefer the abnormal path because of local policy.

Responsibility should therefore be route-specific:

What route did this network receive?
From which relationship did it receive it?
What authorization and path evidence was available?
Which policy accepted or rejected it?
Did the network select it?
Where did it export it?
Which alert fired?
Who owned the decision?
When did the network observe withdrawal?

This method avoids two errors. It does not assign all responsibility to the origin as though the Internet were a passive broadcast medium. It also does not say everyone was equally responsible merely because routing is distributed.

Distributed systems create distributed control. Accountability still follows each control surface.

Registry and authorization records were ledgers, not enforcement

The event involved Internet number resources: autonomous system numbers and IP prefixes. Public records helped identify AS23724, AS4134 and the normal origin of affected prefixes. They supported monitoring, incident communication and later reconstruction.

Those records did not stop a router from accepting an announcement.

This is the central reality layer. A registry can record an allocation or assignment. An IRR database can record a route object or policy intent. RPKI can allow a holder to create a cryptographically verifiable Route Origin Authorization. A network can use those records to generate or evaluate policy.

Enforcement occurs only when running systems consume the evidence and act on it.

RFC 6480 describes the resource public-key infrastructure that supports secure routing. [17] RFC 6811 defines BGP prefix-origin validation using validated ROA payloads. [16] NIST guidance later described resilient interdomain traffic exchange and practical deployment of route-origin validation. [12]

Origin validation answers a bounded question: is the origin ASN authorized by the applicable ROA for this prefix and length? It does not validate the full AS path. It does not prove that the origin intended to export the route through a particular relationship. It does not prove that every router has current validation data or applies the same policy.

The 2010 event illustrates both the value and limit of authorization evidence. If AS23724 announced prefixes whose valid origins were other networks, current ROAs and route-origin validation could mark many of those announcements invalid where coverage and policy existed. That could materially reduce propagation.

It would not resolve every route. Some prefixes might have no ROA. Some might have authorization states that did not detect the path problem. A route leak can also preserve a valid origin while violating the intended relationship path.

RFC 9234 introduced BGP Roles and the Only-to-Customer mechanism to help prevent route leaks by expressing relationship expectations. [18] It addresses a different layer from origin validation. Again, deployment in running code is what matters.

The accountability chain should therefore connect:

resource holder and registry record;
authorization entity and policy source;
validation data and freshness;
generated router policy;
deployed configuration;
observed route decision;
alert and operator action;
independent evidence after repair.

A portal screenshot proves only that a record existed. A policy document proves only that an organization intended a behavior. Running configuration and observed rejection prove enforcement.

No single control should be sold as a complete answer

Routing security discussions often elevate one control as the solution. The 2010 event shows why layered controls are necessary.

Authorized-prefix filters

A direct provider can maintain the prefixes a customer or downstream is allowed to announce. This is one of the strongest controls for a known relationship. Its weakness is data quality and operational maintenance. Stale records can block legitimate routes; permissive macros can include too much space.

Maximum-prefix limits

Volume controls are well matched to a jump from roughly 40 normal routes to tens of thousands. They can warn or stop a session. They do not identify a small, high-impact unauthorized route and can create outages if thresholds and restart behavior are poorly managed.

RPKI route-origin validation

ROV supplies cryptographic origin evidence where ROAs exist. It can reject many origin hijacks. It does not validate the full path and does not stop every route leak.

Relationship-aware path controls

BGP Roles, Only-to-Customer and customer-cone policy can limit routes that cross an implausible relationship boundary. Their effectiveness depends on correct role configuration, deployment at both sides where required and handling of complex relationships.

Default-reject policy

RFC 8212's default-reject direction reduces the chance that an external session exchanges routes without explicit policy. It does not prove that the explicit policy is correct.

Monitoring and alerting

Collectors, route monitors and active probes can detect origin and path anomalies. Monitoring does not contain an event unless alerts reach an owner who can act. Collector blind spots and false positives must be understood.

Staged change and rollback

Configuration generation, review, canary sessions, route-count diffs and automated rollback can stop a bad change before broad propagation. They cannot protect against every software defect or external announcement.

The controls overlap deliberately. If an export filter fails, the direct import filter should contain the route. If authorization data is stale, volume and path controls should still detect the anomaly. If a monitor misses the first update, a downstream observer may alert. If a hard limit creates harm, an owned exception and tested restart process should support recovery.

The strongest design assumes controls can fail. It asks which independent layer contains the failure and what evidence proves that it did.

Detection must lead to an owned decision

BGPMon detected the event because its users and collectors observed abnormal origin announcements. That demonstrates the value of external monitoring. [1]

Detection alone is not enough.

An alert should carry enough context for an operator to act: affected prefix, expected and observed origin, neighbor, AS path, route count change, validation state, collector distribution, first-seen time, comparison with baseline and contact information. It should distinguish a single unauthorized origin from a table-scale relationship leak.

The alert needs an owner. A network operations center may receive it, but the decision to suspend a session, apply an emergency filter or contact a customer may require escalation. If ownership is unclear, an accurate alert can still wait while the incident propagates.

The response playbook should define:

who can modify the relevant session;
who approves a hard shutdown;
which alternative paths preserve service;
which prefix and relationship records are authoritative;
how to contact the neighboring network;
how to preserve received updates and configuration;
how to communicate bounded facts;
how to confirm withdrawal externally;
when service restoration outweighs investigative delay.

Time synchronization is part of the evidence. BGP collector timestamps, router logs, ticket systems, messaging tools and active probes may use different clocks. A credible chronology should normalize them and retain the source of each timestamp.

The public record for the 2010 event does not expose the internal alert and decision sequence at AS23724 or AS4134. It does not say which operator first recognized the anomaly, which policy changed, who approved it or how the networks coordinated.

That gap limits accountability. A statement that routes returned to normal does not show whether a safeguard worked, an engineer intervened, a session reset, a configuration expired or an unrelated state changed.

Operators should treat the response record as part of the control. If an organization cannot reconstruct how it contained an event, it cannot prove that the same response will work next time.

Withdrawal must be proved at more than one layer

The end of a route leak is not one timestamp.

The origin router may stop advertising the route. Its direct neighbor may receive a withdrawal or replacement. The neighbor may update its selected path. Further networks may converge at different times. Route collectors may observe the abnormal path disappear from their peers. Forwarding paths and user services may normalize later.

BGPMon's last observed abnormal announcement at 18:10:14 UTC is useful evidence for its monitoring set. [1] It is not a universal convergence certificate.

A strong recovery record would include:

the last abnormal export from AS23724;
the first corrective action;
the withdrawal or corrected advertisement received by AS4134;
the last onward export from AS4134;
direct-neighbor route-table state;
disappearance from multiple independent collectors;
active path and service measurements;
residual exceptions or stale paths;
final incident-owner sign-off.

Control-plane and data-plane evidence should be aligned but not confused. A collector showing the expected origin again is strong route-state evidence. Active probes showing normal reachability are strong service evidence. Neither alone proves universal recovery.

The repair should also be tied to current configuration. If the incident was caused by an export policy, the closeout should show the corrected policy source, generated diff, deployed route map and negative test. If the direct neighbor lacked containment, it should show the new import and onward-export controls.

An emergency filter is not necessarily the final design. It may be intentionally broad to stop propagation. A permanent policy should be reviewed against legitimate routes, exceptions, growth and failure behavior.

Withdrawal evidence matters to customers and regulators because the responsible network is otherwise asking outsiders to trust the same control plane that failed. Independent observation reduces that circularity.

The recurrence test should reproduce the failure class

The most persuasive remediation is a controlled replay.

The test should use the actual policy generation and deployment path, not a simplified laboratory substitute. It should create a session with the relevant relationship role and a frozen expected route set. It should then attempt to introduce:

a route outside the authorized prefix list;
a more-specific route beyond authorized length;
an origin-invalid route;
a valid-origin route with an unintended relationship path;
a sudden table-scale route set;
a stale exception;
a policy source that is unavailable or out of date;
a configuration change that expands export scope.

Each layer should have an expected result. The exporter should reject or suppress unauthorized routes. The direct importer should contain what escapes. Warning and hard volume controls should activate at documented thresholds. Relationship policy should prevent inappropriate onward export. Monitoring should alert an owned team with usable context.

The test should also exercise failure of the controls themselves. What happens if the RPKI validator is unavailable? What happens if an IRR feed is stale? What happens if policy generation fails halfway through? What happens if the monitoring session drops? What happens if a hard maximum-prefix action removes a legitimate customer?

Fail-open and fail-closed choices should be explicit. A critical network may choose to retain an existing validated state during a validator outage rather than accept unvalidated changes. A customer session may warn before shutdown to avoid unnecessary harm. The right choice depends on service criticality and known failure modes.

Evidence should include source-data versions, configuration hashes, route counts, expected and actual decisions, alert delivery, human actions, timing and independent observations. Exceptions should have owners and expiry dates.

The recurrence test should be scheduled, not performed once. Routing relationships, prefixes, software and staff change. A control that passed after an incident can decay.

This is running-code primacy in practical form. The test does not ask whether the organization owns a policy document. It asks whether the deployed system rejects the historical failure pattern now.

Customer and board questions should follow the route

Customers cannot inspect every router, but they can ask for evidence matched to the control chain.

A customer buying transit or critical reachability can ask:

Which prefixes and AS paths is this relationship authorized to exchange?
How is that set generated and reviewed?
Which sessions use explicit import and export policy?
Which use warning and hard maximum-prefix limits?
What percentage of covered routes has valid ROA data?
How are route-origin invalids handled?
Are relationship roles represented in configuration?
Which external monitors watch customer prefixes?
Who owns a route-leak alert at all hours?
How quickly can the provider prove withdrawal?

Boards should ask about concentration. How many sessions can export a table-scale route set? How many filters depend on one data source? How many exceptions have no expiry? How often are routing-policy changes staged and replayed? Which critical services have independent path monitoring?

Auditors should trace a sample prefix from registry and contract evidence to generated policy, deployed configuration and a negative test. They should not treat a route object, ROA or portal screenshot as proof that the production router enforced it.

Regulators should avoid turning one tool into a compliance checkbox. Requiring ROAs can improve origin evidence, but it does not validate the full path. Requiring maximum-prefix limits can contain volume, but unmanaged thresholds can create outages. Useful oversight asks for outcomes: bounded authorization, layered containment, retained evidence, named ownership and tested recovery.

Public incident reports should separate:

confirmed route observations;
attributed counts;
data-plane measurements;
user impact;
root-cause evidence;
intent;
remediation commitments;
independently verified results.

That format reduces the chance that a compelling number becomes an unsupported conclusion.

The evidence standard is as important as the filter

The 2010 debate showed that routing incidents can produce two forms of harm. The technical event can disrupt or redirect paths. The evidence failure can distort what the event means.

Overstatement is not harmless. Saying that eleven or fifteen percent of all Internet traffic was hijacked creates a claim that the cited prefix count does not support. It can make later technical corrections look like denial of the underlying route leak.

Understatement is also harmful. Saying that the event was merely a brief configuration mistake can obscure the fact that table-scale announcements crossed multiple routing boundaries and were visible internationally.

The defensible middle is precise:

an enormous abnormal prefix set was announced by AS23724;
AS4134 and other networks propagated part of it;
visibility and selection varied by network and collector;
prefix volume did not measure traffic volume;
public evidence did not establish malicious intent or data use;
multiple operators controlled opportunities for containment;
current prevention requires layered, tested routing policy.

This standard preserves the seriousness of the failure without inventing facts.

It also makes accountability actionable. Engineers can test export scope and import filters. Network operators can review relationship policy and alerts. Resource holders can improve authorization records. Customers can monitor paths. Boards can require replay evidence. Researchers can publish vantage-point limits.

The aim is not to remove uncertainty from a distributed system. It is to prevent uncertainty from becoming either an excuse or a headline.

A bounded accountability model for interdomain routing

The event supports a five-part accountability model.

1. Authority

Who was authorized to originate the prefix, and what record supported that authority? Registry and RPKI evidence belong here.

2. Relationship

What was each session's role, and which routes were expected to cross it? Contracts, route sets, BGP Roles and customer-cone evidence belong here.

3. Running policy

Which configuration imported, selected and exported the route? Router policy, limits and validation state belong here.

4. Observation

Which collectors and probes saw the route or forwarding change? Vantage points, timestamps and measurement limits belong here.

5. Recovery

What changed, who approved it, and which independent evidence showed normalization? Withdrawal records, configuration hashes, active tests and closeout belong here.

Weak incident accounts usually omit at least one layer. They may show authority but not running enforcement. They may show a collector path but not forwarding. They may show a policy change but not independent recovery. They may assign blame without mapping relationship controls.

The five-part model keeps responsibility distributed but concrete.

The accountability test is bounded propagation and verifiable withdrawal

The 8 April 2010 route leak became internationally significant because one network announced an extraordinary route set, a direct backbone accepted and propagated part of it, and other networks made their own route-selection and export decisions.

The public evidence does not justify a universal traffic percentage, a packet-interception finding, malicious intent or one exact global count. Those limits do not erase the event. They define the standard for reporting it.

AS23724 controlled export scope. AS4134 controlled the first visible external import and onward-propagation boundary. Other networks controlled their own filters, preference and resilience. Resource holders controlled authorization records and escalation. Monitoring operators preserved partial evidence. Users bore consequences without controlling BGP.

Registry and authorization systems were essential ledgers. They identified resources and supported policy. They did not enforce a route. Running code determined reachability.

A credible operator should now be able to prove four things:

it knows which prefixes and paths a neighbor is authorized and expected to announce;
its running export and import policy rejects or contains announcements beyond that scope;
its monitoring detects abnormal origin, relationship and volume changes quickly enough for a named owner to act; and
after containment, independent control-plane and data-plane evidence shows that abnormal state was withdrawn and expected service returned.

That is the accountability test exposed by the 2010 China Telecom route leak. The standard is not a perfect global routing system. It is bounded propagation, measurement discipline, assigned control and repair that can be falsified.

China Telecom's 2010 Route Leak Made Prefix-Volume Claims an Accountability Test