The 2025 DDoS Mitigation Leak and BGP Role Accountability

Summary

Kentik reported that, beginning at 07:35 UTC on 1 April 2025, DDoS mitigation provider Voxility's autonomous system AS3223 leaked routes learned from peers through transit provider Lumen's autonomous system AS3356. The event lasted around 20 minutes and involved 31,258 routes in Kentik's reconstruction, including 7,381 seen by at least 50 peers feeding the RouteViews public route-collector system [1].
This was a path or adjacency leak, not a simple case of the wrong autonomous system originating someone else's prefix. The origins could remain legitimate while the middle of the path violated the intended relationship. That distinction explains why Route Origin Validation, or ROV, was not sufficient [1][15][16].
Kentik used RouteViews BGP messages and aggregated traffic data to show examples involving TPG Telecom and Yahoo prefixes, along with traffic that was either misdirected through the leaked path or dropped. Those observations are powerful but bounded: they do not reveal every affected network or the exact overloaded link [1][8].
DDoS mitigation networks present a difficult but not optional filtering problem. They can legitimately carry routes for large and changing customer populations. Accountability therefore depends on relationship-aware provisioning, explicit import and export policy, route-count anomaly controls, BGP Roles and Only-to-Customer where available, and evidence retained by both the mitigation provider and its transit neighbors [12][13][14][16][17].
The article does not allege malicious intent, a legal breach, a universal outage or a known internal root cause. It asks which records should exist at AS3223, AS3356, peers, affected networks and route collectors to prove the event boundary, impact, withdrawal and durable repair.

What happened

The visible event began at 07:35 UTC on 1 April 2025. Kentik reported that Voxility, identified by autonomous system number AS3223, began advertising routes learned from peers to its transit provider Lumen, AS3356. A peer is normally a network with which another network exchanges traffic for their respective customers without providing full Internet transit. A transit provider carries traffic toward the broader Internet. When a route learned from a peer is exported to a provider as if it were an allowed customer route, it can travel farther than intended and attract traffic that the exporting network was never meant to carry [1][11].

For a non-specialist, the simplest analogy is a delivery company publishing a shortcut through a depot that was authorized only for a limited exchange. Other carriers see a plausible route, prefer it under their own rules and send packages toward the depot. The address on each package may still be correct. The problem is the chain of handoffs. If the depot or its links were not provisioned for the diverted load, deliveries slow down or fail even though nobody changed the final destination.

Kentik described the incident as a path error rather than a mis-origination. It counted 31,258 leaked routes, of which 7,381 were seen by at least 50 RouteViews peers, and said the incident lasted as much as 20 minutes [1]. Those numbers should retain their attribution. They are not a census of every router on the Internet. RouteViews is a collection of BGP vantage points supplied by participating networks. A route visible to many collectors is evidence of broad propagation, but the collector set is still a sample [8].

The path examples make the relationship failure concrete. Before the leak, one RouteViews feed supplied by the California research and education network CENIC showed a TPG Telecom prefix following a path through Tata and Lumen. During the incident, the same prefix appeared behind AS3223 and AS3356, with community values that Kentik interpreted as a customer route received in Bucharest. Another example involved a Yahoo prefix that normally reached GTT through PCCW but was seen during the leak through AS3356 and AS3223 [1][7]. These examples show a changed running path. They do not by themselves disclose the internal route map that created it.

Kentik also examined aggregated NetFlow data. NetFlow is a summary of traffic flows recorded by network devices. Its analysis indicated traffic sent along paths containing AS3356 and AS3223 toward destinations in multiple countries. It further compared traffic to a subset of the most visible leaked routes and found both a smaller misdirected portion and a larger disruption or drop. Kentik explicitly said the exact bottleneck on the path was unknown [1]. That uncertainty is important. A responsible account should not transform an inference about congestion into a claim that a specific port, router or operator definitively failed.

The public evidence therefore supports a bounded statement. A path leak escaped AS3223, was accepted and propagated through AS3356, appeared at many route-collector peers, and coincided with measurable traffic disruption in Kentik's data. The evidence does not disclose whether the first error was a route-map change, a provisioning record, a session role, a community rule, a software defect or some combination. It also does not show every destination, every customer complaint or every remediation step.

Why it matters

DDoS mitigation providers are unusual routing actors. A distributed denial-of-service attack tries to overwhelm a service or network with traffic. A mitigation provider may receive a customer's routes so traffic can be diverted into large scrubbing systems, where unwanted traffic is filtered before legitimate traffic is returned. Depending on the service design, the provider can legitimately originate, transit or propagate routes for many different customers. Its authorized routing surface may change quickly during attacks and onboarding events.

That breadth makes a naive allowlist difficult. Kentik cited a bgp.tools expansion for the AS3223 AS-SET that included tens of thousands of autonomous systems and hundreds of thousands of IPv4 and IPv6 prefixes [1][3]. An AS-SET is an Internet Routing Registry object that groups autonomous systems for policy generation. Such objects can help automate filters, but large nested sets can become too broad to express a meaningful relationship boundary. A list that covers much of the routing table may protect router memory while doing little to distinguish legitimate customer propagation from a leaked peer route.

The difficulty does not remove responsibility. It changes what responsible control looks like. A mitigation provider cannot rely on one static prefix list as its complete answer. It needs a provisioning ledger that identifies the customer, service mode, authorized prefixes, route origin, relationship role, activation window, upstream sessions and return path. That ledger must be reconciled with the configuration actually running on routers. The important question is not whether a spreadsheet or registry object exists; it is whether the exported BGP state matches the approved service relationship.

Transit providers face the mirror image of the problem. They know that mitigation customers can legitimately advertise many third-party origins, so a filter based only on origin ownership may be insufficient. Yet accepting nearly any route from such a customer creates a powerful propagation channel. The provider needs controls that distinguish customer-authorized routes from routes the mitigation network learned from lateral peers or providers. If the distinction is missing, a local export mistake can become global shared risk.

The harm is also broader than routing-table aesthetics. A leaked path can redirect traffic through a remote geography, overload a link, create latency, produce packet loss or make a service appear unavailable. The destination operator may remain healthy while users experience failure. Support teams can waste time looking at applications, DNS or cloud systems because the routing change is outside their immediate control. For public services, communications platforms, financial systems and networked businesses, 20 minutes of path distortion can be operationally significant even when there is no permanent data loss.

This is why the incident belongs in risk and accountability rather than a narrow protocol diary. BGP is a shared control plane. Each operator makes local choices, but those choices impose external costs when a route crosses the wrong boundary. Accountability requires evidence from every point where the route could have been stopped: the mitigation provider's export, the transit provider's import, downstream propagation, affected networks' telemetry and independent collectors.

The technical layer: origin validity is not path validity

BGP exchanges reachability between autonomous systems. An autonomous system, or AS, is a network under one administrative routing policy and is identified by an ASN. A BGP announcement includes an IP prefix, an AS_PATH and other attributes. The AS_PATH lists the autonomous systems through which the route advertisement has passed. Routers use local policy, path length and other attributes to choose among routes [10].

Origin security asks whether the right ASN appears at the origin end of the path. The Resource Public Key Infrastructure, or RPKI, allows a resource holder to create a Route Origin Authorization, known as a ROA, that states which ASN may originate a prefix. Route Origin Validation compares a received origin against those authorizations [15][16]. This is valuable because it can reject or de-prioritize a route with an unauthorized origin.

The April 2025 event did not depend on replacing legitimate origins. The path examples retained the destination origins while inserting AS3223 as an unintended intermediary. Kentik found virtually no new more-specific routes and concluded that ROV would not have limited this class of event [1]. The control question therefore moves from origin authorization to propagation authorization. Was AS3223 allowed to send a peer-learned route to AS3356? Was AS3356 allowed to accept it as a customer route? Should downstream networks have recognized the path as inconsistent with expected relationships?

RFC 7908 defines a route leak as propagation beyond intended scope and describes common relationship patterns [11]. The practical Internet often follows a valley-free expectation: a network may carry routes from its customers toward peers or providers, but it should not normally carry a route learned from one peer to another peer or provider. Real relationships can be complex, and commercial labels do not always map neatly to protocol policy. That complexity strengthens the case for explicit machine-readable roles rather than weakening it.

RFC 9234 specifies BGP Roles and the optional transitive Only-to-Customer attribute, or OTC [14]. Neighboring networks can negotiate roles such as provider, customer, peer, route server or route-server client. The OTC attribute then carries information about where a route is allowed to propagate. In the simplified counterfactual described by Kentik, a peer-learned route marked OTC should not be accepted from AS3223 by AS3356 as a customer route [1]. The attribute is not proof that either operator had deployed the mechanism. It is a standards-based description of the relationship evidence that was missing from the leaked path.

Autonomous System Provider Authorization, or ASPA, addresses another part of path verification. An AS can authorize its providers, giving validators a way to assess whether provider relationships in a path are plausible [16]. ASPA deployment and validation are still operational questions, and the article should not claim it would have deterministically prevented this exact event. The important point is that routing security is expanding beyond the origin because path and relationship failures need their own evidence.

Explicit import and export policy remains the foundation. RFC 8212 changes the default expectation for external BGP sessions: routes should not be imported or exported without configured policy [13]. RFC 7454 collects operational security practices, including filtering and limits [12]. These standards do not eliminate mistakes. They define a fail-closed posture in which a missing or ambiguous policy should not silently turn a session into a route exchange for everything.

The AS3223 evidence duty

AS3223's first evidence duty is to show the intended export set for the AS3356 session at the time of the incident. That set should distinguish self-originated routes, directly authorized customer routes, routes learned from peers, routes learned from providers and temporary mitigation routes. A postmortem should not merely state that the configuration was corrected. It should preserve the policy before and after the event, identify the exact delta and bind the delta to an approved change or emergency action.

The second duty is to reconcile policy with running state. BGP implementations maintain several views of routes, including routes received from a neighbor, routes selected locally and routes advertised to a neighbor. An Adj-RIB-Out snapshot, or equivalent advertised-route record, can show what AS3223 actually sent to AS3356. Comparing that output with the provisioning ledger would identify whether the leaked routes entered through the wrong class, lost a community marker, bypassed an export term or inherited an overly broad policy.

The third duty is to explain anomaly detection. A leak of more than 30,000 routes should produce a visible change in exported route count or path composition. Maximum-prefix controls are often applied on import to protect a router from receiving too many routes. Export-side controls can compare a session's planned and actual route sets. The operator should show whether an alert fired, who received it, how quickly the session or policy was constrained, and whether the alert threshold would detect a smaller recurrence.

The fourth duty is to show relationship provenance. If the leaked routes were learned from peers, the system should preserve the ingress session, role, communities and policy tags that classified them. If those tags were missing or overwritten, the repair should restore the chain of custody. Relationship classification is not just a billing label. It is security metadata that determines where a route may travel.

The fifth duty is to prove withdrawal and convergence. A route disappearing from one collector is not enough. AS3223 should correlate its local withdrawal timestamps with AS3356 acceptance state, downstream collector changes and traffic recovery. The closeout should show whether the bad routes were removed by a source-side action, an upstream filter, a session reset or natural convergence. Different mechanisms imply different recurrence risk.

None of these duties presume intent or negligence. They are the normal evidence requirements for an operator whose running announcements affected other networks. A company may have acted quickly and responsibly after an unexpected failure. The records are what allow customers and peers to distinguish that response from a temporary disappearance with no durable control change.

The AS3356 acceptance duty

AS3356 was not the reported source of the peer-learned routes, but acceptance and propagation are separate control decisions. A transit provider chooses what it will accept from a customer. It can use customer provisioning, registry data, RPKI status, IRR sets, route history, communities, AS-path rules and negotiated roles. No source is perfect. A robust acceptance policy combines them and escalates exceptions rather than treating a large customer route surface as unlimited permission.

The first acceptance question is what AS3356 believed AS3223 was authorized to carry. If the answer came from an expanded AS-SET, the postmortem should preserve the exact object versions and expansion result used at the time. Registry data changes. Nested objects can include stale or overly broad members. Reconstructing the generated filter is necessary to know whether the policy itself authorized too much or whether the running router failed to apply the policy.

The second question is whether the provider enforced customer-route semantics. A customer path that contains a destination origin behind the customer can be legitimate. A path showing a customer as transit between a peer-learned route and the provider may be inconsistent with the relationship. BGP Roles and OTC are designed to make that inconsistency visible in-band [14]. Where those mechanisms are not deployed, operators still need equivalent local controls based on session classification, communities and path rules.

The third question is route-count and novelty detection. A customer's normal route surface can be large, but its rate of change and composition have patterns. An abrupt arrival of tens of thousands of paths learned from unrelated peers should trigger scrutiny even when a maximum-prefix limit is not exceeded. Providers can compare new paths with the customer's authorized origins, usual first-hop relationships and historical announcements. The goal is not to freeze legitimate mitigation activity; it is to make exceptional breadth require exceptional evidence.

The fourth question is downstream export. Once AS3356 accepted the routes, its policies influenced how widely they spread. A complete account should show which peers and customers received the paths, when withdrawals were sent and whether any downstream sessions retained stale state. That evidence matters because a provider may stop accepting the source while some downstream routers continue to prefer a previously learned path until convergence completes.

The fifth question is communication. Affected networks need a precise incident notice: event start, route classes, AS paths, mitigation steps, confidence bounds and recovery status. Generic statements about a routing issue are not enough for customers trying to correlate traffic loss. Shared incidents require shared timestamps and artifacts so each operator can reconcile its own telemetry.

Who was affected, and what the public data cannot prove

Kentik's traffic analysis identified destination-country shares among traffic observed on AS paths containing the leaked subsequence and examined a subset of heavily visible leaked routes [1]. That analysis is stronger than a route-table-only account because it connects the control-plane change to forwarding consequences. It is still bounded by Kentik's customer vantage points, flow annotation method and selected route set.

The phrase "networks around the world" should therefore be understood as observed broad impact, not a claim that all users or all routes were affected. Different networks select different paths. Local preference can favor customer routes over peer or provider routes. AS-path prepending can make one path look less attractive, while a leaked route may appear shorter. Geography, peering and traffic engineering all influence whether a particular network sees or selects the leak.

The examples involving TPG Telecom and Yahoo demonstrate that unrelated destination networks could be drawn into the path [1][4][5][6]. They do not establish that those organizations caused the incident or that every service they operated was unavailable. Their prefixes serve as evidence objects in a route-propagation analysis. The accountable control surfaces remain the export, acceptance and propagation decisions around the leaked path.

RouteViews and RIPE RIS can help expand the view [8][9]. RIPE RIS is another public routing data platform with collectors in multiple locations. Comparing the two systems can show when and where paths appeared, but neither collector platform sees every routing decision. A route may be visible without being selected for forwarding, and a selected path at one network may not represent another network's experience.

The exact bottleneck is also unknown. Kentik inferred that unexpected traffic likely overwhelmed something along the AS3356-AS3223 path because dropped or disrupted traffic exceeded the misdirected traffic that still reached its destination [1]. That is a reasonable operational interpretation, not a location proof. A closeout should avoid naming a port, facility or capacity owner unless packet, interface or flow records support the claim.

Customer-loss estimates require similar discipline. Twenty minutes of degraded routing can interrupt sessions, time out transactions and trigger operational response. Converting that into financial loss requires service-specific evidence. The absence of a public loss figure does not make the routing control failure unimportant. It means the article should describe the continuity risk without inventing damages.

Registry records are evidence anchors, not verdicts

Public ASN pages for AS3223 and AS3356 help bind the event to stable number-resource identities [3][4]. Additional pages for AS7545 and AS10310 anchor the example origins [5][6]. These records are useful because company names, ownership and service descriptions can change while the autonomous system identifiers remain part of the routing evidence.

This is why registry records matter without deciding the case. A registry is a ledger and recordkeeper, not a sovereign judge of operational conduct. An ASN record can identify the resource holder or routing context. It cannot prove which route map ran on a particular router or decide whether an export was permissible under a private interconnection agreement. The running BGP state remains the reality layer.

The distinction prevents two common mistakes. The first is treating registration as permission: because an ASN is properly registered, any path containing it must be legitimate. That is false. Registration covers identity and resource administration, not every propagation relationship. The second is treating a public path as a complete fault verdict. A collector can show an unexpected sequence, but private logs are still needed to explain cause, authorization and repair.

Accountability connects the layers. Registry records identify the autonomous systems. Provisioning records describe intended relationships. Router state shows what was accepted and exported. Collectors show external propagation. Traffic telemetry shows forwarding effects. Incident records explain the repair. A credible postmortem should let an independent reviewer move across those layers without relying on brand trust or advocacy.

Controls that should have stopped or shortened the leak

The first control is explicit relationship assignment for every external BGP session. Each side should know whether the session is provider-to-customer, peer-to-peer, route-server-to-client or a documented complex relationship. The assignment should be stored in provisioning data, represented in configuration and reviewed during changes. A session whose relationship is unknown should not inherit a permissive default.

The second control is default-deny import and export. RFC 8212 formalizes the principle that routes should not flow across an external session without policy [13]. For a mitigation provider, the policy may need dynamic inputs, but the generated result should still be explicit. Emergency activation should add a bounded authorization, not bypass the gate for the entire table.

The third control is route provenance. Routes should carry internal tags showing whether they were originated locally, learned from a customer, learned from a peer or learned from a provider. Export policy can then enforce relationship rules. Tags must be protected against accidental overwrite and tested across route reflectors, vendor boundaries and service automation.

The fourth control is negotiated BGP Roles and OTC where implementation and peer support permit [14]. These mechanisms allow the relationship to be confirmed by both neighbors and carry a signal that helps detect routes moving in prohibited directions. Deployment should be measured per session. A policy document saying roles are supported is not evidence that the AS3223-AS3356 boundary used them on 1 April 2025.

The fifth control is ASPA-aware path verification as the ecosystem matures [16]. Provider authorizations can give networks more evidence about whether an observed provider relationship is plausible. Operators should track coverage, validator behavior, exception handling and false-positive risk. ASPA should complement, not replace, direct customer provisioning and route policy.

The sixth control is route-count and composition monitoring. Useful thresholds compare the current export with a planned set and historical baseline. They should detect a large delta, unexpected origin diversity, new first-hop relationships, sudden more-specifics and abnormal propagation. Alerts should have named owners and a rapid containment action.

The seventh control is public collector monitoring. RouteViews and RIPE RIS provide an outside-in view that can catch a mismatch between intended and actual announcements [8][9]. Operators should monitor their own ASN appearing unexpectedly in paths, not only unauthorized origins. A route-path alert can reveal a leak that origin-only monitoring misses.

The eighth control is traffic-impact correlation. BGP updates explain the control-plane event, while flow, interface and packet-loss data show forwarding consequences. The incident timeline should align route announcements, path selection, traffic redirection, drops, customer reports and withdrawal. Without that alignment, teams may close the routing issue while users remain affected.

The ninth control is rollback proof. A repaired configuration should be rendered from source, compared with the previous version, validated in a lab or policy test, deployed under change control and observed externally. The test should include the exact failed class: a peer-learned route presented for export to a provider. A generic successful BGP session test is not enough.

The tenth control is retained communication. Peers, customers and transit providers should preserve incident notices, acknowledgments, timestamps and route samples. Routing failures cross organizational boundaries. A closeout that exists only in one operator's ticket system cannot prove that the shared path was repaired everywhere.

What leadership must own

Leadership does not need to approve every route map line, but it does need to own the system that makes route authorization auditable. The first governance decision is who owns the relationship ledger. Sales may know the commercial arrangement, provisioning may know the service, and network engineering may know the session. If those records disagree, the router eventually receives ambiguity as configuration.

The second decision is whether emergency DDoS mitigation can bypass normal evidence. Attack response creates pressure to announce routes quickly. The safe design pre-authorizes bounded prefixes and relationships, records every activation, applies expiry and verifies external propagation. Speed should come from prepared controls, not from disabling them.

The third decision is how much friction to accept at transit boundaries. Broad customer filters can reduce provisioning work and avoid accidental rejection of legitimate mitigation routes. They also enlarge the blast radius of customer mistakes. Leadership should require a documented risk acceptance for permissive policies and fund the automation needed for narrower dynamic controls.

The fourth decision is disclosure quality. An accountable incident statement separates facts, inference and unknowns. It gives exact times, ASNs, route classes, observed impact, containment and planned controls. It avoids blaming an individual engineer or claiming complete recovery before external evidence agrees.

The fifth decision is independent verification. Teams that wrote the policy should not be the only teams deciding that the repair works. A separate network-security or reliability reviewer can test route export, collector visibility and alerting. Important peers may also need a coordinated validation window.

The incentive risk is familiar: every operator assumes the next boundary will catch the problem. The mitigation provider expects transit filtering. The transit provider expects accurate customer provisioning. Downstream networks expect path selection to remain stable. Resource holders expect RPKI to solve routing security. The April 2025 leak shows that these partial assumptions do not add up to a complete control system.

What to watch next

The first signal is public disclosure of a specific root cause and repair. A useful account would name the failed policy class without exposing sensitive configuration, identify whether AS3223 or AS3356 changed filtering, and provide a testable statement about recurrence prevention. A generic reference to human error would not answer the relationship question.

The second signal is BGP Role and OTC deployment. Operators should publish implementation support and measure session coverage. The important metric is not whether software can parse the capability; it is how many high-risk customer, peer and mitigation sessions negotiate consistent roles and enforce the resulting policy.

The third signal is ASPA ecosystem coverage. As provider authorizations expand, route monitors may gain stronger path evidence. Reviewers should watch how networks handle unknown and invalid states, how exceptions are governed, and whether the control catches provider-path anomalies without disrupting legitimate complex relationships.

The fourth signal is route-leak visibility. Public monitoring should show fewer wide propagations and shorter containment times. For AS3223 and AS3356, a recurrence of unexpected peer-origin paths through the same relationship would be strong evidence that the repair was incomplete. A clean period is helpful but not proof without tested controls.

The fifth signal is mitigation-provider onboarding discipline. Providers should be able to explain how a customer prefix becomes authorized, how the authorization expires, how route provenance is retained and how exported routes are compared with the service ledger. This is a continuity control, not merely a compliance form.

The sixth signal is transit-provider customer filtering. Large carriers should disclose enough about their routing-security posture to show that high-volume mitigation customers do not receive unlimited propagation privilege. MANRS guidance offers an operational baseline for preventing incorrect announcements and maintaining contact information [2][17].

The seventh signal is shared incident timing. Route collectors, traffic telemetry and operator statements should converge on start, containment and recovery. If they do not, the discrepancy should remain open. Accountability is not achieved by choosing the most convenient timestamp.

The eighth signal is evidence retention across organizational boundaries. A future review should be able to retrieve the exact AS3223 export policy, the AS3356 customer-acceptance policy, route-count alerts, collector snapshots, flow summaries, incident notices and the tests used to approve the repair. Retention periods should reflect how long peers and customers may need to reconcile an event, not merely how long a device keeps volatile logs. The records should identify the policy version and time source so an investigator can distinguish a route that was configured, selected, advertised, accepted or merely observed.

This is where operational continuity becomes measurable. A route withdrawal can restore service quickly, but only retained evidence can show whether the restored state came from a durable relationship-aware control or a one-off manual intervention. Operators should also preserve failed tests and exceptions. A clean final configuration without the rejected intermediate states can hide the decision path that created risk. Evidence retention is therefore part of prevention: it makes recurring policy drift visible before another broad propagation event.

Scenario changes

The assessment would change if router records showed that AS3223 never exported the leaked routes and that the collector path was created elsewhere. It would also change if AS3356 had rejected the routes and another path merely appeared to contain the same sequence through aggregation or observation error. Those are testable alternatives, and the public article should remain open to them.

The assessment would become more severe if evidence showed a known permissive export rule, repeated warnings, disabled alerts, an unbounded AS-SET accepted without review, or a prior similar leak left unrepaired. It would also become more severe if operators claimed complete recovery while relevant collectors or traffic data continued to show the path.

The assessment would become less severe if the operators produced a narrow configuration defect, immediate automated containment, consistent collector withdrawal, verified traffic recovery and an independently tested relationship-aware repair. That would not erase the incident. It would demonstrate that the accountability system worked after the initial control failed.

The judgment should not turn on whether a regulator or registry declares fault. Number-resource registries provide identity and authorization records at their own layer. They do not operate the routers. The decisive evidence is the running route state and the controls that govern it.

The 2025 DDoS Mitigation Leak Made BGP Role Boundaries an Accountability Test

Why it matters

Summary

What happened

Why it matters

The technical layer: origin validity is not path validity

The AS3223 evidence duty

The AS3356 acceptance duty

Who was affected, and what the public data cannot prove

Registry records are evidence anchors, not verdicts

Controls that should have stopped or shortened the leak

What leadership must own

What to watch next

Scenario changes

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing