Summary
- On June 24, 2019, optimized, more-specific routes generated inside DQE Communications' network were passed through customer AS396531 and accepted by Verizon's AS701. Verizon then propagated paths covering thousands of networks. Because routers prefer a more-specific destination prefix, substantial traffic followed the leaked paths into links that were not sized to carry it; Cloudflare reported losing about 15% of its global traffic at the incident's worst point.
- The public route record supports a chain of control failures, not a single-cause slogan. The route generator did not keep its optimization routes local, a multihomed customer exported provider-learned routes to another provider, and a major transit network accepted and spread routes that did not fit the customer's expected routing authority. Cloudflare could detect, communicate, and help withdraw the routes, but it could not unilaterally change another network's import policy.
- RPKI Route Origin Validation was unusually well matched to the Cloudflare portion of this event because Cloudflare's Route Origin Authorizations allowed its aggregate prefixes only to a stated maximum length. The leaked more-specifics exceeded that length and were therefore invalid. That does not make RPKI a complete route-leak solution: origin-valid paths can still violate commercial relationships, which is why customer filtering, prefix limits, BGP Roles, path controls, monitoring, and reachable operations contacts remain necessary.
- Accountability follows control capability. Operators that generate or export exceptional routes must contain and test them; providers must verify what customers may announce; cloud platforms must publish route authority, observe external paths, coordinate rapidly, and disclose customer impact; customers must plan for dependency failure; and boards and regulators should demand measured route-security assurance rather than a generic statement that industry best practice is followed.
A routing outage, not a failure of Cloudflare's servers
At 10:34:25 UTC on June 24, 2019, public BGP collectors began recording abnormal, more-specific routes for Cloudflare address space. The last of the studied Cloudflare routes disappeared at 12:38:54 UTC. Cloudflare's archived-route deep dive reconstructs that interval from RIPE NCC data and shows a remarkably consistent path: Cloudflare's AS13335, one of its transit providers, DQE Communications' AS33154, Allegheny Technologies' AS396531, and Verizon's AS701. Other networks then learned the route through Verizon.
The path is important because the outage did not begin with a failed Cloudflare data center or an application deployment. Cloudflare's machines continued to announce their ordinary aggregate routes. The global routing system simply learned competing routes for smaller pieces of the same address space. Those smaller pieces won the forwarding decision in many networks and directed packets along an unintended path. Congestion and packet loss followed before the requests could reach Cloudflare's edge.
Cloudflare's contemporaneous incident explanation reported that roughly 15% of its global traffic was lost at the worst point. That is a company measurement, not an independently audited universal outage percentage. It describes Cloudflare traffic, not 15% of the entire Internet. Independent observation nevertheless supports the broad mechanism and cross-service impact. ThousandEyes reported in its network-path analysis that users had difficulty reaching Cloudflare-fronted services and some AWS services for roughly two hours, while Catchpoint's incident review recorded performance problems across named online services around 10:30 UTC.
The distinction between route availability and server availability matters to accountability. A platform can operate healthy servers in many countries and still be unreachable if the routing control plane directs traffic elsewhere. Customers experience one outcome: timeouts, errors, and unavailable applications. The engineering cause, however, determines which controls could have prevented the loss and which party could operate them.
Cloudflare's status record for the event first described network performance issues, then identified a possible route leak, and later said the responsible network had fixed it. Public copies of the status updates place the investigation notice at 11:02 UTC, identification at 11:36 UTC, and monitoring after correction at 12:42 UTC. The BGP archive shows abnormal routes before the first status notice. That difference is not proof that Cloudflare ignored a known event for 28 minutes. It is a useful accountability question: when did automated systems detect abnormal traffic, when did engineers identify external routing as the cause, and when did the company have enough confidence to notify customers?
No public evidence shows malicious intent, traffic inspection, or compromise of Cloudflare systems in this event. A route leak can create an interception opportunity, but the observed service harm here was congestion and loss along an unintended path. The article therefore treats the incident as an availability and routing-integrity failure. It does not convert a possible security property of route leaks into an allegation that traffic was read.
How a local optimization became a global route
The Internet is an agreement among autonomous systems rather than a centrally dispatched network. Each autonomous system uses the Border Gateway Protocol, or BGP, to tell neighboring systems which IP prefixes it can reach and through what AS path. The core protocol in RFC 4271 gives operators considerable policy freedom. That flexibility supports commercial peering, paid transit, multihoming, traffic engineering, and local preferences. It also means that a route received from a neighbor is not accompanied by a universal proof that every AS in the path intended the announcement to travel that far.
Before the incident, DQE used a BGP optimization product from Noction. Such a product can measure path performance and inject more-specific routes to influence which link carries selected traffic. In the example Cloudflare published, the normal 104.20.0.0/20 announcement was divided into 104.20.0.0/21 and 104.20.8.0/21. The two /21s cover the same address range as the /20, but each names a smaller destination block.
Inside a controlled network, more-specifics can be a legitimate traffic-engineering instrument. The danger is scope. The routes were meant to influence DQE's internal decisions. DQE announced them to AS396531. AS396531 was connected both to DQE and Verizon and exported the learned routes toward Verizon. Verizon accepted them from its customer and propagated them onward. A local instruction had become a global claim.
Noction's own June 26 incident response acknowledged that its platform generated the more-specifics and described three compounding conditions: generation inside its customer's network, leakage through a downstream ASN to a major provider, and inadequate filtering at all three autonomous systems. Noction argued that creating more-specifics is a common practice rather than an inherent defect and emphasized provider filtering. That response is relevant because it confirms the optimizer's role while disputing a single-party account. It is not an independent postmortem, and it does not publish the precise configuration, change record, or test evidence for DQE's deployment.
Qrator Labs' separate routing analysis associated the start with the re-establishment of the BGP session between AS396531 and Verizon shortly after 10:35 UTC. Its account says AS396531 had lost filters and exported routes learned from DQE. That provides a plausible trigger for why the condition began when it did, but the available public record does not include router configurations or logs from AS396531, DQE, or Verizon. The safe conclusion is narrower: the observable path proves that routes crossed those AS boundaries; operator accounts identify missing or inadequate filters; the exact internal change sequence remains non-public.
This distinction prevents three common errors. First, DQE should not be described as the origin of Cloudflare's address space in the BGP sense. The observed AS path still ended at Cloudflare's AS13335. DQE's optimizer created and propagated a more-specific path with the legitimate origin retained. Second, Verizon did not invent the routes, but its acceptance and global propagation greatly enlarged their reach. Third, Cloudflare's network did not choose AS396531 as a preferred path. Remote networks made forwarding decisions based on advertisements they received.
Why more-specific routes defeated distance and anycast
For a non-specialist, the event can sound as if routers selected a shorter AS path. The decisive preference occurred earlier. Internet forwarding uses longest-prefix matching: a route covering the most specific destination block is selected over a route covering a broader block. RFC 4632, the classless inter-domain routing specification, describes this longest-match behavior and its relationship to aggregate and more-specific routes.
Suppose a router knows that Cloudflare's 104.20.0.0/20 is reachable through a normal provider and also learns 104.20.0.0/21 through Verizon, AS396531, and DQE. A destination inside the first /21 matches both announcements. The /21 is more specific, so it wins even if its AS path is longer or operationally absurd. Normal path attributes decide among routes to the same prefix; they do not make a healthy /20 defeat an accepted /21.
That is why Cloudflare's anycast footprint did not automatically route around the problem. Anycast allows many Cloudflare locations to announce the same prefixes, letting BGP select a suitable instance. It provides geographic distribution and can absorb the failure of individual sites or links. But the leaked /21s were more specific than Cloudflare's ordinary /20 advertisements. The global routing system could prefer the /21 before comparing which Cloudflare anycast location was closest. Redundancy behind the losing route did not restore traffic.
The unwanted path also concentrated load. AS396531 and its connections were not provisioned as global transit for Cloudflare, Amazon, Linode, and the many other affected networks. Traffic attracted by the more-specific advertisements entered a corridor without the capacity or policy to carry it. Packets were delayed or dropped. A route leak can sometimes deliver traffic by an inefficient path; here, the scale turned the path into a bottleneck.
The Internet Engineering Task Force's RFC 7908 route-leak taxonomy defines a route leak as propagation beyond an announcement's intended scope. The June 2019 event combines features that the taxonomy separates for analytical purposes. It involved provider-learned routes exported by a multihomed network toward another provider, which resembles the classic hairpin-turn pattern, and internally useful more-specific routes that were never intended for global propagation. The label matters less than the violated invariant: a customer of Verizon appeared to offer transit to prefixes outside its legitimate customer cone, and Verizon accepted that appearance.
The chronology and the expanding accountability window
Accountability changes as an incident moves from prevention to detection and recovery. The following timeline uses public route data and attributed operator statements; it does not fill gaps with assumed internal actions.
| Time, June 24, 2019 (UTC) | Event | Accountability significance |
|---|---|---|
| Before 10:34 | DQE uses a routing optimizer capable of generating more-specific routes for internal traffic engineering. AS396531 is connected to DQE and Verizon. | Exceptional routes required containment, export policy, customer-route authorization, and propagation testing before an incident existed. |
| 10:34:25 | First studied Cloudflare more-specific appears in archived routing data. | The preventable configuration condition becomes an externally observable global event. |
| About 10:35 | Qrator associates the leak with restoration of the AS396531-Verizon BGP session. | Session establishment and policy attachment become important audit evidence; the claim cannot be verified from public router logs. |
| 11:02 | Cloudflare status reports network performance issues. | Customer communication begins about 28 minutes after the first archived route. The unknown interval between machine detection and confident diagnosis should be measured internally. |
| 11:36 | Cloudflare status identifies a possible route leak affecting some IP ranges. | The response shifts from symptom management to cross-network coordination. |
| During the event | Cloudflare says engineers in several regions were engaged and attempted to contact DQE and Verizon. | Reachable network operations contacts and authority to execute route changes become part of resilience, not administrative housekeeping. |
| Before about 12:39 | Cloudflare reaches DQE; DQE stops advertising the optimized routes to AS396531. | Withdrawal at an upstream source resolves a condition Cloudflare could not directly command. |
| 12:38:54 | Last studied Cloudflare route in the archive ends. | The control-plane event is bounded at a little more than two hours; user recovery can lag as routes converge and sessions retry. |
| 12:42 | Cloudflare status says the responsible network fixed the issue and traffic is improving. | Monitoring continues after route withdrawal rather than declaring recovery at the first change. |
| June 26 | Cloudflare publishes its route-data deep dive; Noction publishes its response. | Public technical evidence improves, while material internal records from three route-handling networks remain absent. |
| August 2019 | Cloudflare's amended registration filing discusses the route leak, service obligations, and expected financial effect. | Operational harm becomes a customer-contract and investor-disclosure issue. |
The most consequential period began before the first timestamp. If a board starts its review at 10:34, it will focus on alerting and calls. If it starts when optimizer routes were authorized for production, it can examine design safety, route scope, fail-closed defaults, peer policies, change review, and independent propagation tests. Incident response reduced duration. Preventive controls determined whether there was an incident to respond to.
Four filtering opportunities failed in the same direction
The route crossed several boundaries, each with a different opportunity to stop it. Treating those opportunities as layers clarifies responsibility without pretending that all parties had equal control.
Optimizer and originating network containment. DQE controlled the environment in which Noction's product generated more-specifics. Routes intended only for local decisions needed an export barrier that did not depend on every downstream behaving correctly. Options included tightly scoped export policy, a dedicated routing context, explicit communities interpreted by every exit, automated checks from external collectors, and a kill switch tied to unexpected propagation. Noction says it performed deployment tests and discusses use of NO_EXPORT, but also argues that NO_EXPORT is not appropriate in every multi-AS design. The well-known community is defined in RFC 1997: a route carrying it should not be advertised outside a confederation boundary. Whether it was used, preserved, removed, or never attached in this event is not established publicly.
Multihomed-customer export control. AS396531 should not have offered one provider's full or optimized routes to another provider unless it intentionally operated as transit. A leaf or enterprise network can apply a simple outbound rule: advertise only its own authorized prefixes and explicitly approved customer prefixes. A default deny is more reliable than trying to identify every route that must not leave. RFC 8212, published in 2017, codified default external-BGP rejection when no explicit import or export policy is configured. It cannot prevent an operator from attaching a wrong permissive policy, but it removes one class of accidental propagation caused by an absent policy.
Provider customer-ingress control. Verizon had the highest-leverage stopping point. A transit provider knows which session is a customer session and should know what that customer is authorized to originate or transit. Cloudflare's deep dive found that the route registry information associated with the customer did not include Cloudflare's ASN or the other leaked networks. A customer-specific prefix and AS-path filter could therefore have rejected the announcements. The BGP operations and security guidance in RFC 7454, published in 2015, recommends policies for routes received and advertised at every border, customer prefix controls, AS-path filtering, and maximum-prefix limits.
Downstream and peer rejection. Networks receiving the routes from Verizon also had a chance to reject them. Because Verizon is a large transit network, many recipients gave its announcements substantial trust. Some networks using Route Origin Validation would have rejected the affected Cloudflare more-specifics as RPKI-invalid. Others could use route-leak heuristics or peer policies. Yet asking every remote network to catch an error after a major provider distributes it is less efficient than rejecting it on the original customer session. Prevention nearest the policy violation limits propagation before global convergence turns a configuration error into a distributed outage.
These layers were not independent enough. DQE's optimization, AS396531's export, and Verizon's import all relied on correct route-policy configuration. If each layer is manually permissive or built from incomplete customer records, three controls can fail together. A mature assurance program therefore tests the outcome from outside the administrative domain. It does not accept configuration review alone as proof that a route remained local.
RPKI could have blocked these routes, but it is not the whole answer
Cloudflare had begun signing routes and deploying validation in 2018, as described in its RPKI deployment account. A Route Origin Authorization, or ROA, states which autonomous system may originate a prefix and, optionally, the most-specific prefix length it may announce. Cloudflare says its relevant routes authorized AS13335 with a maximum length of /20. The leaked /21s retained AS13335 as their origin but exceeded the authorized maximum length. They were therefore invalid under Route Origin Validation.
The logic is formalized in RFC 6811. A received route is valid if a validated ROA payload covers the prefix, the origin ASN matches, and the route's prefix length does not exceed the ROA's maximum. It is invalid when a covering authorization exists but none matches all required properties. RIPE NCC's origin-validation explanation usefully separates valid, invalid, and unknown states and emphasizes that network operators still decide what policy to apply to those states.
Cloudflare's act of creating ROAs was necessary but not sufficient. A ROA is published evidence, not a remote enforcement command. Verizon or another receiving network had to retrieve validated RPKI data, apply validation to the customer route, and reject invalids. Cloudflare could reject invalid routes entering its own network, but that did not stop third-party networks from sending Cloudflare-bound traffic along a route selected elsewhere. Routing security has a reciprocal structure: an address holder publishes authorization, while other operators make it effective.
For this incident, RPKI was a particularly strong preventive control because the optimizer changed prefix length. It would be wrong to generalize that success condition to every route leak. If AS396531 had leaked Cloudflare's ordinary /20 while preserving AS13335 at the end of the path, origin validation could regard the route as valid. The route would still violate the expected provider-customer topology. RPKI origin validation answers who may originate a prefix and at what length. It does not prove that every transit relationship in the AS path is authorized.
This boundary is not a criticism of RPKI. It is the reason to deploy it with other controls. NIST's SP 800-189 guidance combines RPKI and BGP origin validation with prefix filtering and broader interdomain-resilience practices. It treats route leaks, hijacks, traffic detours, denial of service, and performance degradation as related operational risks requiring layers. The June 2019 event is an unusually concrete demonstration: one layer could have rejected the exact bad prefixes, while basic customer filtering could have rejected the implausible authority path even without cryptography.
There is also a governance lesson in maxLength. An overly permissive ROA can make unauthorized more-specifics appear valid; an overly restrictive or stale ROA can cause legitimate routes to be rejected. ROA coverage, maximum length, expiry, key and repository health, and planned routing changes need change control. A dashboard showing that ROAs exist is not evidence that they accurately describe production intent.
Path-policy controls after 2019
The standards and policy landscape continued to develop after the outage. Later controls should not be described as if operators could have deployed a finished version in June 2019, but they show how the industry has tried to encode assumptions that were previously implicit.
RFC 9234, published in 2022, introduced BGP Roles and the Only-to-Customer, or OTC, attribute. Neighboring networks can declare whether a relationship is provider, customer, peer, route server, or route-server client. The role agreement and OTC handling allow routers to detect some announcements that cross a relationship boundary in an impermissible direction. In a simplified version of the 2019 path, a route learned from a provider and then sent to another provider should carry evidence inconsistent with a customer-only export. BGP Roles convert some commercial-topology knowledge from an operator convention into protocol-visible state.
Peerlock offers another path-focused approach. The 2020 paper "Flexsealing BGP Against Route Leaks" studied the operator-deployed mechanism, including its ability to stop paths in which a protected large network appears where it should not. Peerlock existed before the paper and before the June 2019 event, but deployment depended on bilateral knowledge and configuration. It is evidence that practical path filters were possible, not proof that a universal off-the-shelf control was available.
Autonomous System Provider Authorization, or ASPA, aims to let an AS publish verifiable provider relationships through the RPKI system. It is promising because many route leaks are path-plausibility failures rather than origin failures. It also demands careful language: ASPA's standards and deployment state have evolved, and partial coverage produces unknown paths. It should be treated as an additional validation signal, not as retrospective evidence that the 2019 participants violated a then-mandatory cryptographic path standard.
Detection also matured. Cloudflare later described its Radar route-leak detection service, which uses routing relationships and observed paths to flag likely leaks. Monitoring reduces time to know and time to coordinate, but it does not prevent a router from accepting the route. A two-hour incident can still impose global harm if the remediation path is a human telephone chain. Detection has to connect to rehearsed action: identify affected prefixes, apply defensive policy where safe, reach authorized operators, publish customer status, verify withdrawals across independent collectors, and watch traffic recover.
The useful control model is therefore cumulative:
- Publish accurate route authority through IRR objects and ROAs.
- Generate customer import filters from trusted data and refresh them safely.
- Default to rejecting routes that lack an explicit policy.
- Enforce customer-cone, AS-path, prefix-length, and maximum-prefix expectations.
- Reject RPKI-invalid announcements at every relevant external ingress.
- Add relationship-aware controls such as BGP Roles, OTC, Peerlock, and, as it matures, ASPA validation.
- Observe propagation from independent external vantage points.
- Maintain continuously tested operations contacts and route-withdrawal authority.
No single item substitutes for the rest. Their value comes from different failure modes.
Allocating accountability without inventing a liability verdict
The public technical record supports responsibility analysis, but it does not contain a court judgment, regulator order, or complete set of contracts allocating legal liability among DQE, AS396531, Verizon, Noction, Cloudflare, and affected customers. No public Verizon root-cause report was located in the record used for this article. The following allocation is therefore operational: who controlled which safeguard and who could reduce which risk. It is not a percentage assignment of damages.
DQE Communications. DQE controlled the network where optimization routes were generated and the relationship through which they reached AS396531. Its highest-value duties were to constrain route scope, test external visibility, maintain correct export policy, and stop the announcements once contacted. Cloudflare credited DQE personnel with helping withdraw the routes. Fast cooperation reduced duration; it does not erase the preventive control failure.
AS396531. The multihomed network was the bridge between providers. Its observable advertisement toward Verizon made it appear to provide reachability for routes learned through DQE. A non-transit enterprise should export a narrow allowlist, not a learned full table. The public record does not identify the engineer, vendor, or change that removed or bypassed filtering, so individual blame would be speculation. Organizational accountability attaches to the design that allowed a session restoration to expose routes outside the enterprise's authority.
Verizon. Verizon's customer-facing import policy was the most consequential unexercised control. A large transit network accepting thousands of routes from a customer should verify authorized prefixes, expected origins and paths, and prefix volume. The route archive shows that Verizon propagated the path. Cloudflare says relevant IRR data and RPKI validation could have rejected it and reports difficulty reaching Verizon during the event. Without Verizon's internal records, one cannot say whether a filter was absent, stale, misapplied, bypassed, or failed in another way. Any of those possibilities points to assurance and incident-coordination duties proportionate to the provider's scale.
Noction. A routing optimizer that can create globally preferred more-specifics has a foreseeable high-consequence failure mode if containment fails. Product accountability includes safe defaults, conspicuous risk warnings, deployment validation, route tagging, external leak tests, rollback, and controls that make intrusive mode difficult to enable without verified boundaries. Noction's response says it tested propagation during deployment and that filters remained compulsory. That claim raises the next audit question: did the product continuously verify containment after peering or session changes, or only at commissioning? A one-time test cannot prove the safety of a dynamic routing environment indefinitely.
Cloudflare. Cloudflare neither generated nor propagated the unwanted paths, and it could not configure Verizon's customer session. It had nevertheless sold customers an availability and security service built on global routing. Its accountability therefore sits in the residual controls: accurate ROAs, diverse interconnection, external route monitoring, rapid diagnosis, reachable peer contacts, customer communication, mitigation options, and transparent disclosure. It also had a duty not to overclaim what its architecture could withstand. Anycast and a large global network reduce many failures but cannot defeat a globally accepted more-specific without help from validating networks.
Other networks. Peers and downstreams that accepted the routes from Verizon were not equally positioned to know AS396531's customer authorization, but they could deploy RPKI validation and path controls. Their decisions affected their own users and, in some cases, further propagation. The system is safer when large transit networks act correctly, yet a receiving network remains accountable for the routes it installs.
This allocation avoids the convenient but unhelpful statement that BGP is based on trust and therefore no one is accountable. Trust is implemented through configurations, registries, contracts, and operating practices. Those are controllable. The protocol's openness explains why a failure can spread; it does not excuse a provider from filtering customer routes.
Cloudflare's business accountability survived the external cause
An external trigger does not remove a cloud provider's obligations to customers. Cloudflare's amended 2019 Form S-1 registration statement said the June route leak caused significant disruption to its traffic and that of other providers. It warned that route leaks could harm reputation and confidence, described service-level commitments that could lead to credits or refunds, and stated that the June route leak and a separate July outage triggered some of those obligations. At the time, Cloudflare did not expect the incidents to have a material effect on results of operations or financial condition.
That disclosure followed an SEC staff comment asking the company to address the reasonably expected financial impact of the June route leak in light of service-level commitments. The exchange is a compact example of accountability moving from the network operations center to corporate reporting. An incident can be externally caused, operationally significant, contractually compensable, and financially immaterial to the provider at the same time.
The filing does not disclose the number of affected customers, total credits, refunds, lost transactions, or customer-level downtime. It also discusses the June route leak alongside Cloudflare's internally caused July 2 web application firewall outage. Those events should not be merged. The June incident tests dependency on external routing. The July incident tests internal software-change controls. Both affected availability, but the preventive owners and evidence are different.
For customers, a service credit is not equivalent to restored business. A small online merchant may lose orders, a communications service may lose sessions, and an enterprise may consume staff hours before a monthly subscription credit is calculated. Contract remedies allocate a fraction of direct provider fees, not the full social or customer cost of downtime. Cloud providers should therefore report more than contractual uptime: reachability by region and network, traffic loss, time to detect, time to identify, time to communicate, and time to stable recovery.
What boards should ask of peering and transit risk
Routing is often treated as a specialist concern below the level of board oversight. The June 2019 event shows why that division is too neat. A BGP import policy at one major provider changed access to many cloud services, triggered customer obligations, created investor disclosure, and exposed concentration outside formal cloud-vendor contracts. The board does not need to choose router syntax. It does need evidence that management knows where availability depends on another autonomous system's behavior.
A useful board package begins with exposure, not compliance claims:
| Evidence area | Board-level question | Useful measure |
|---|---|---|
| Route authority | Are all originated prefixes covered by current, least-permissive ROAs and accurate registry objects? | Percentage of prefixes and address space covered; unauthorized maxLength exceptions; stale-object age |
| Customer filtering | Can a customer advertise only approved prefixes and customer-cone paths? | Percentage of customer sessions on automated allowlists; policy exceptions; last independent test |
| ROV enforcement | Are invalid routes rejected on every external ingress where policy requires it? | Session and traffic coverage, not merely router count; invalid-route alert and rejection tests |
| Route volume | Will an abnormal route count warn or close a session before global propagation? | Maximum-prefix thresholds relative to approved baseline; alert and shutdown behavior |
| External observation | Can the organization see what the Internet sees? | Collector and commercial-vantage coverage; time to detect a test leak; false-positive and missed-event review |
| Coordination | Can another operator reach an authorized engineer at any hour? | Contact validation age; drill success; median acknowledgment and withdrawal-authority time |
| Cloud dependency | What applications fail if a CDN or transit path is unreachable while origins remain healthy? | Critical-service dependency map; tested bypass or alternate path; recovery objective demonstrated in exercise |
| Learning | Did corrective actions change measurable behavior? | Closure evidence for route policy, detection, contact, and customer-communication actions |
The denominator matters in every metric. Saying that RPKI is deployed on core routers does not reveal whether an unvalidated edge session can inject a route into the same network. Saying that customer filters are automated does not show whether the source registry is complete, whether emergency exceptions persist, or whether a new BGP session inherited the policy. Saying that contacts are in a database does not prove that someone answers with authority at 06:30 local time.
Testing should include controlled negative cases. A provider can attempt to announce an unauthorized lab prefix, a prefix longer than its ROA permits, an excessive route count, and a path that violates the declared customer relationship. The expected result should be observed at the receiving policy and at independent collectors. Tests need safeguards so they cannot themselves become leaks, but avoiding all realistic testing leaves the highest-risk behavior unproven.
Customer resilience without simplistic multi-provider advice
Customers often hear that they should avoid dependency by buying a second CDN, a second DNS provider, or a second cloud. Diversity can help, but routing failures do not respect product labels. Two providers may share transit, exchange points, fiber, route collectors, or the same non-validating access networks. A leaked more-specific can also attract traffic before a customer's DNS or application failover logic has a chance to help.
The correct design starts with the service path. Which provider is authoritative for DNS? Where are TLS keys and security policies held? Can an origin safely accept direct traffic? Can traffic be shifted without creating a security bypass? How quickly do DNS caches change? Do clients retain connections? Does a secondary provider have current configuration and capacity? Can the organization tell an upstream-routing failure from an origin failure before it moves traffic?
For some services, active-active delivery across independently routed providers is justified. For others, the complexity, inconsistent security policy, cache behavior, and added attack surface outweigh a two-hour availability gain. A defensible decision records the criticality, tested recovery time, shared dependencies, cost, and residual risk. It does not count vendor names and call the result resilient.
Customers can also use procurement leverage. They can ask a cloud or network provider for ROA coverage, ROV policy, customer-filter controls, MANRS participation, incident-contact practices, external monitoring, and anonymized test results. The MANRS network-operator actions provide a practical frame: filtering, anti-spoofing, coordination, and publication of information others can validate. Membership or conformance is a signal, not proof of flawless operation, but the actions translate routing security into questions a buyer can understand.
The most important contractual question is often not the uptime percentage. It is what evidence and assistance the provider supplies when traffic cannot reach a healthy service because of external routing. Rapid, specific status communication helps customers avoid destructive changes to healthy origins. Post-incident route data helps them reconcile their own observations. A narrowly drafted force-majeure or third-party clause may limit compensation, but it should not end the provider's operational duty to diagnose and communicate.
From voluntary norms to risk-management evidence
The June 2019 event occurred in a largely voluntary routing-security environment. The best practices were not unknown. Prefix and AS-path filtering, IRR data, maximum-prefix controls, RPKI, and operator contact registries existed. Adoption and assurance were uneven, particularly where one network had to bear deployment cost while benefits spread across the Internet.
That collective-action problem later drew more explicit government attention. The U.S. Office of the National Cyber Director's 2024 Roadmap to Enhancing Internet Routing Security describes BGP's inability, in common operation, to validate origin authority, message integrity, remote path information, or announcements that violate neighboring business policies. It calls for stronger adoption of route-origin security, especially among major providers and government-contracted services. The roadmap is policy guidance, not a finding about the 2019 participants.
The Federal Communications Commission's 2024 Secure Internet Routing notice proposed BGP risk-management plans and reporting for broadband providers and sought comment on measures beyond RPKI origin validation. It explicitly recognized that path security requires further work. Again, this does not create retroactive liability for June 2019. It illustrates a governance shift from asking whether a provider supports RPKI in principle to asking for a maintained plan, coverage data, attestation, and progress.
Regulation has its own risks. A percentage target for ROA registration can reward broad, permissive authorizations. A filing requirement can become paperwork disconnected from router policy. Public disclosure of detailed defensive configurations can create security concerns. Effective oversight should therefore focus on outcomes and controlled evidence: accurate authorization, rejection coverage, tested customer policy, exception governance, detection speed, contact readiness, and incident learning. Confidential supervisory access may be appropriate for sensitive details, while aggregate adoption and incident metrics remain public.
The route-security commons also crosses national boundaries. Verizon's propagation affected users and services globally; Cloudflare engineers in several regions participated in response; route authority is distributed through regional registries; and recipients apply their own policy. A national rule can improve the conduct of providers under its jurisdiction, but interoperable standards and operator norms are what make that improvement travel.
The evidence still missing from the public record
Cloudflare's deep dive is unusually reproducible: it identifies RIPE NCC data, provides commands, and shows observed paths and timestamps. That transparency supports high confidence in the route chronology. It does not answer every accountability question.
The following records would materially improve the analysis if the involved operators released them:
- DQE's optimizer configuration, generated-prefix policy, export maps, community handling, and external propagation tests before and after deployment.
- AS396531's BGP policy attached to DQE and Verizon sessions, the session-down and session-up timeline, configuration changes, route counts, and the reason provider-learned routes were eligible for export.
- Verizon's customer onboarding record, IRR or prefix-list source, AS-path policy, maximum-prefix setting, RPKI validation state, alerts, operator response timeline, and explanation for global propagation.
- Noction's deployment checklist, continuous-containment safeguards, alerting behavior, and product changes made after the incident.
- Cloudflare's first internal detection timestamp, alert source, mitigation decisions considered, peer-contact escalation timeline, customer impact by network and region, and corrective-action verification.
- Quantified service credits, refunds, support load, and customer churn attributable specifically to the June route leak rather than the separate July outage.
Their absence does not make the event unknowable. Public BGP announcements are evidence of what networks told one another. Traffic measurements are evidence of service impact. SEC filings are evidence of corporate disclosure and expected materiality. Operator blogs are evidence of attributed explanations. The discipline is to keep those evidence classes separate.
It is also important not to confuse a missing public record with a missing internal record. Verizon, DQE, AS396531, and Noction may have performed extensive reviews that were never published. Cloudflare may hold detailed telemetry not included in its posts. Public accountability is weaker when the evidence remains private, but the article cannot infer that no learning occurred.
A durable accountability standard for route resilience
The June 2019 outage is remembered because a small network became the apparent route to large parts of the Internet. Its deeper lesson is that scale did not create corresponding skepticism. A major transit provider received extraordinary claims from a customer and distributed them; many networks accepted the result; traffic followed protocol rules into an implausible path; and recovery depended on finding people who could withdraw the announcements.
The event was preventable with controls available at the time. DQE could have confined optimization routes. AS396531 could have exported only authorized prefixes. Verizon could have filtered customer announcements with registry, path, prefix-count, and RPKI evidence. Receiving networks could have rejected the RPKI-invalid Cloudflare more-specifics. Better monitoring and contact readiness could have shortened the event. Later standards make some relationship assumptions easier to signal, but they do not turn operational discipline into an optional legacy concern.
Cloudflare's role is more complicated than victim or owner. It was the destination whose reachability was harmed by external decisions. It had already published ROAs suited to rejecting the leaked more-specifics, operated a distributed network, detected the event, coordinated withdrawal, explained the route record, and disclosed contractual consequences. It still owed customers clear status, recovery effort, financial remedies where contracted, and a truthful account of residual routing risk. A provider cannot promise that the rest of the Internet will validate its routes; it can promise to make validation possible, monitor what happens, and respond with evidence.
The final accountability standard is therefore not zero route leaks. No global network can guarantee that every autonomous system will configure every session correctly. The standard is whether each party reduced the risk within its control, tested that reduction from the outside, constrained the blast radius of inevitable mistakes, responded through a practiced coordination path, and produced enough evidence for customers and overseers to verify improvement.
That is what network resilience looks like beyond the edge: not independence from other networks, which the Internet makes impossible, but disciplined limits on how much unverified trust any one route can consume.