The Telia-Verizon AS Path Leak (2019)

On June 24, 2019, a small Swiss hosting provider called Safe Host (AS21217) made a configuration error that would ripple across the entire internet. Safe Host leaked its full routing table -- over 70,000 prefixes -- to its transit provider Telia (AS1299), one of the world's largest Tier 1 networks. Telia accepted every one of those routes without filtering, propagated them to Verizon (AS701), and Verizon in turn broadcast them globally. For roughly three hours, traffic destined for major networks like Cloudflare, Amazon AWS, and dozens of other providers was funneled through a company with a fraction of the capacity needed to handle it.

This incident was not an isolated accident. It was part of a cluster of BGP routing failures in 2019 that exposed deep, systemic weaknesses in how the internet's largest networks handle route filtering -- and it became a catalyst for the routing security reforms that followed.

What Is a Route Leak?

A route leak is distinct from a BGP hijack. In a hijack, a network falsely claims to originate prefixes it does not own. In a route leak, a network re-announces legitimate routes it has learned from one provider to another provider in violation of the intended routing policy. The AS paths remain valid -- the origin AS is still correct -- but the routes are propagated through an unauthorized path.

RFC 7908 defines a route leak as "the propagation of routing announcement(s) beyond their intended scope." In the customer-provider-peer model that governs internet peering, a customer network should only announce its own prefixes (and those of its own customers) to its transit providers. When a customer accidentally announces routes learned from Provider A to Provider B, those routes may suddenly appear as a shorter or equally viable path through the customer's network -- a network that was never designed to carry that traffic.

The Anatomy of the June 24, 2019 Leak

The chain of failure involved three autonomous systems and unfolded in a matter of seconds:

1. Safe Host (AS21217), a small Swiss datacenter and hosting provider, experienced a configuration error -- likely an optimizer or route redistribution misconfiguration -- that caused it to export its entire BGP table to its upstream transit provider Telia. Under normal operation, Safe Host should have announced only its own small set of prefixes (a handful of /24s and /22s). Instead, it announced tens of thousands of prefixes belonging to networks all over the world.
2. Telia (AS1299), a major Tier 1 carrier (now called Arelion), accepted every one of these routes from its customer without filtering. In a properly configured transit relationship, Telia would have had a prefix filter on the customer session limiting Safe Host to only its registered prefixes. No such filter was in place. Telia then propagated these leaked routes to its peers and customers, including Verizon.
3. Verizon (AS701) accepted the leaked routes from Telia and propagated them globally. Because the leaked routes often had shorter or competitive AS paths when seen through Safe Host, routers around the world began preferring these new paths -- sending traffic for major cloud providers through Safe Host's limited infrastructure.

Why Filtering Failed at Every Level

The most striking aspect of this incident is not that Safe Host leaked routes -- misconfigurations happen constantly. The real failure is that two of the world's largest transit networks, Telia and Verizon, had no effective safeguards in place to stop it.

Customer Prefix Filtering

Best practice for any transit provider is to maintain a prefix filter on every customer BGP session. This filter, typically built from the customer's registered route objects in an Internet Routing Registry (IRR) database, specifies exactly which prefixes the customer is authorized to announce. If the customer sends anything else, the filter drops it.

Telia did not have an effective prefix filter on its session with Safe Host. When Safe Host suddenly began announcing 70,000+ prefixes instead of its usual handful, Telia's routers accepted them all. A simple max-prefix limit -- a configuration that shuts down a BGP session if the number of received prefixes exceeds a threshold -- would also have caught this. Telia apparently had neither mechanism in place for this customer, or the limits were set too high to be useful.

Peer Route Validation

Verizon, receiving these routes from Telia via a peer or transit relationship, also failed to filter. While peer filtering is more complex than customer filtering (peers exchange large route sets), Verizon could have used several mechanisms to detect and prevent the leak: RPKI origin validation, AS path filtering based on IRR data, or even basic anomaly detection based on the sudden appearance of thousands of new routes through an unexpected path.

None of these protections were triggered. Verizon accepted and propagated the leaked routes to the rest of the internet.

The Impact: Traffic Rerouted Through a Small ISP

The consequences were immediate and severe. Traffic destined for some of the internet's largest networks was rerouted through Safe Host's infrastructure -- a small hosting company with bandwidth capacity orders of magnitude smaller than what was suddenly being sent through it.

The effects included:

• Cloudflare (AS13335) -- Cloudflare reported that their traffic from Verizon's network was rerouted through Safe Host for roughly three hours. Cloudflare's CEO publicly called out Verizon's lack of route filtering.
• Amazon AWS (AS16509) -- Routes to AWS infrastructure were affected, potentially impacting thousands of websites and services hosted on AWS.
• Other major networks -- Any network whose prefixes were among the 70,000+ leaked routes could have experienced traffic detours, packet loss, or increased latency.

Because Safe Host did not have the capacity to handle a meaningful fraction of global internet traffic, much of the rerouted traffic was likely dropped or severely degraded. Users experienced this as slow-loading websites, connection timeouts, and outright unreachability for affected services.

The Broader 2019 Context: A Cascade of Routing Failures

The Telia/Verizon incident did not happen in isolation. June 2019 was a particularly bad month for BGP routing, and the year as a whole became a watershed moment for routing security awareness:

• June 24, 2019: The Safe Host leak -- The incident described in this article. Safe Host leaked routes through Telia and Verizon, impacting Cloudflare and other major networks.
• Earlier in 2019: China Telecom route leaks -- Traffic for European networks was rerouted through China Telecom's network, raising concerns about state-level traffic interception.
• November 2018: Google traffic rerouted through Nigeria and China -- A BGP leak involving a Nigerian ISP caused Google traffic to be rerouted through China Telecom and a Russian ISP, highlighting how leaks can chain through multiple networks.
• Ongoing through 2019: Numerous smaller leaks -- BGP monitoring services like BGPStream recorded hundreds of route leaks and anomalies throughout the year.

The Cloudflare-Verizon incident was particularly impactful because of Cloudflare's vocal public response. Cloudflare's CEO and CTO published detailed blog posts documenting how Verizon's lack of filtering caused the outage and publicly challenged Verizon to implement RPKI and proper route filtering. This brought unprecedented public attention to a problem that had historically been discussed only in network engineering circles.

How Route Leaks Differ from Hijacks in AS Path Analysis

When you examine a route leak in a BGP looking glass, the AS path reveals a distinctive pattern. Unlike a hijack -- where the origin AS changes to the attacker's ASN -- in a route leak the origin AS remains correct. The leaking network simply appears as an unexpected transit hop in the path.

During the Safe Host leak, an AS path to Cloudflare's prefix that normally looked like:

701 13335

might have instead appeared as:

701 1299 21217 <...> 13335

The origin was still AS13335 (Cloudflare), so RPKI origin validation would have returned Valid -- the originating AS was legitimate. This is a fundamental limitation of RPKI: it validates who originates a route, but not the path the route takes. The route was legitimate in origin but was being propagated through an unauthorized and suboptimal path.

This is exactly why ASPA (Autonomous System Provider Authorization), defined in draft-ietf-sidrops-aspa-verification, was developed. ASPA allows each AS to publish a cryptographically signed list of its authorized upstream providers. If Safe Host's ASPA record listed only Telia as an upstream, and Telia's ASPA record did not include Safe Host as an authorized transit, receiving networks could have detected the leaked path as unauthorized and rejected it.

Technical Defenses: What Should Have Happened

Multiple layers of defense, had any of them been in place, would have prevented or mitigated this leak:

1. Max-Prefix Limits

The simplest safeguard. If Telia had configured a max-prefix limit on the Safe Host BGP session -- say, 100 prefixes, well above Safe Host's normal count but far below the 70,000+ that leaked -- the session would have been automatically torn down when Safe Host began sending an anomalous number of routes. This is a basic, low-effort configuration that every transit provider should apply to every customer session.

2. IRR-Based Prefix Filters

Transit providers should build prefix filters from Internet Routing Registry (IRR) data, accepting only prefixes registered to the customer. Telia could have automatically generated filters from RIPE's IRR database, limiting Safe Host to its registered address space. Tools like bgpq4 make this straightforward to automate.

3. RPKI Route Origin Validation

RPKI would not have fully prevented this leak (since the origin AS in the leaked routes was still correct), but it would have caught any leaked routes where the combination of prefix and origin AS was invalid. More importantly, widespread RPKI deployment creates a culture and infrastructure for route validation that makes other filtering mechanisms more likely to be deployed.

4. ASPA (AS Provider Authorization)

ASPA, which was still in early development in 2019 but has since matured, directly addresses route leaks. By publishing authorized upstream providers, each AS enables receiving networks to validate that the AS path makes topological sense. A path that included Safe Host as a transit for Cloudflare traffic would fail ASPA validation because Safe Host is not an authorized provider for the ASes whose routes it was leaking.

5. BGP Communities and Policy

BGP communities can signal route handling preferences. For instance, Telia could have tagged routes learned from Safe Host with a community indicating "customer route" and configured its peers (including Verizon) to only accept routes with that community for that path. Similarly, using the Gao-Rexford model of routing policy -- where routes learned from customers are announced to peers and providers, but routes learned from peers or providers are not -- proper implementation would have limited the blast radius.

The MANRS Response and Industry Fallout

The 2019 route leak incidents became a major catalyst for the MANRS (Mutually Agreed Norms for Routing Security) initiative, coordinated by the Internet Society. MANRS establishes a baseline of routing security actions that network operators should implement:

• Filtering -- Prevent propagation of incorrect routing information. This includes applying prefix filters based on IRR data and enforcing max-prefix limits.
• Anti-spoofing -- Prevent traffic with spoofed source IP addresses from leaving your network (BCP 38/84).
• Coordination -- Maintain up-to-date contact information and respond promptly to routing incidents.
• Global validation -- Publish route information (IRR and RPKI) and enable validation of routing announcements.

Before the 2019 incidents, MANRS had modest participation. The Telia/Verizon leak and the surrounding publicity pushed dozens of major networks to publicly commit to MANRS principles. RPKI adoption accelerated significantly in the following years, with major cloud providers, CDNs, and Tier 1 carriers deploying route origin validation.

Verizon's role in this incident was particularly consequential for the industry narrative. As one of the largest networks in the world, Verizon's failure to filter routes demonstrated that even the biggest players were not implementing basic routing hygiene. Cloudflare's public pressure campaign -- including blog posts titled "How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today" -- forced the issue into mainstream tech media and put sustained pressure on large carriers to improve their practices.

Lessons for Network Operators

The Telia/Verizon leak offers concrete lessons that apply to every network operator, regardless of size:

For Transit Providers

• Always filter customers. Every customer BGP session should have both prefix filters (based on IRR registration) and max-prefix limits. This is non-negotiable.
• Automate filter generation. Use tools like bgpq4 or irrpt to automatically build and update prefix filters from IRR databases. Manual filter maintenance does not scale.
• Deploy RPKI ROV. Even though RPKI does not catch all route leaks, it catches hijacks and creates an infrastructure for future path validation.
• Monitor for anomalies. Sudden spikes in the number of prefixes received from a customer should trigger alerts and, ideally, automatic session teardown.

For Stub/Customer Networks

• Register your routes. Maintain accurate IRR entries and publish RPKI ROAs for all your prefixes. This enables your upstream providers to filter accurately.
• Test your BGP configuration carefully. Route leaks from customer networks almost always stem from configuration errors -- redistribution of IGP routes into BGP, incorrect route map application, or optimizer software that unexpectedly alters export policy.
• Use max-prefix limits on your sessions too. If your upstream starts sending you an unexpected number of routes, you want to know about it.

How to Investigate Route Leaks

A BGP looking glass is one of the primary tools for investigating route leaks in real time. When you suspect a leak, here is what to look for:

1. Check the AS path. Look for unexpected ASNs in the path. If traffic to a major cloud provider is traversing a small ISP you have never heard of, that is a strong signal of a route leak.
2. Compare path lengths. Leaked routes often have longer AS paths than the legitimate routes they replace. If the normal path to a prefix is 2 hops and you see a 5-hop path through unusual networks, investigate.
3. Check RPKI status. While RPKI cannot detect all leaks (origin-valid leaks pass validation), RPKI-invalid routes in the leak are a clear sign of problems.
4. Look at multiple vantage points. Route collectors at different locations will show different views of the leak. Compare paths from multiple peers to understand the scope.

Try looking up the networks involved in this incident to see their current routing:

• AS21217 -- Safe Host (the leaking network)
• AS1299 -- Telia/Arelion (Tier 1 that accepted the leak)
• AS701 -- Verizon (propagated the leak globally)
• AS13335 -- Cloudflare (affected network)

The Slow Progress Toward a Safer Routing System

Seven years after the Telia/Verizon leak, the internet's routing system is measurably more secure, but still far from fully protected. RPKI adoption has grown from roughly 20% of prefixes covered by ROAs in 2019 to over 50% by 2025. Major Tier 1 networks including Telia/Arelion, NTT, and Cogent now perform RPKI route origin validation and reject invalid routes. ASPA is progressing through the IETF standardization process and has seen early deployment.

Yet route leaks continue to occur. The fundamental challenge remains: BGP is a trust-based protocol operating in an environment where thousands of independent organizations make their own configuration decisions. A single misconfigured router in a single small network can still, if the right upstream providers lack filtering, cause global routing disruptions. The defenses exist. The question is whether every network in the chain deploys them.

The Telia/Verizon incident of June 2019 stands as a stark demonstration of what happens when they do not.

Explore BGP Routing

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

• Look up AS1299 -- Telia/Arelion, one of the world's largest Tier 1 networks
• Look up AS701 -- Verizon's autonomous system
• Look up AS13335 -- Cloudflare's network and routes
• Look up 1.1.1.1 -- See the AS path to Cloudflare's DNS