Indosat's 2014 Route Leak Made Full-Table Export Controls

Summary

The event boundary is narrow: This article covers the AS4761 mass mis-origination observed on 2 April 2014 from approximately 18:26 to 21:15 UTC. It excludes a separate Indosat event in 2011, later AS4761 anomalies, and unrelated Indonesian routing incidents.
The headline number needs an observer: BGPMon reported 417,038 new origins, while RIPE NCC described more than 400,000 affected prefixes. Those measurements establish extraordinary scale at named vantage points. They do not prove that every network installed every path or forwarded traffic through Indosat.
Root cause remains attributed: Contemporary accounts described an operational problem and repeated reports of a failed maintenance window or unfiltered upstream. The complete Indosat configuration, change record, policy-generation state, and internal incident report are not public.
Responsibility follows routing control: Indosat controlled what AS4761 originated and exported. Direct neighbors controlled prefix, origin, relationship, and maximum-prefix filters. Other autonomous systems controlled acceptance, preference, onward export, monitoring, and escalation.
Registries record authority; routers enforce reachability: ASN and number-resource records identify holders and expected origins. RIS, RouteViews, and other collectors preserve selected running state. Neither a registry entry nor a collector automatically blocks an announcement.
Origin authorization and path policy are different: Route Origin Validation can reject an origin that conflicts with a valid ROA, where relevant records and validation exist. It does not by itself prove that a relationship path or route volume is appropriate.
Recovery is not a local configuration statement: A credible closeout shows withdrawals, replacement origins, convergence at multiple independent vantage points, residual exceptions, changed policy, tested maximum-prefix behavior, and replay evidence that the same failure class is now contained.
The accountability standard is reproducible containment: Operators should be able to show the authorized route set, the generated and running policy, the abnormal delta, the first containment opportunity, the timeline of action, and an independent recurrence test.

Freeze the incident before interpreting it

The first discipline in routing accountability is to define exactly which event is being examined. On 2 April 2014, public BGP observers reported that AS4761, associated with Indosat, began originating an extraordinary number of prefixes that were normally originated by other autonomous systems. BGPMon counted 417,038 new prefixes and placed the visible interval at roughly 18:26 to 21:15 UTC. RIPE NCC analysis described more than 400,000 affected prefixes and used RIPE Routing Information Service data and RIPEstat visualisations to reconstruct examples of propagation and reachability. [1][2]

Those observations are sufficient to establish a major interdomain routing event. They are not sufficient to establish every claim that might be attached to it.

This article does not combine the April 2014 event with an earlier Indosat routing event in 2011. It does not incorporate later AS4761 anomalies or other incidents involving Indonesian networks. It does not infer one continuous operational defect from events separated by years. Such aggregation might make a larger narrative, but it would weaken the evidence needed to assign control, measure correction, and test recurrence.

The bounded event starts with the first abnormal AS4761 origins observed by the cited monitors around 18:26 UTC. It includes their spread through selected networks, the reachability changes visible from particular vantage points, detection and operator communication, the withdrawal of abnormal origins, and the return toward expected path state. It ends with the last relevant observations around 21:15 UTC, while recognizing that different collectors can see different start and end times.

This boundary also limits the root-cause claim. BGPMon characterized the scale as consistent with an operational problem and referred to reports of a failed maintenance window. Operator discussion referred to an unfiltered upstream. [2][3] Those are contemporary descriptions, not a published forensic record of the exact command, route redistribution mechanism, policy compiler state, approval decision, or device behavior that created the announcements.

An accountable analysis therefore begins with what the running network exposed: AS4761 appeared as the origin for hundreds of thousands of prefixes; the abnormal origins were visible beyond the source network; some paths and reachability changed; and the origins were later withdrawn. It treats intent, internal cause, and the complete remediation as unknown unless supported by additional evidence.

That distinction is not caution for its own sake. It creates a repairable problem. A claim such as "a maintenance error caused a global hijack" is too broad to test. A claim such as "AS4761 exported a route set radically beyond its expected authorized origins, direct neighbors accepted enough of that set to propagate it, and public evidence does not show the full set of controls that later prevented recurrence" identifies observable boundaries and missing records.

The route count is a measurement, not a map of every forwarding decision

The number 417,038 is central to the public record because it conveys the extraordinary scale of the event. It must also remain attached to its source and method. BGPMon reported that count as new origins associated with AS4761. RIPE NCC used the broader formulation of more than 400,000 affected prefixes. [1][2] The figures are close enough to corroborate a full-table-scale anomaly, but neither should be presented as a universal count installed by every autonomous system.

BGP is a distributed control protocol. A route collector receives selected updates from participating peers. Its record reflects which paths those peers chose to export to the collector, at what time, under their own policies. Another collector with different peers can see a different subset, a different first timestamp, and a different withdrawal sequence.

Several quantities are often collapsed in incident reporting:

the number of unique prefixes for which an abnormal origin was observed;
the number of BGP update messages;
the number of path variants;
the number of collectors or peers that saw an update;
the number of networks that selected the abnormal path as best;
the number of forwarding tables that installed it;
the volume of traffic carried over those paths; and
the number of users who experienced loss, delay, diversion, or no visible effect.

These are not interchangeable. A prefix can generate many updates. A collector can see a path that its peer did not use for all traffic. A network can accept a route into a routing information base without selecting it. A selected path can affect only traffic from certain sources because the Internet's paths are asymmetric and policy-specific. A service can remain reachable through an alternative path while another network loses access.

The count still supports a strong control finding. AS4761 was normally associated with a small route set relative to the global table. An observed increase to more than 400,000 origins was far beyond any ordinary growth margin. A direct neighbor did not need a perfect global count to recognize that the received set had departed from an expected customer, peer, or provider contract.

This is why accountability should focus on the expected route set and the observed delta. A session owner should be able to say how many prefixes and origins were authorized immediately before a change, which increase was expected, what warning and hard thresholds applied, and what happened when the received or advertised set exceeded them.

A reproducible incident measurement would document collector names, collector peers, address families, exact UTC intervals, deduplication rules, prefix versus update counting, and the AS-path predicate used to identify affected routes. It would preserve the raw update references or extraction commands. The purpose is not to produce one perfect number. It is to let another operator reproduce the scale, timeline, and propagation boundaries without trusting an unexamined headline.

Mis-origination is visible; intent is not

In ordinary operation, an origin autonomous system signals that it can deliver traffic for an announced prefix. During the April 2014 event, AS4761 appeared as the origin for prefixes normally associated with many other networks. That behavior is often described as a hijack because the origin changed to an autonomous system that was not expected to originate the address space. BGPMon used hijack language in its contemporary report. [2]

The observable origin state does not establish malicious intent. A malicious route hijack, an accidental redistribution, an incorrect policy attachment, a route-server error, a test leak, and a failed maintenance procedure can produce overlapping control-plane symptoms. Distinguishing among them requires internal configuration, logs, authorization records, operator testimony, and often traffic or security evidence that public collectors do not possess.

The scale of this event is consistent with a broad operational failure. That is an inference, not a complete root-cause report. The article therefore attributes maintenance and filtering explanations to contemporary observers and does not state that one exact command or operator action has been proven.

This boundary matters for both fairness and engineering quality. If an accidental event is described as an intentional interception without evidence, the account becomes legally and technically weak. If the same event is dismissed as "just a mistake," the failure of controls at multiple routing boundaries disappears. Accountability requires neither accusation nor excuse. It requires a record of what was allowed to run.

The evidence questions are concrete:

Which process supplied the prefixes that AS4761 originated?
Which policy permitted those origins to enter an external advertisement?
Was the route set generated from an authorized inventory or inherited from another session?
Did the change pass review, simulation, or canary deployment?
What advertised-route snapshot existed before and after the change?
Which direct neighbor first accepted the abnormal set?
Which alerts fired, who owned them, and what action followed?
What data showed that withdrawal and normalization were complete?

The public record answers only parts of this list. That incompleteness should be recorded as an accountability gap, not filled with speculation.

The source network owns the first export boundary

AS4761 controlled the source-side boundary. Regardless of the internal trigger, Indosat's running routing system originated and exported a route set that radically exceeded the expected scope associated with the autonomous system. The first obligation is therefore to define and enforce what AS4761 was authorized to originate and advertise.

An authorized origin inventory should connect number-resource records, customer delegations, internal service records, routing registry data, and explicit exceptions. It should have a version, an owner, an approval history, and an effective time. The generated router policy should be checksum-bound to that inventory so that an auditor can distinguish the intended input from the configuration actually deployed.

The export contract should answer four different questions:

Which prefixes may AS4761 originate itself?
Which customer prefixes may AS4761 carry as transit?
Which routes learned from providers or peers may be re-advertised, and to whom?
Which temporary exceptions exist, why do they exist, and when do they expire?

Combining these sets into one permissive filter creates the conditions for a full-table export. A provider-learned route, a full routing table used internally, or a broad route-server feed can cross an external session if the export policy is missing, attached in the wrong direction, generated from the wrong data, or bypassed by an exception.

Explicit policy defaults reduce this risk. RFC 8212, published years after the incident, specifies that eBGP routes should not be imported or exported without an explicit policy. [8] It should not be projected backward as proof of Indosat's 2014 implementation. It is useful as a durable comparison: a session should fail closed when intended policy is absent rather than exchange everything until a filter is added.

The exporter also needs a route-volume control on its own advertised set. Maximum-prefix is often discussed as an inbound feature, but operators can monitor outbound route count and delta before updates leave a network. A pre-deployment check can compare candidate advertisements with the authorized set. A live guard can alarm or block an increase that has no approved change record.

The most valuable evidence is the diff between expected and running state. A post-incident statement that "filters were added" is not enough. An accountable record would preserve:

the authorized prefix and origin set before the event;
the configuration source and generated policy;
the device candidate and committed configuration hashes;
advertised-route snapshots for the affected session;
the abnormal set and how it entered export processing;
the withdrawal commands or policy change;
the authorized set after recovery; and
a replay showing that the abnormal set is rejected.

This evidence turns a configuration narrative into a control test. It also prevents a later policy cleanup from obscuring what was actually running during the event.

Direct neighbors own the first external containment opportunity

The source network is not the only operator with control. A direct neighbor receiving a route set from AS4761 had the first external opportunity to contain it. That neighbor knew, or should have documented, the relationship type, expected prefix set, ordinary route volume, and escalation contact for the session.

The public record indicates that much of the abnormal route visibility came through providers in Thailand, with some routes propagating farther. [1][2] The complete commercial and technical relationships are not public, so each specific customer, peer, or provider label should be used only where supported. The control principle does not depend on one disputed label. Any neighbor accepting a route set radically outside an expected bilateral scope controlled an import boundary.

Several safeguards can operate there.

Prefix filtering compares received routes with an authorized customer or neighbor inventory. It is most effective when the bilateral route set is bounded and when updates to the inventory are owned and timely.

Origin filtering or validation checks whether the origin is authorized for a prefix. RPKI-based Route Origin Validation can supply cryptographic authorization where a covering ROA exists and validators are deployed. It is not the only source of origin evidence and was far less broadly deployed in 2014.

AS-path and relationship policy tests whether the path is plausible for the session. A customer ordinarily should not provide transit between unrelated upstreams. Real relationships can be complex, so policy needs explicit exceptions rather than an assumption that any path is acceptable.

Maximum-prefix controls compare received route volume with a documented range. A session normally associated with hundreds or thousands of routes should not silently deliver hundreds of thousands. Warning and hard limits need different operational responses, and both require ownership.

Explicit import defaults prevent a new or misclassified session from accepting everything because a route map is absent.

Onward-export controls separate what a network receives from what it advertises to customers, peers, and providers. A route retained for diagnosis need not be propagated.

RFC 7454 describes operational filtering, maximum-prefix limits, bogon controls, and other BGP security practices. [9] NIST SP 800-189 later organized resilient interdomain exchange practices including filtering, route-origin validation, monitoring, and coordination. [13] MANRS similarly frames filtering, anti-spoofing, coordination, and routing information as operator actions. [14] These are modern comparison points, not evidence that every safeguard was available or deployed on the relevant 2014 sessions.

The direct-neighbor question is not "why did the Internet trust BGP?" It is "why did a running bilateral policy accept this set, and what evidence now shows that the same set would be rejected or quarantined?"

Maximum-prefix control is necessary, but a number alone is not a policy

The extraordinary route volume makes maximum-prefix protection an obvious control. It is also easy to describe too simply. A hard limit can contain a mass leak, but a poorly chosen limit can disconnect legitimate customers, trigger during normal growth, or encourage operators to set thresholds so high that they never act.

An accountable maximum-prefix design begins with the authorized set. The threshold should reflect current routes, documented growth, aggregation behavior, backup announcements, and approved exceptions. It should not be a generic fraction of the global table or a value copied from another relationship.

A mature design has at least three states:

a normal operating range;
a warning range that alerts an owned response channel and freezes risky changes; and
a hard containment threshold with a documented action.

The hard action can vary. A router may reject additional prefixes, tear down the session, quarantine the received set, lower preference, or invoke automation. Each choice has consequences. Rejecting new routes can preserve established reachability while blocking growth. Resetting a session can create a wider outage. Continuing to accept routes while only sending an alert can fail open during the period when propagation matters most.

The response must therefore be tested. Operators should replay a route set that resembles the April 2014 failure and record whether the device warns, rejects, resets, or continues. They should test both a sudden full-table increase and a slower leak designed to remain below a rate-based alert. They should verify that the escalation reaches a staffed owner and that the owner has authority to contain the session.

Maximum-prefix also needs protection against exception drift. Emergency increases and one-time migrations can become permanent. Every override should have a reason, approver, effective interval, and automatic expiry or review. The running threshold should be visible in the incident evidence alongside the authorized route count.

The accountability question is not whether a configuration contains a maximum-prefix statement. It is whether the threshold corresponds to the relationship contract, whether the response is safe, whether alarms are owned, and whether a replay proves containment.

Origin authorization and path authorization solve different problems

The Indosat event is a strong case for origin validation because AS4761 appeared as the origin for prefixes associated with many other networks. Where a valid ROA authorizes a different origin and a receiving network performs Route Origin Validation, the unexpected route can be classified invalid and rejected or de-preferred under policy.

RFC 6811 specifies BGP Prefix Origin Validation using RPKI. RFC 6483 provides guidance on origin validation operations. [10][11] Those documents explain the mechanism but do not prove the relevant 2014 coverage, ROA state, validator availability, or routing policy of Indosat's neighbors.

Three limitations need to remain explicit.

First, RPKI coverage in 2014 was limited. A route without a covering ROA is not automatically invalid; it is generally "not found." Present-day ROA state must not be projected back onto the event.

Second, origin validation checks the relationship between a prefix and its origin ASN. It does not validate every AS-path relationship. A route can have an authorized origin and still leak through an unintended provider, peer, or customer path.

Third, validation only changes routing when operators deploy validators, maintain cache availability, attach policy, and decide how to treat each state. A registry record does not enforce itself.

RFC 9234 later introduced BGP Roles and the Only-to-Customer attribute to improve route-leak prevention through explicit relationship signaling. [12] Again, it is a modern control comparison, not a description of the 2014 network. Roles and OTC can help routers detect announcements that violate valley-free relationship expectations, but they depend on deployment and correct role configuration.

The defensible architecture layers controls:

resource and origin records for expected authority;
prefix and origin filters at customer boundaries;
route-origin validation where data exists;
relationship-aware import and export policy;
BGP Roles and OTC where supported;
maximum-prefix and route-delta containment;
explicit default policy;
independent anomaly monitoring; and
tested coordination and withdrawal.

No single control should be presented as a complete solution. The accountability objective is defense in depth with evidence that each layer addresses a defined failure mode.

Registries are accountability ledgers, not reachability sovereigns

Internet number registries, routing registries, ROAs, and operator databases are essential evidence surfaces. They help identify resource holders, origin authority, contacts, and expected policy. RIPEstat's AS4761 view provides a present-day interface to registration and routing observations, while historical analysis must bind claims to the relevant time. [4]

These records do not determine running reachability by declaration. A router accepts, rejects, selects, and exports routes according to deployed software and configuration. An accurate registry can coexist with a permissive filter. An inaccurate or stale registry can cause a generated filter to reject legitimate routes. A signed ROA can classify an origin, but only a validating network's policy determines the operational result.

This distinction supports a reality-based accountability model. Registries should be evaluated as ledgers:

Are resource and contact records accurate?
Are changes recorded and attributable?
Can operators derive filters reproducibly?
Are exceptions visible?
Is security metadata current?
Can another network verify the expected origin?

Routers and policy systems should be evaluated as running enforcement:

Was the derived policy actually deployed?
Which version ran on the affected session?
Did it default to reject?
Did the device accept the abnormal set?
Did onward export preserve or amplify the error?
Did the running state match the ledger-derived intent?

The April 2014 event cannot be explained solely as a registry problem or solely as a router problem. It exposed the seam between recorded authority and executable policy. If records were accurate but filters were absent, the enforcement failed. If policy generation relied on inaccurate records, both the ledger and its operational use need correction. If broad redistribution bypassed the intended data path, deployment controls failed.

The evidence needed to distinguish these cases is not exotic. It includes dated resource records, policy source data, generated filters, configuration hashes, received and advertised routes, and independent collector observations. The absence of such a joined record is itself an accountability finding.

Collector evidence proves selected observations, not universal convergence

RIPE RIS and RouteViews preserve historical BGP data that makes independent reconstruction possible. RIPE describes RIS as a measurement system that collects and stores Internet routing data. RouteViews archives April 2014 updates. [5][6] CAIDA's BGPStream provides a framework for processing BGP data from major collection projects. [18]

These systems are accountability infrastructure because they preserve evidence outside the network that caused or propagated an incident. They allow analysts to test whether an abnormal origin appeared, which AS paths carried it to particular peers, when withdrawals became visible, and whether expected origins returned.

Their limits should be part of every claim.

A collector sees routes exported by its peers. It does not see every route those peers received or every alternative they considered. A first-seen timestamp is the first observation at that collector, not necessarily the first announcement at the source. A withdrawal observed at one peer does not prove global convergence. A best path visible at a collector does not prove the forwarding path from every user.

Collector diversity improves confidence. An incident reconstruction should compare RIS and RouteViews peers in different networks and regions. It should identify whether the abnormal origin was visible from each vantage point, how long it remained visible, which paths carried it, and when the expected origin returned. Differences should be preserved rather than averaged away.

The analysis also needs a reproducible predicate. For this event, an analyst might identify updates in which AS4761 is the origin for prefixes outside its expected set. The exact expected-set source, time, address family, duplicate handling, and path normalization should be documented. Derived route counts should link back to raw archive intervals or commands.

Research systems such as BGPInspector show how historical events can be examined through multiple dimensions and evidence views. [15] Later academic work on route leaks and detection further demonstrates that classification depends on topology, relationships, and observation. [16] These tools do not replace operator telemetry, but they make independent challenge possible.

An operator closeout should therefore pair internal and external evidence. Internal received and advertised routes explain what crossed a session. External collectors show what escaped into the wider routing system. The two records should converge on a bounded timeline while retaining vantage-point uncertainty.

Impact must be measured as reachability, not inferred from route volume

RIPE NCC's reconstruction showed that effects varied by vantage point and route. BGPMon reported that many abnormal routes were visible through providers in Thailand and that some propagated more broadly. [1][2] This supports a finding of uneven propagation and reachability impact.

It does not support a claim that the event redirected most global Internet traffic through Indonesia. A count approaching the size of the global table can sound equivalent to control over the Internet, but routing decisions are distributed. Networks apply local preference, AS-path policy, prefix specificity, origin validation, and business relationships. Some retain an unaffected route; some prefer the abnormal origin; some never receive it.

Impact should be measured in layers:

Control-plane visibility: Which collectors and peers saw AS4761 as an unexpected origin?

Route selection: Which networks selected the path, where that information is observable?

Forwarding evidence: From which source locations did traceroute, looking-glass, or flow data show traffic following a changed path?

Service performance: Which destinations experienced loss, latency, instability, or no observable degradation?

User scope: Which customers, regions, or services were affected, based on provider telemetry rather than route count alone?

Security consequence: Was there evidence of packet access, inspection, or alteration? The public route record alone does not establish it.

This layering prevents both exaggeration and minimization. It avoids treating every visible prefix as a globally installed forwarding path. It also avoids dismissing the incident because some networks maintained reachability.

For future events, operators should preserve active measurements, routing tables, flow summaries, application health, and customer-impact data with synchronized timestamps. The methodology should account for asymmetric paths, hidden hops, anycast, load balancing, and incomplete geolocation.

The key accountability measure is not the largest plausible affected population. It is whether each operator can connect an abnormal route state to concrete reachability effects, explain the uncertainty, and show how its controls limited or failed to limit propagation.

Monitoring has value only when it is tied to action

The event was visible to external monitors because the origin change and route volume were extraordinary. Public systems and operator communities helped surface the anomaly. That visibility does not by itself contain a route leak.

Monitoring should connect four elements:

a baseline defining expected origins, prefixes, paths, and route volume;
a detection rule explaining why the observed state is abnormal;
an owner with authority and contact paths; and
a safe action that can contain or withdraw the route.

An alert saying "AS4761 originated 417,038 new prefixes" is useful for triage. An operational alert should add the affected sessions, received and accepted counts, expected inventory, observed upstreams, current policy version, recent changes, and a recommended containment action.

Alert timing should be preserved. A complete timeline distinguishes first abnormal update, first collector observation, first automated alert, first human acknowledgement, first contact with the source or upstream, first containment action, first withdrawal, and later normalization. These timestamps reveal whether the delay was detection, escalation, authority, diagnosis, or convergence.

Coordination data also matters. Routing incidents cross organizational boundaries. Contacts must be current, reachable, and empowered. MANRS treats global validation and coordination as a core operator responsibility. [14] A contact record that exists but does not reach an operational owner is not a functioning control.

Automation can accelerate containment but needs guardrails. An automatic session shutdown based on a false positive can create an outage. A fail-open alert can allow a full-table leak to propagate while humans investigate. A bounded design can quarantine new routes, freeze changes, lower preference, or require confirmation under defined thresholds.

The event therefore tests more than anomaly detection. It tests whether observation becomes accountable action quickly enough to matter.

Withdrawal begins recovery; it does not prove closure

Public accounts indicate that the abnormal origins were withdrawn after several hours and that route state moved back toward expected origins. [1][2] Withdrawal is essential, but it is only the beginning of a recovery record.

BGP convergence is observer-specific. Networks receive and process withdrawals at different times. Some may retain stale routes, alternate abnormal paths, or session state longer than others. Route flap damping, session resets, local policy, and collector visibility can alter the apparent end time.

A credible recovery record should show:

the exact route set targeted for withdrawal;
the command, policy change, or session action used;
who authorized it;
when affected neighbors received it;
when internal received, selected, and advertised route counts normalized;
when multiple independent collectors stopped seeing AS4761 as the unexpected origin;
when expected origins reappeared;
which residual exceptions remained; and
whether user-facing reachability recovered on the same timeline.

The record should separate route withdrawal from configuration repair. An operator can withdraw bad routes manually while leaving the failure mechanism intact. Conversely, a configuration change can be correct locally while stale or alternative routes remain visible elsewhere.

Recovery also needs a known-good baseline. "Normal" should mean a checksum-bound authorized origin and path state, not merely the absence of a current alarm. If the authorized set changed during the incident, the change should be documented rather than hidden inside the closeout.

Independent evidence is particularly valuable because it checks claims outside the source network. RIS, RouteViews, looking glasses, and affected operators can show whether abnormal origins disappeared from different vantage points. Their observations will not be perfectly simultaneous, and that variance should be part of the record.

The public record does not provide a complete signed remediation report, route replay, or exception inventory for the 2014 event. The absence does not prove that no remediation occurred. It means outsiders cannot verify the durability of remediation from the available evidence.

A recurrence test should reproduce the failure class without exporting it

The strongest closeout is a controlled recurrence test. It does not send hundreds of thousands of unauthorized routes to the public Internet. It recreates the failure class in a lab, policy simulator, route-replay system, or isolated session and proves that every intended boundary responds correctly.

The test should begin with a frozen expected set for the AS4761 relationship. It should then introduce:

one unauthorized origin;
a small batch of unauthorized prefixes;
a full-table-scale set;
a gradual increase designed to evade a sudden-spike detector;
a path that violates the documented relationship;
an expired exception;
a missing explicit policy;
a stale registry or customer record; and
a withdrawal followed by attempted reannouncement.

For each case, the record should show the generated filter, candidate configuration, device or simulator result, alert, owner acknowledgement, containment behavior, and evidence exported to independent monitoring.

The test should run at both source and neighbor boundaries. The exporter should reject or prevent unauthorized advertisement. The direct neighbor should reject or quarantine a set that crosses bilateral scope. Onward-export policy should prevent accepted diagnostic routes from spreading further.

Negative controls are important. The system must continue to accept legitimate customer growth, authorized backup paths, and documented maintenance changes. Otherwise, a strict filter can become an availability risk and operators will bypass it.

The recurrence test should be rerun when routing inventory, policy generators, router software, topology, or relationships change. A passing test in one environment does not prove that every production session remains protected.

This approach changes the accountability question from "did the operator promise to be careful?" to "can the operator reproduce the failure and show that its current running controls contain it?"

Modern controls should be used as comparisons, not retroactive claims

Several standards and operational frameworks published before or after 2014 provide a useful control map.

RFC 7908 defines route-leak categories and terminology. [7] Its taxonomy helps separate unintended propagation from origin hijacking, but applying a specific leak type requires knowledge of relationships that may not be public.

RFC 8212 promotes explicit eBGP import and export policy. [8] It addresses the dangerous default in which routes flow when intended policy is missing.

RFC 7454 describes BGP security practices including filters, maximum-prefix, bogon handling, and operational protections. [9]

RFC 6811 and RFC 6483 address route-origin validation through RPKI. [10][11] They help test whether an origin is authorized but do not establish full path appropriateness.

RFC 9234 adds BGP Roles and OTC to support route-leak prevention through relationship signaling. [12]

NIST SP 800-189 frames resilient interdomain traffic exchange around filtering, RPKI, monitoring, security, and coordination. [13]

MANRS identifies operator actions for filtering, anti-spoofing, coordination, and global validation. [14]

Research and measurement tools add independent analysis. BGPInspector illustrates multidimensional incident inspection, later route-leak research examines detection and classification, RIPEstat connects registration and routing views, and BGPStream supports reproducible processing. [15][16][17][18]

The historical discipline is essential: these documents do not prove what Indosat or its neighbors had deployed on 2 April 2014. Some controls were immature, uncommon, or not yet standardized. A modern comparison can identify what would reduce recurrence now without rewriting history.

The layered control objective is stable across time: define authority, restrict export, validate import, constrain relationship scope, detect abnormal volume, preserve independent evidence, coordinate response, withdraw safely, and test recurrence.

Accountability should be allocated by boundary, not diluted across the Internet

Interdomain incidents involve many networks, which can make responsibility appear collective and therefore vague. A better model assigns duties according to control.

Indosat / AS4761 controlled origin and export state. Its evidence burden includes the authorized origin set, policy source, generated and running configuration, change record, advertised routes, withdrawal action, and recurrence test.

Direct neighbors controlled first external acceptance. Their burden includes relationship documentation, prefix and origin filters, maximum-prefix thresholds, import policy, onward-export policy, alert handling, and evidence of containment.

Further autonomous systems controlled their own acceptance, preference, propagation, monitoring, and customer communication. They may have had less specific relationship information, but they still owned their running policy.

Number and routing registries controlled the accuracy, availability, and auditability of resource and policy records within their scope. They did not control router enforcement.

Monitoring operators and researchers controlled measurement quality, timestamping, retention, methodology, and the boundaries of public claims. They could expose the event but not withdraw routes.

Service and access providers controlled resilience, path diversity, impact measurement, and communication to customers affected through their networks.

Customers and end users generally had no practical control over interdomain route acceptance. They should not bear the burden of discovering or repairing a provider's policy failure.

This allocation avoids two errors. It prevents the source operator from treating downstream propagation as someone else's problem. It also prevents other networks from claiming that any route received from a neighbor is solely the originator's responsibility.

The first preventable boundary deserves particular attention. If the exporter could have stopped the route, its failure is primary. If a direct neighbor had an expected route contract and accepted a full table anyway, that was a separate containment failure. If onward networks could detect an implausible path or volume and did not, their controls also require examination.

Distributed control creates multiple duties, not no duty.

Governance should require evidence without pretending private topology is public

Some routing evidence is necessarily private: contracts, full configurations, topology, security controls, and customer details. Accountability does not require indiscriminate disclosure. It requires enough independently verifiable evidence to support claims about control and recovery.

Operators can publish or share bounded attestations:

the expected route-count range without revealing every customer;
hashes of authorized inventories and generated filters;
confirmation that explicit import and export policy is attached;
maximum-prefix warning and hard-limit behavior;
timestamps of alerts, containment, and withdrawal;
independent collector references;
test results for full-table and relationship-violation replay;
the number and type of exceptions;
the owner and expiry process for those exceptions; and
a statement of unresolved evidence gaps.

Regulators, customers, peers, and insurers should ask for these artifacts rather than broad assurances. Contract language can require notification, evidence retention, route-policy testing, current contacts, and coordinated containment.

Disclosure should distinguish facts, inferences, and unknowns. For the Indosat event, the mass origin state and broad time interval are strong facts. A maintenance or filtering explanation is an attributed account. The exact internal mechanism and complete remediation remain unknown in the public record.

This format protects legitimate confidentiality while making operational claims challengeable. It also makes comparison possible across incidents. An operator that can provide a reproducible route-set diff and replay result has stronger evidence than one that offers only a root-cause label.

Governance should not turn registries into imagined central authorities over routing. Number records, ROAs, IRR objects, and contacts are critical inputs. Reachability remains the result of distributed running policy. Effective oversight therefore tests the connection between recorded authority and deployed behavior.

The April 2014 event was a full-table control test

The most durable lesson from the AS4761 event is not that BGP is based on trust or that one operator made a large error. Those statements are too general to assign a repair.

The event tested whether a network could prevent an unauthorized full-table-scale origin set from leaving its boundary. It tested whether direct neighbors could compare received routes with a bilateral expectation and contain a radical departure. It tested whether onward networks could avoid amplifying the state. It tested whether monitors could provide precise, observer-bound evidence. It tested whether withdrawal and normalization could be proved rather than asserted.

The public evidence establishes that more than 400,000 unexpected origins associated with AS4761 became visible on 2 April 2014 and were withdrawn after several hours. It supports uneven propagation and reachability effects. It does not establish malicious intent, universal forwarding, one complete internal cause, or a publicly verifiable remediation program.

An accountable operator response would close those gaps with:

a frozen authorized prefix and origin inventory;
explicit default-reject import and export policy;
generated prefix and origin filters;
relationship-aware path controls;
maximum-prefix warning and hard containment;
route-origin validation where relevant data exists;
controlled exceptions with owners and expiry;
independent multi-vantage monitoring;
a timestamped containment and withdrawal record; and
a replay proving that the same failure class is rejected at source and neighbor boundaries.

The standard is not perfection. Interdomain routing is distributed, relationships change, records can lag, and visibility is incomplete. The standard is whether each operator can identify the boundary it controls, show what policy ran there, explain what departed from expectation, act within a tested process, and provide evidence that authorized route state returned.

That is the difference between an incident that merely ends and an incident that produces accountability.