The Telekom Malaysia BGP Route Leak (2015)

On June 12, 2015, Telekom Malaysia (AS4788) accidentally leaked approximately 179,000 BGP prefixes to its upstream transit provider Level3 Communications (AS3549). For several hours, a significant portion of global internet traffic was funneled through Malaysia's comparatively limited infrastructure, causing severe packet loss and latency spikes for users worldwide. The incident remains one of the five largest BGP route leaks in history and a stark demonstration of how a single misconfiguration in one country can ripple across the entire internet.

What Happened

Telekom Malaysia is the largest telecommunications provider in Malaysia, operating AS4788. Like most large ISPs, it maintains a full BGP routing table internally -- receiving routes from its transit providers, peers, and customers. Under normal operation, Telekom Malaysia should only announce its own prefixes and its customers' prefixes to its upstream providers. The full routing table it receives from peers and transit providers should never be re-announced outward.

On June 12, 2015, a configuration error caused Telekom Malaysia to re-announce its entire internal routing table -- roughly 179,000 prefixes -- to Level3 Communications (AS3549), one of the world's largest Tier 1 backbone providers. In effect, Telekom Malaysia told Level3: "I can provide transit to all of these 179,000 networks." Level3's routers, lacking sufficient inbound prefix filters on the session with Telekom Malaysia, accepted these routes and propagated them to the rest of the internet.

Within minutes, routing tables worldwide began to shift. Networks that previously routed traffic directly or through optimal paths now saw a route through AS4788 as a viable -- and in some cases preferred -- option. Traffic destined for major networks in North America, Europe, and Asia was suddenly detoured through Telekom Malaysia's infrastructure in Southeast Asia.

Understanding the Mechanism: What is a Route Leak?

A route leak is fundamentally different from a BGP hijack. In a hijack, a network falsely claims to originate prefixes it does not own -- it forges the origin AS. In a route leak, the routes themselves are technically legitimate: the origin AS is correct, the AS paths are real. The problem is that the routes are being propagated in a direction they should not be.

BGP routing relationships follow a strict hierarchy defined by commercial agreements:

• Customer routes -- A network announces its own prefixes and its customers' prefixes to everyone (upstream providers, peers, and other customers). This is how the network gets paid.
• Peer routes -- Routes learned from a settlement-free peer should only be announced to customers, never to other peers or upstream providers.
• Provider routes -- Routes learned from an upstream transit provider should only be announced to customers, never to other providers or peers.

Telekom Malaysia violated this hierarchy. It took routes learned from its providers and peers -- the entire global routing table -- and re-announced them to Level3, its upstream transit provider. This made Telekom Malaysia appear to be a transit provider for the entire internet, rather than a customer network.

Why Level3 Accepted the Routes

The critical amplifying factor in this incident was Level3's failure to apply adequate inbound filters on its BGP session with Telekom Malaysia. In the provider-customer relationship between Level3 and Telekom Malaysia, Level3 should have limited the number and scope of prefixes it would accept from AS4788. Standard best practices include:

• Prefix limit -- Setting a maximum number of prefixes that can be received from a customer. Telekom Malaysia might legitimately announce a few hundred prefixes. A sudden jump to 179,000 should have triggered an automatic session teardown.
• Prefix list filtering -- Only accepting prefixes that are documented in routing registries (IRR) as belonging to the customer or its downstreams.
• AS path filtering -- Only accepting routes whose AS paths begin with the customer's ASN and contain only known downstream ASNs.
• RPKI-based filtering -- Rejecting routes whose origin AS does not match a valid Route Origin Authorization (ROA).

Level3, as a Tier 1 provider with global reach, had the ability to propagate these leaked routes worldwide. When it accepted and redistributed Telekom Malaysia's 179,000 prefixes, the leak went from being a local misconfiguration to a global routing incident. Every network that received these routes from Level3 saw a seemingly valid path through AS3549 and AS4788 to destinations across the internet.

The Impact

The consequences were immediate and severe. Telekom Malaysia's international links, designed to carry traffic for a single country's ISP, were suddenly expected to carry transit traffic for tens of thousands of networks around the world. The results were predictable:

Massive Packet Loss

Telekom Malaysia's international capacity was nowhere near sufficient to handle the redirected traffic. Links became saturated almost instantly. Packet loss rates spiked to 30-60% or higher for traffic that was being routed through Malaysia. Services that had been running smoothly became unreliable or completely unreachable for users whose traffic was affected.

Latency Increases

Even for packets that made it through, the added latency was enormous. Traffic between two networks in, say, the US East Coast that would normally traverse a direct path with 20ms latency was now being routed from North America across the Pacific to Malaysia and back -- adding hundreds of milliseconds of round-trip time. For latency-sensitive applications like VoIP, video conferencing, and online gaming, this made services unusable.

Asymmetric Routing

The leak created severe asymmetric routing conditions. The forward path (from source to destination) might go through Malaysia, while the return path followed the normal route. This asymmetry broke many applications that depend on consistent latency in both directions, and it made the problem difficult to diagnose because standard tools like ping and traceroute only show the forward path.

Duration and Scope

The leak persisted for several hours before it was identified and corrected. During that window, any network that selected the leaked routes -- which included many networks worldwide -- experienced degraded connectivity to the affected prefixes. The 179,000 leaked prefixes represented a substantial fraction of the approximately 550,000 prefixes in the global IPv4 routing table at the time, meaning the impact was not limited to a few unlucky networks but was broadly felt.

Timeline of Events

The incident followed a pattern typical of major route leaks:

1. The misconfiguration -- Telekom Malaysia's routers began exporting the full routing table to Level3. The exact cause of the misconfiguration was never publicly disclosed, but common triggers include software upgrades, configuration changes to BGP export policies, or human error during maintenance windows.
2. Propagation -- Level3 accepted the 179,000 prefixes and redistributed them to its peers and customers worldwide. Within minutes, the leaked routes had propagated across most of the internet's routing table.
3. Detection -- Network operators and BGP monitoring services began detecting anomalies. The sudden appearance of AS4788 in the AS path of tens of thousands of routes was highly unusual. BGP monitoring platforms like BGPStream, RIPE RIS, and the RouteViews project recorded the event.
4. Diagnosis and response -- Engineers at Level3 and Telekom Malaysia were alerted. The fix required either Telekom Malaysia to correct its export policy or Level3 to tear down the BGP session and filter the leaked routes.
5. Recovery -- Once the leaked routes were withdrawn, BGP convergence began. Networks around the world reverted to their normal routing paths. Full convergence took additional time as BGP update messages propagated and routing tables stabilized.

Anatomy of the AS Path During the Leak

During the leak, the AS path for affected prefixes revealed the problem clearly. Consider a prefix normally originated by Google (AS15169). Before the leak, a typical AS path might look like:

2914 15169

This shows a direct route through NTT (AS2914) to Google. During the leak, an alternative path appeared:

3549 4788 ... 15169

The presence of AS4788 (Telekom Malaysia) in the path of a route to Google was the telltale sign. Telekom Malaysia had no business being in the transit path for Google's prefixes. Any network operator who examined their routing table during the incident would have seen AS4788 suddenly appearing in the paths of thousands of unrelated routes -- a clear indicator of a route leak.

Whether a given network actually used the leaked path depended on BGP's path selection algorithm. If the path through AS4788 happened to be shorter (in AS hop count) or was preferred due to local preference settings, the network would shift traffic to the leaked route. Many networks did, because Level3's position as a Tier 1 provider meant the leaked paths often appeared competitive in hop count.

Why Route Leaks Are So Dangerous

The Telekom Malaysia incident highlights several properties of route leaks that make them particularly damaging:

They are hard to detect automatically

Unlike a BGP hijack where the origin AS changes (which RPKI can catch), route leaks preserve the correct origin AS. The prefix 8.8.8.0/24 still shows AS15169 as the origin -- it is just arriving via an unexpected transit path. RPKI Route Origin Validation would mark these routes as "valid" because the origin AS is correct. The problem is purely in the transit path.

They exploit the trust model

BGP's provider-customer trust model assumes that a customer will only announce routes it is authorized to transit. There is no cryptographic mechanism in production BGP today that enforces this -- it relies entirely on correct configuration and diligent filtering by upstream providers.

They scale with the leaker's upstream

The blast radius of a route leak depends on who the leaker's upstream provider is. Telekom Malaysia's leak would have been far less damaging if its upstream were a small regional provider with limited connectivity. But because Level3 was a Tier 1 network with global reach, the leaked routes were propagated everywhere. The bigger the upstream, the bigger the damage.

They cause congestion, not just misdirection

Hijacks can redirect traffic to a black hole or an attacker's server. Route leaks cause a different problem: they funnel traffic through infrastructure that was never designed to carry it. The result is congestion, packet loss, and latency -- affecting all traffic through the leaker, including the leaker's own legitimate users.

Defenses That Could Have Prevented the Leak

Multiple layers of defense, if properly implemented, could have prevented or mitigated this incident:

Prefix Limits (Maximum Prefix Setting)

The simplest defense. If Level3 had configured a maximum prefix limit on its BGP session with Telekom Malaysia -- say, 1,000 prefixes -- the session would have been automatically torn down the moment Telekom Malaysia tried to announce 179,000 prefixes. Most BGP implementations support this as a basic session parameter. This is a low-effort, high-impact protection that every transit provider should configure for every customer session.

IRR-Based Filtering

Internet Routing Registries (IRR) contain records of which ASes are authorized to announce which prefixes. Transit providers can generate prefix filters from IRR data to ensure they only accept routes that match documented allocations. If Level3 had applied IRR-based filters, it would have rejected the vast majority of the 179,000 leaked prefixes because they were not registered to Telekom Malaysia or its downstream customers.

RPKI and ROV

RPKI Route Origin Validation would not have directly prevented this leak, because the origin AS on the leaked routes was correct. However, RPKI does help reduce the set of routes that can be leaked by ensuring that only properly authorized origins are accepted. Future extensions to RPKI, such as ASPA (Autonomous System Provider Authorization), are specifically designed to detect and prevent route leaks by validating the provider-customer relationship in the AS path.

ASPA (Autonomous System Provider Authorization)

ASPA is an emerging standard (still in draft at the IETF as of 2025) that directly addresses route leaks. With ASPA, each AS publishes a signed list of its authorized upstream providers. Receiving networks can then verify that every provider-customer hop in the AS path is legitimate. If ASPA had been deployed in 2015, networks receiving the leaked routes would have seen that AS4788 was not an authorized provider for the networks whose routes it was transiting, and the routes would have been rejected.

Telekom Malaysia in Context: The Largest Route Leaks in History

The Telekom Malaysia incident is part of a pattern of major route leaks that have occurred over BGP's history. Each one exposed the same fundamental weaknesses:

• 2015 -- Telekom Malaysia (AS4788) -- 179,000 prefixes leaked to Level3. Several hours of global disruption.
• 2017 -- Google (AS15169) -- Google accidentally leaked prefixes to a Japanese peer, briefly redirecting traffic and causing outages in Japan.
• 2019 -- Allegheny Technologies / DQE / Verizon -- A small Pennsylvania ISP (AS33154) leaked 20,000+ prefixes to Verizon, which propagated them globally. Cloudflare, Amazon, and others were affected for hours.
• 2019 -- China Telecom (AS4134) -- Over 70,000 routes from European networks were rerouted through China for over two hours.
• 2020 -- Rostelecom (AS12389) -- Leaked prefixes belonging to Cloudflare, Amazon, Hetzner, and others, redirecting traffic through Russia.

The recurring theme is consistent: a customer network leaks routes to a major transit provider, the transit provider accepts them without adequate filtering, and the damage propagates globally. The Telekom Malaysia incident at 179,000 prefixes remains among the largest in terms of sheer volume of leaked routes.

Lessons for Network Operators

The Telekom Malaysia leak reinforced several operational best practices that remain critical today:

For Transit Providers

• Always set max-prefix limits on customer sessions. A customer announcing 10x their normal prefix count is almost certainly leaking. The session should be automatically shut down.
• Build and apply IRR-based prefix filters for every customer. Automate filter generation from IRR data (RADB, RIPE, ARIN, etc.) and update regularly.
• Deploy RPKI ROV and reject RPKI-invalid routes. While ROV does not catch leaks, it prevents hijacks and reduces the set of routes available to be leaked.
• Monitor BGP sessions for unusual prefix count changes. Alerting on sudden spikes can catch leaks before they cause widespread damage.

For Customer Networks

• Use explicit export policies -- never rely on default behavior. Every prefix announced to an upstream should be explicitly permitted by policy.
• Apply outbound prefix lists that restrict what you announce to only your own prefixes and your customers' prefixes.
• Test configuration changes in a staging environment when possible. Many leaks are triggered by configuration changes during maintenance.
• Register your routes in IRR so your upstream providers can build accurate filters.

The State of Route Leak Prevention Today

A decade after the Telekom Malaysia incident, the internet's defenses against route leaks have improved but remain incomplete. RPKI adoption has grown significantly -- over 40% of global prefixes now have valid ROAs, and major networks like Cloudflare, Google, and Amazon enforce ROV. However, RPKI only validates origin, not the transit path.

ASPA, which would directly prevent route leaks, is still in the standardization process. RFC 9582 (published 2024) defines the ASPA profile, and several large networks have begun experimental deployment. Full adoption is likely years away.

In the meantime, the internet relies on the same operational practices that failed in June 2015: prefix limits, IRR filters, and manual monitoring. Some transit providers have tightened their filtering significantly since these high-profile incidents. Others have not. The next major route leak is not a question of "if" but "when" -- and the outcome will depend on whether the transit provider accepting the routes has learned from incidents like this one.

Explore the Networks Involved

Use the looking glass to examine the networks involved in the 2015 Telekom Malaysia route leak and see their current routing posture:

• AS4788 -- Telekom Malaysia: see its current announced prefixes and upstream providers
• AS3549 -- Level3 / CenturyLink (now Lumen): one of the world's largest transit providers
• AS3356 -- Lumen Technologies: Level3's successor AS
• AS15169 -- Google: one of many networks whose traffic was affected
• AS13335 -- Cloudflare: a leader in RPKI deployment and route leak prevention

You can also look up any IP address or ASN to check its current BGP routes, AS paths, and RPKI validation status. Understanding how routes propagate -- and how they can go wrong -- is the first step toward building a more resilient internet.