The Indosat BGP Route Leak (2014)

On April 2, 2014, the Indonesian telecommunications provider Indosat (AS4761) leaked approximately 417,000 BGP routes to its external peers. For roughly two hours, Indosat's network advertised more-specific prefixes for a vast swath of the internet's address space, causing routers worldwide to redirect traffic through its infrastructure in Jakarta. It was one of the largest route leaks in history by raw prefix count, and it laid bare a category of risk that the routing community had been warning about for years: the uncontrolled use of BGP route optimizers.

What Happened

Indosat used a commercial product called Noction Intelligent Routing Platform (IRP), a BGP optimizer designed to improve outbound traffic engineering. BGP optimizers work by taking the routes a network learns from its upstream transit providers, splitting them into more-specific prefixes (e.g., breaking a /16 into two /17s), and re-injecting those more-specific routes into the network's internal BGP (iBGP) to steer traffic toward the best-performing upstream link.

This is a legitimate technique when used correctly. The critical requirement is that these optimized, more-specific routes must never leak to external peers. They are internal traffic engineering artifacts, not routes that should be announced to the rest of the internet. Indosat's configuration failed to enforce this boundary.

On April 2, the internal routes generated by the Noction optimizer were exported to Indosat's external eBGP sessions. In an instant, Indosat began announcing approximately 417,000 prefixes to its upstream providers and peers. These were more-specific versions of routes from across the global routing table, covering networks on every continent.

Why More-Specific Routes Are So Dangerous

The internet's routing system follows a simple rule: the most specific prefix always wins. This is the longest prefix match rule, and it is fundamental to how BGP forwarding decisions work.

Suppose a legitimate network announces 203.0.113.0/16 via BGP. If another network announces 203.0.113.0/17 and 203.0.113.128/17, those two /17 routes are more specific than the /16. Every router on the internet will prefer the /17s over the /16, because they are a more precise match for the destination address. The original /16 announcement becomes effectively invisible for all traffic covered by the more-specific routes.

This is exactly what Indosat's optimizer did. It took large prefixes learned from transit providers and split them into smaller, more-specific chunks for internal traffic engineering. When those more-specific routes leaked externally, they overrode the original, legitimate announcements. Routers worldwide began forwarding traffic toward Indosat as if it were the best path to those destinations.

The Scale of the Leak

To appreciate the magnitude: in April 2014, the global BGP routing table contained approximately 500,000 IPv4 prefixes. Indosat leaked roughly 417,000 additional more-specific routes. This means the leak generated an announcement volume equivalent to about 83% of the entire global routing table.

The leaked prefixes covered networks belonging to organizations across the world. Traffic destined for major providers in North America, Europe, and Asia was suddenly being pulled toward a single Indonesian ISP's infrastructure. Indosat's network was not designed to handle this volume of global transit traffic, so the result was severe congestion, packet loss, and unreachability for affected destinations.

The Role of Noction IRP

Noction Intelligent Routing Platform is a commercially available BGP optimizer used by ISPs and enterprises worldwide. Its purpose is straightforward: monitor the performance of routes learned from multiple upstream providers and shift outbound traffic to the best-performing path. It does this by injecting more-specific routes into the network's iBGP, causing the router to prefer the optimized path over the default.

The Noction product itself was not inherently flawed. The problem was operational: Indosat's configuration failed to prevent these internally generated routes from being redistributed to eBGP sessions. Proper deployment of a BGP optimizer requires strict route filtering: all routes tagged or generated by the optimizer must be blocked from export to any external peer. This is typically enforced through a combination of:

• BGP communities — Tagging optimizer-generated routes with a specific community string and filtering on export
• Route maps / route policies — Explicit deny rules on all eBGP export policies for routes matching the optimizer's characteristics
• Prefix lists — Only permitting the announcement of the network's own legitimately held address space
• AS path filtering — Ensuring that only routes originated by the network itself (or its customers) are exported

Indosat either lacked these safeguards or had a misconfiguration that bypassed them. The result was that the optimizer's internal routes were treated as valid external announcements.

How the Leak Propagated

When Indosat's routers began sending 417,000 more-specific routes to their upstream transit providers and peers, those providers had to decide whether to accept or reject them. In an ideal world, every upstream provider would have had strict prefix limits configured on their BGP sessions with Indosat. A prefix limit is a safeguard that automatically tears down a BGP session if a peer sends more routes than expected. If Indosat normally announced a few hundred prefixes and suddenly sent 417,000, a properly configured prefix limit would have shut the session down within seconds.

But in 2014 (and to a lesser extent, still today), many transit providers did not enforce strict prefix limits on their customer sessions. Indosat's upstream providers accepted the flood of routes and propagated them further. From there, the routes spread through the global routing mesh like a chain reaction. Each transit provider that accepted the routes forwarded them to its own peers and customers, and within minutes the leaked routes were visible across much of the internet.

The Impact

The effects were felt across multiple dimensions:

Traffic Black-Holing

Indosat's infrastructure was designed to serve its Indonesian customer base, not to transit traffic for the entire internet. When routers worldwide began forwarding traffic through AS4761, the network's international links became saturated almost immediately. Packets arrived at Indosat's border routers but could not be forwarded to their actual destinations quickly enough, resulting in massive packet loss. For many affected prefixes, the practical effect was a black hole: traffic entered but never emerged.

Latency and Path Inflation

Even for traffic that did successfully transit through Indosat, the paths were absurdly suboptimal. Traffic between two networks in Europe might be routed from Europe to Indonesia and back again. The added latency of these circuitous paths broke time-sensitive applications and degraded user experience for anything that did manage to get through.

Cascading Congestion

The sudden redirection of massive traffic volumes did not just affect Indosat's network. The transit providers carrying traffic to and from Indosat also experienced elevated load on their links to Indonesia. Submarine cables and international interconnection points serving Southeast Asia saw unexpected traffic spikes, causing collateral congestion for uninvolved networks sharing those links.

Detection and Response

The leak was detected by BGP monitoring systems operated by organizations like RIPE RIS and BGPStream, as well as by network operators who noticed sudden route changes for their prefixes. The pattern was unmistakable: hundreds of thousands of new more-specific routes all appearing simultaneously from a single origin, AS4761.

Once identified, the response followed the standard incident procedure for route leaks:

1. Identification — Monitoring systems flagged the anomalous route announcements from AS4761
2. Contact — Network operators and the routing community reached out to Indosat's NOC (Network Operations Center) through operational mailing lists and direct communication channels
3. Mitigation at the source — Indosat corrected the misconfiguration and withdrew the leaked routes
4. BGP convergence — After the withdrawals were issued, routers worldwide gradually reconverged on the legitimate routes. Full convergence took additional time as withdrawals propagated across the global mesh

The total duration of the incident was approximately two hours from the initial leak to full withdrawal. However, due to BGP convergence delays, some networks continued to see the leaked routes for some time after Indosat issued the withdrawals.

Why Upstream Providers Did Not Stop It

A recurring question in the aftermath was: why did Indosat's upstream providers accept 417,000 routes from a customer that normally announced a few hundred? The answer reveals a systemic weakness in how BGP sessions are configured in practice.

The tools to prevent this existed in 2014 and exist today:

• Prefix limits — BGP supports configuring a maximum number of prefixes that will be accepted from a peer. If the limit is exceeded, the session is torn down. Most router vendors support this feature, but many operators do not configure it, or set it too high to be useful.
• IRR-based filtering — Internet Routing Registries (IRRs) document which prefixes an autonomous system is authorized to announce. Transit providers can generate prefix filters from IRR data and reject unauthorized announcements. In 2014, IRR-based filtering was inconsistently deployed.
• RPKI — Route Origin Authorization (ROA) records allow the holder of IP address space to cryptographically specify which AS is authorized to originate announcements for their prefixes. In 2014, RPKI deployment was in its earliest stages and provided essentially no protection.

The fundamental problem was that the internet's routing system operated largely on trust. Transit providers accepted whatever their customers announced, and the assumption was that customers would not send garbage. Indosat did not send garbage intentionally, but the effect was the same.

The BGP Optimizer Problem

The Indosat incident brought renewed attention to the risks of BGP optimizers. These tools are widely used in the industry. Their value proposition is real: for a multi-homed network buying transit from several providers, a BGP optimizer can measurably improve outbound performance by shifting traffic to the best-performing path in real time.

But the architectural pattern they rely on, injecting more-specific routes into the routing table, creates an inherent risk. If those routes leak, the consequences are catastrophic precisely because more-specific routes override everything else. The optimizer is, in effect, manufacturing a loaded weapon that must never be pointed outside the network.

The Indosat leak was not the first optimizer-related incident, nor would it be the last. The pattern recurs because:

• The optimizer generates routes that are indistinguishable from legitimate announcements once they escape the network
• The volume of routes generated is enormous (the optimizer creates more-specific versions of much of the routing table)
• A single misconfiguration, software bug, or human error in the export policy can release all of them at once
• The resulting leak is maximally damaging because every leaked route is more specific than the legitimate route it shadows

Lessons and Defenses

The Indosat leak reinforced several critical lessons for the internet routing community:

1. Prefix Limits Are Essential

Every eBGP session should have a maximum prefix limit configured. If a customer normally announces 200 prefixes, a limit of 300 or 500 would catch a leak of 417,000 routes instantly. This is the single most effective defense against route leaks and is trivial to implement on any router platform. Transit providers that do not enforce prefix limits are implicitly accepting the risk that their customers will one day flood them with garbage routes.

2. Defense in Depth for Route Filtering

No single filtering mechanism is sufficient. Best practice is to layer multiple defenses:

• Prefix limits as a circuit breaker
• IRR-based prefix filters to allow only authorized announcements
• RPKI Route Origin Validation to cryptographically verify origins
• AS path filters to reject routes with unexpected origin ASes
• Bogon and martian route filters to reject obviously invalid announcements

3. BGP Optimizers Need Strict Containment

Any network using a BGP optimizer must ensure that optimizer-generated routes are tagged with a well-known community and that all eBGP export policies explicitly deny routes carrying that community. This filtering must be tested, audited, and verified regularly. A configuration drift or a software upgrade that resets policies can release the routes.

4. RPKI Adoption Is Critical

In 2014, RPKI was too nascent to help. Today, with over 40% of global prefixes covered by ROAs and major networks performing Route Origin Validation, a similar leak would have a somewhat reduced impact. Networks performing ROV would reject leaked routes where the origin AS (AS4761) does not match the ROA for the prefix. However, RPKI alone is not a complete solution. It validates the origin AS but does not prevent route leaks where the AS path is plausible. Emerging standards like ASPA (Autonomous System Provider Authorization) aim to close this gap by allowing ASes to declare their authorized upstream providers, enabling detection of unauthorized route propagation.

5. Monitoring and Rapid Response

BGP monitoring services like RIPE RIS, BGPStream, and commercial platforms provide near-real-time visibility into routing changes. Networks should monitor their own prefixes for unauthorized announcements and have runbooks for responding to hijacks and leaks. The two-hour duration of the Indosat leak, while disruptive, was relatively short because monitoring systems detected it quickly and the community mobilized a response.

The Indosat Leak in Context

The Indosat incident is one of several major BGP routing incidents that have shaped how the internet community thinks about routing security. While BGP hijacks like the 2008 Pakistan-YouTube incident involve announcing prefixes owned by someone else, route leaks like Indosat's involve propagating legitimate routes in unauthorized directions. The distinction matters technically, but the impact is similar: traffic ends up where it should not be.

Other notable route leak incidents include:

• 2019: Verizon/Allegheny/DQE — A small Pennsylvania ISP leaked routes from Allegheny Technologies through DQE Communications to Verizon, causing traffic for Cloudflare, Amazon, and others to funnel through a small regional network. The leak was also caused by a Noction BGP optimizer, making it a near-exact repeat of the Indosat pattern five years later.
• 2017: Google/Japan — Google accidentally leaked internal routes to Japanese transit providers, causing significant disruption to Japanese internet connectivity for roughly an hour.
• 2015: Telekom Malaysia — Telekom Malaysia (AS4788) leaked over 179,000 prefixes, causing traffic for services worldwide to be routed through Malaysia.

The recurrence of these events demonstrates that route leaks are not edge cases but a structural vulnerability in the internet's routing architecture. As long as BGP operates on trust and filtering is optional, leaks will continue to happen. The trend toward mandatory RPKI validation, tighter prefix limits, and emerging standards like ASPA offers hope, but the transition is slow and adoption remains uneven.

Indosat Today

Indosat (now Indosat Ooredoo Hutchison after a 2022 merger) continues to operate as one of Indonesia's largest telecommunications providers under AS4761. The company tightened its BGP export policies following the 2014 incident and, like most major carriers, has improved its routing hygiene over the past decade. You can look up Indosat's current BGP presence and see its announced prefixes, upstream providers, and peers.

Explore the Routing Data

Use the looking glass to examine the networks involved in this incident and see real-time BGP routing data:

• AS4761 — Indosat's autonomous system: see its current announced prefixes and neighbors
• AS4788 — Telekom Malaysia, involved in a similar 2015 leak
• AS15169 — Google, whose 2017 Japan leak disrupted connectivity
• AS13335 — Cloudflare, affected by the 2019 Verizon/Allegheny leak

Understanding how route leaks happen is essential for anyone operating a network. Explore the BGP fundamentals, learn about RPKI and how it helps prevent these incidents, and look up any autonomous system to see its routing posture today.