Comcast BGP Route Leak 2017: How a Filtering Failure Hijacked Traffic

On November 6, 2017, Comcast (AS7922) -- the largest residential internet service provider in the United States -- leaked a large number of BGP routes to its peers, briefly hijacking traffic destined for other networks. The leak lasted approximately 90 minutes and affected routes to major content providers, CDNs, and other networks. While the incident did not cause a total internet outage, it misdirected traffic through Comcast's network for destinations that Comcast had no authority to advertise, demonstrating once again how the internet's routing system remains vulnerable to route leaks from even the largest and most established networks.

The Comcast route leak of 2017 is significant not because of its duration or severity -- it was relatively short-lived compared to incidents like the Cloudflare-Verizon leak of 2019 -- but because it came from a Tier 1-adjacent network with tens of millions of customers, and it illustrated how a single filtering failure at a major ISP can propagate incorrect routing information across the global internet within seconds.

Background: Comcast's Network

Comcast (AS7922) operates one of the largest networks in North America. As of 2017, Comcast served over 25 million broadband subscribers and carried a substantial portion of US internet traffic. Comcast's network is a Tier 1-adjacent or "Tier 2" network, meaning it has extensive peering relationships with other large networks and purchases some transit, but also operates as a transit provider for smaller networks.

Comcast maintains BGP peering sessions with hundreds of networks at major Internet Exchange Points across the US and internationally. These peering sessions are governed by route policies: filters that control which prefixes Comcast announces to each peer and which prefixes it accepts from each peer. When these filters fail or are misconfigured, the results can be dramatic.

What Happened: The Route Leak

On November 6, 2017, Comcast's BGP routers began announcing routes for prefixes that did not belong to Comcast or its downstream customers. These announcements were propagated through Comcast's peering sessions to adjacent networks, which in turn propagated them further. The leaked routes included prefixes belonging to major internet properties and infrastructure providers.

Mechanics of a Route Leak

To understand the Comcast incident, it helps to understand the mechanics of a BGP route leak in the context of a large ISP.

Comcast, like all large networks, learns routes from multiple sources:

• Customer routes -- Prefixes announced by Comcast's downstream customers (businesses, smaller ISPs, content providers that buy transit from Comcast). Comcast is expected to re-announce these routes to its peers and upstream providers, providing transit for these customers.
• Peer routes -- Prefixes learned from networks that Comcast has settlement-free peering agreements with. Under standard peering policy, Comcast should use these routes to reach those networks' prefixes but should not re-announce them to other peers. Peering routes are for local use only.
• Transit routes -- Prefixes learned from networks that Comcast pays for transit. Like peer routes, these should not be re-announced to Comcast's other transit providers (that would create a transit loop) or to peers (that would turn Comcast into a free transit provider for those networks).

A route leak occurs when a network re-announces routes that it should not. In Comcast's case, routes learned from peers or transit providers were re-announced to other peers, effectively telling those peers "send traffic for these destinations through Comcast." The peers, seeing Comcast in the AS path and having no reason to distrust a major ISP, accepted the routes and forwarded them to the global routing table.

How the Leak Was Detected

The Comcast route leak was detected within minutes by multiple monitoring systems and network operators:

• BGPStream and RIPE RIS -- Public BGP monitoring services observed new AS paths appearing for prefixes that had never previously transited through AS7922. When a prefix that normally follows the path [Origin -> Transit A -> Peer] suddenly appears as [Origin -> Comcast -> Peer], it is a clear indicator of a leak.
• Network operator alerts -- Operators of the affected prefixes received alerts from their own monitoring systems showing new, unexpected AS paths for their prefixes. When your prefix suddenly has an additional AS in its path that should not be there, your BGP monitoring tools flag it.
• NANOG and operator mailing lists -- Network engineers quickly began reporting the leak on operational mailing lists, identifying AS7922 as the source and cataloging the affected prefixes.

The detection was rapid, but the remediation depended on Comcast's internal response. External operators could not fix the leak; they could only observe it and, in some cases, apply defensive filtering to prefer alternative paths that did not transit through Comcast.

Impact Analysis

The impact of the Comcast route leak was moderated by several factors:

Why It Was Not Worse

• AS path length. The leaked routes included Comcast's own AS number in the path, making them longer than the legitimate paths. BGP prefers shorter AS paths, so many networks that had a direct or shorter path to the affected prefixes continued using the correct route. The leak primarily affected networks whose only path to the affected prefixes would have been through Comcast or whose BGP selection process preferred the leaked path for other reasons (e.g., local preference, MED).
• Short duration. The leak was corrected within approximately 90 minutes, limiting the total traffic misdirected.
• Comcast had valid connectivity. Unlike some BGP hijacks where the hijacking network has no path to the legitimate destination (causing traffic to black-hole), Comcast actually had connectivity to the prefixes it was leaking. Traffic that was misdirected through Comcast was still delivered to its intended destination, albeit via a suboptimal path. This meant the impact was primarily performance degradation (additional latency, potential congestion) rather than a total loss of connectivity.

Why It Still Mattered

• Traffic interception risk. When traffic is routed through an unintended network, that network has the ability to inspect, log, or modify the traffic. While there is no evidence that Comcast intentionally intercepted traffic during this incident, the routing configuration created the technical capability to do so. For unencrypted traffic (HTTP, DNS, SMTP without TLS), this is a real confidentiality risk.
• Precedent and trust. If one of the largest ISPs in the world can leak routes, it underscores the systemic fragility of the internet's routing system. BGP operates on trust: every network trusts its peers to only announce routes they are authorized to announce. When a major network violates this trust -- even accidentally -- it erodes confidence in the system.
• Scale of potential impact. Comcast's network carries traffic for over 25 million households. A route leak from this network has the potential to affect a massive volume of traffic, even if each individual prefix sees only a modest increase in latency.

Root Cause: Route Policy Configuration Error

While Comcast did not publish a detailed root cause analysis, the pattern of the leak -- routes learned from peers being re-announced to other peers -- points to a failure in Comcast's BGP export policies. These policies are implemented as route maps, prefix lists, and community-based filters on Comcast's border routers.

In a properly configured network, BGP export policies enforce the following rules:

To Customers:     Announce all routes (full table or default + customer routes)
To Peers:         Announce only customer routes and own prefixes
To Transit:       Announce only customer routes and own prefixes

NEVER:            Re-announce peer routes to other peers (route leak)
NEVER:            Re-announce transit routes to peers (free transit)
NEVER:            Re-announce transit routes to other transit providers (loop)

The most common causes of route leaks at large ISPs include:

• Policy template errors -- A change to the route policy template that is applied to peering sessions may accidentally include routes that should be filtered. If the template is applied to hundreds of peering sessions, the leak is instantly global.
• Community stripping -- BGP communities are often used to tag routes with their origin (customer, peer, transit). If a router configuration change accidentally strips these community tags, the export policy cannot distinguish between route types and may announce everything.
• Route-map ordering -- BGP route maps are evaluated sequentially. If a new entry is added in the wrong position, it may match routes that should be filtered before the filtering rule is evaluated.
• Automation failures -- Large networks use automation to generate and deploy router configurations. A bug in the automation tooling can produce configurations that do not match the intended policy.

What Should Have Prevented It

Multiple layers of defense should have prevented this leak from occurring or limited its impact:

At Comcast (the leaker)

• BGP community-based filtering -- Every route learned from a peer or transit provider should be tagged with a community indicating its type. Export policies should then filter based on these communities, ensuring that only customer-tagged routes are announced to peers.
• Configuration review and testing -- Changes to BGP export policies should be peer-reviewed, tested in a lab environment, and deployed incrementally (one peering session at a time, not all at once).
• Automated policy validation -- Tools like Batfish or similar network configuration analysis platforms can verify that a proposed configuration change does not create unintended route leaks before it is deployed to production routers.

At Comcast's Peers (the receivers)

• Prefix filtering -- Peers should filter incoming routes from Comcast to only accept prefixes that Comcast is authorized to announce (its own prefixes and its customers' prefixes, as registered in IRR databases).
• Max-prefix limits -- If Comcast suddenly begins announcing thousands of new prefixes, a max-prefix limit on the peering session would automatically shut it down, preventing the leak from propagating.
• RPKI validation -- If the affected prefixes had ROAs (Route Origin Authorizations) and the receiving networks validated routes against RPKI, the leaked routes (with Comcast as the origin or with an unexpected AS path) would have been flagged as invalid and rejected.

The Broader Problem: BGP Without Authentication

BGP was designed in the 1980s as a protocol between trusted network operators. It has no built-in mechanism for verifying that a network is authorized to announce a given prefix. When AS7922 announces a route to a prefix, the receiving network has no cryptographic proof that Comcast has authorization to originate or transit that prefix. It simply trusts that Comcast's export policy is correct.

This fundamental lack of authentication is what makes route leaks possible. Solutions exist but adoption remains incomplete:

• RPKI (Resource Public Key Infrastructure) -- Provides cryptographic proof of prefix origin authorization. A ROA (Route Origin Authorization) says "AS X is authorized to originate prefix Y." If a different AS announces that prefix, the route can be flagged as invalid. RPKI adoption has grown significantly since 2017, but it primarily validates origin ASes, not the full AS path -- a leak where the origin AS is correct but the path includes unauthorized transit ASes would not be caught by basic RPKI ROV (Route Origin Validation).
• BGPsec -- An extension to BGP that provides cryptographic signatures on each AS hop in the path, preventing AS path manipulation. BGPsec is defined in RFC 8205 but has seen minimal real-world deployment due to performance concerns, the need for every AS in the path to participate, and the complexity of key management.
• ASPA (Autonomous System Provider Authorization) -- A newer mechanism that allows networks to publish their authorized upstream providers in RPKI. ASPA can detect route leaks by verifying that each AS in the path is an authorized provider for the next AS. ASPA was still in development at the time of the Comcast leak but has since progressed toward standardization.

Comcast's Response and Industry Impact

Following the incident, Comcast corrected its route policies and the leaked routes were withdrawn. The relatively fast resolution (approximately 90 minutes from leak to correction) suggests that Comcast's NOC identified the issue quickly, likely through their own monitoring or through reports from affected peers.

The incident contributed to the broader industry push for routing security improvements:

• MANRS (Mutually Agreed Norms for Routing Security) -- The Internet Society's MANRS initiative gained momentum in the years following incidents like the Comcast leak. MANRS asks networks to commit to filtering, anti-spoofing, coordination, and global validation.
• RPKI deployment acceleration -- Major networks, including Comcast itself, increased their deployment of RPKI ROV in the years following this and similar incidents. By 2024, a significant majority of Tier 1 and large Tier 2 networks perform RPKI validation on incoming routes.
• Automated route leak detection -- Services like Cloudflare Radar, RIPE RIS, BGPStream, and commercial BGP monitoring platforms have improved their ability to detect and alert on route leaks in near real-time, reducing the window during which leaked routes can propagate.

A Pattern That Keeps Repeating

The Comcast route leak of 2017 is one incident in a long history of BGP leaks from major networks. The fundamental problem -- that BGP trusts every announcement from every peer -- remains unsolved despite decades of work on routing security. Until RPKI, ASPA, and other validation mechanisms achieve near-universal deployment, route leaks from large networks will continue to occur and continue to misdirect traffic on the global internet.

Each incident underscores the same lesson: the internet's routing system is only as secure as the weakest link in the chain of networks that propagate routes. A single misconfigured router at a major ISP can inject incorrect routing information that propagates globally within seconds, affecting traffic flows for millions of users.

Explore BGP Routes

You can examine Comcast's AS7922 and its current route announcements, see the AS paths that connect it to the rest of the internet, and explore the peering relationships between major networks. Use the god.ad BGP Looking Glass to look up any autonomous system, IP address, or prefix and trace how traffic is routed across the internet today.