OVH's 2016 Mirai Attack Made DDoS Scrubbing Capacity an Accountability Test

Summary

OVHcloud has publicly described a September 2016 Mirai attack above one terabit per second. That is an operator-reported peak, not an independent packet-level audit of every target, device or customer impact. [1][2]
Independent research presented at USENIX Security reconstructed Mirai's growth and attack history from several measurement vantage points. It reports that attacks against OVH infrastructure began on 18 September 2016 and places them within a botnet that eventually reached roughly 600,000 infections. [3][4]
The OVH event must not be merged with the separate Mirai attacks on KrebsOnSecurity or Dyn. Similar malware and overlapping infrastructure history do not make separate targets, dates and service effects one incident.
Mirai-infected devices could send traffic directly with ordinary routable source addresses. That differs from reflection-amplification attacks that depend on forged source addresses. Anti-spoofing remains important, but BCP 38 alone is not a complete explanation or remedy for this event. [15][16][19][20]
A hosting provider's meaningful DDoS capacity is not one headline number. It is the ability to observe bit rate and packet rate, distinguish attack traffic, activate filtering or diversion, avoid control-plane overload, preserve a path for legitimate packets and verify service recovery.
Accountability is distributed. Device makers influence credentials, exposed services and update support. Device owners and access networks can detect abnormal outbound behavior. Transit and hosting operators control traffic engineering, filtering, capacity, telemetry and recovery. Law enforcement addresses botnet operators. [5][9][10]
The public record does not disclose OVH's complete scrubbing topology, trigger thresholds, customer count, contractual obligations or loss allocation. Those limits must remain explicit.
The central evidence test is running service: did the mitigation path absorb the actual packet mix, keep clean traffic moving, bound collateral loss and produce records that customers and operators could reconcile?

The number was a warning, not a complete capacity claim

In September 2016, OVHcloud publicly reported an attack above one terabit per second during the first major Mirai wave. Its current DDoS explainer places the episode in the chronology of large attacks, and a later engineering article describes Mirai as the first botnet to generate more than 1 Tbps. [1][2] The number remains important because it marked a change in what compromised consumer devices could direct at hosting infrastructure. It is also easy to misuse.

A peak measured by the attacked operator does not automatically reveal where the traffic was observed, how long the peak lasted, which interfaces saw it, what packet sizes dominated, how many targets were involved or how much traffic reached customer workloads. It does not state whether the figure was measured before or after filtering, at one site or across several, at the border or deeper inside the network. Unless the operator supplies those details, the responsible formulation is narrow: OVH reported a peak above one terabit per second.

That boundary is not pedantry. DDoS engineering depends on the constrained resource. A flood can saturate a physical link, exceed a router's packet-processing rate, overload a filtering platform, exhaust connection state, consume control-plane resources or overwhelm the application after passing every network device. The same bit rate can represent very different packet rates. A million large packets and many millions of small packets ask different work from forwarding hardware.

OVH's later engineering discussion emphasizes packet-rate attacks and the stress they can place on core routers. [2] That material helps define the control surface, but it should not be projected backward as a complete description of the private 2016 network. The public record does not provide every interface counter, line-card limit or filter rule from the event. What it establishes is that both bit rate and packet rate belong in a credible evidence pack.

A capacity claim should therefore answer a sequence of questions. Which resource was measured? Where was it measured? Was the peak sustained? Which mitigation state was active? How much legitimate traffic continued? What became the bottleneck after traffic moved? How quickly did the system return to a stable state? A provider can truthfully report a very large peak while still leaving those operational questions unanswered.

The headline number is best treated as an alert to governance. It tells boards, customers and network teams that ordinary assumptions about attack scale may be obsolete. It does not prove that the provider was prepared, unprepared, negligent or fully resilient. Those conclusions require the operating record.

Independent research establishes the botnet, not OVH's private impact

The strongest independent technical account is the USENIX Security study of Mirai. The researchers reconstructed the botnet's development and attack activity using several data sources and measurement vantage points. Their paper reports that Mirai began launching attacks against OVH infrastructure on 18 September 2016, describes a peak population of roughly 600,000 infected devices and analyzes more than 15,000 attacks over the observation period. [3][4]

That work is valuable because it moves beyond a single company's traffic graph. It connects scanning, infection, command infrastructure and attacks into a measured history. It shows how weakly protected Internet-connected devices could be recruited at global scale and used as distributed traffic sources. It also provides a firmer basis for separating Mirai's direct botnet behavior from later narratives that collapse all large DDoS events into one generic mechanism.

The study does not, however, disclose OVH's complete customer-impact ledger. It does not reveal every mitigation threshold, internal network path, private packet sample or commercial obligation. It cannot tell readers which individual OVH customers were unreachable, for how long, or what losses they incurred unless those facts appear in another reliable source. It also does not establish that every infected device participated in every attack.

This difference between botnet reconstruction and victim-side operations is essential. The researchers could observe important parts of Mirai's ecosystem. OVH controlled the private network state, customer telemetry and mitigation decisions. Device owners and access providers held still other evidence. No single source contains the entire chain.

The public account must also keep incidents separate. Mirai was used against KrebsOnSecurity, OVH and later Dyn, among other targets. The malware family and some operators were related, but the targets, dates, traffic paths and service dependencies differed. The Dyn event became an authoritative-DNS continuity case. The OVH episode is a hosting and mitigation-capacity case. Combining them would create a larger story at the cost of a less accurate one.

The US Department of Justice later announced guilty pleas involving Mirai's creators. [5] That source can support the narrow statement that identified defendants accepted criminal responsibility for conduct involving Mirai. It should not be used to infer the identity of every person who directed traffic at OVH, the intent behind every observed packet or the culpability of device owners and networks along the path.

Good accountability writing therefore layers the evidence. Operator sources support attributed measurements and operational claims. Independent research supports the botnet chronology and mechanics. Government records support bounded legal facts. Standards and guidance explain controls. None should be stretched to fill gaps held by another actor.

Mirai traffic and reflection traffic are different control problems

The distinction between direct botnet traffic and reflection-amplification determines which controls can work. A reflection attack sends a request with the victim's forged source address to a third-party service. The service produces a response, often larger than the request, and sends it to the victim. Source-address validation can stop the forged request near its origin, while closing or restricting the reflector removes the amplification service.

Mirai did not need that structure for its core attack capability. Infected cameras, recorders and other devices could send traffic directly toward a victim using their real routable addresses. The traffic was distributed because many compromised devices participated, not because every packet was reflected through an innocent server. The USENIX study describes this botnet architecture and its attacks. [3][4]

This is why BCP 38 is relevant but not sufficient. RFC 2827 describes ingress filtering intended to restrict packets with forged source addresses. RFC 3704 expands the operational discussion for multihomed networks, where legitimate asymmetry makes simplistic reverse-path checks dangerous. [15][16] MANRS supplies practical anti-spoofing guidance, and RFC 7039 describes source-address validation improvements. [19][20]

Those controls reduce attacks that depend on spoofing. They also improve attribution and limit some forms of abuse. They do not prevent a compromised device from sending a direct flood with its assigned address. They do not patch weak credentials, close an exposed management service, increase a victim's packet-processing capacity or ensure that clean traffic survives filtering.

The difference should shape both diagnosis and investment. If traffic is direct, operators need source-distribution analysis, behavioral detection, rate controls, upstream coordination and the ability to block or constrain abusive networks without discarding all traffic from a region or provider. If traffic is reflected, they also need protocol signatures, reflector cleanup and source-validation pressure. A blended attack can require both sets.

NIST's interdomain traffic guidance treats DDoS resilience as a layered practice involving routing security, source-address validation, filtering, remotely triggered black holes, FlowSpec, rate limiting, detection and coordination. [13][14] RFC 4732 similarly presents denial of service as a broad engineering problem and warns that countermeasures can create collateral effects. [17] The lesson is not that every listed tool applied to OVH in 2016. It is that no single control should be promoted beyond its mechanism.

For this article, anti-spoofing belongs in a comparison section and in the wider ecosystem map. It must not be presented as the missing switch that would have stopped Mirai. Accuracy about attack mechanics is itself an accountability control because it determines who can act and what evidence should be retained.

Hosting continuity begins at the edge but does not end there

OVH's central responsibility was the network it operated for customers. A hosting provider facing a distributed flood must observe traffic before it becomes an outage, decide when to activate mitigation, move or filter packets without destabilizing routing, and preserve a path for legitimate traffic. That chain crosses edge routers, backbone links, filtering systems, customer networks, automation and incident command.

Detection starts with telemetry, but not one metric. Interface counters show bit rate and packet rate. Flow records can reveal protocol, ports, source distribution and destination concentration. Router counters show drops, queue pressure and control-plane stress. Scrubbing systems show classifications and actions. Customer probes show whether useful transactions complete. BGP and internal routing data show which path carried the traffic.

Each view has a limit. A traffic spike may be an attack, a software release or a measurement fault. A broad source distribution may reflect a botnet or legitimate global demand. A filter can report millions of drops while customers remain unavailable because the clean path is congested. Application health can look normal in one region while another loses reachability. Accountability requires correlation, not a dashboard screenshot.

The activation decision is equally important. On-demand mitigation can preserve ordinary routing and reduce cost, but it creates a handoff interval. Always-on mitigation removes that specific transition but can add persistent dependency and may still have capacity or classification limits. The responsible choice depends on traffic patterns, threat history, architecture and tested recovery, not a marketing label.

Once mitigation is active, the provider must distinguish unwanted packets from customer traffic. A signature that is too narrow can leave the flood intact. A rule that is too broad can create a self-inflicted outage. Rate limiting can preserve core resources while excluding legitimate high-volume users. Geographic or ASN-level blocking may stop abusive sources but harm users sharing the same network.

Clean traffic then needs a viable delivery path. Filtering at an upstream or scrubbing location does not help if the return connection to the hosting network is undersized, unstable or misrouted. Local filtering does not help if the access circuit is already saturated. A distributed provider must understand whether mitigation capacity, inter-site transport and customer-facing links share a common bottleneck.

The public sources do not disclose OVH's complete 2016 design. This article therefore evaluates the evidence a provider should retain rather than claiming a private topology. The practical standard is whether the path that remained in operation carried legitimate traffic and whether the operator could prove that result.

Bit rate and packet rate expose different bottlenecks

Large DDoS numbers are usually expressed in bits per second because bandwidth is intuitive. A link has a nominal capacity; a flood approaches or exceeds it. Packet rate is less visible to non-specialists, but it can be equally decisive. Every packet must be parsed, classified, queued, forwarded or dropped. Small packets can require far more decisions for the same bit rate.

A router's limits are not one-dimensional. Line cards, forwarding ASICs, fabric bandwidth, buffers, route processors, filter tables and telemetry systems can fail differently. A filter that is cheap for one protocol may be expensive for another. Exporting detailed flow data can itself consume resources during an attack. A mitigation design that tests only aggregate throughput may miss the path that fails under high packet rate.

OVH's later engineering discussion of packet-rate attacks is therefore relevant control guidance. [2] It does not prove which device constrained the 2016 response. It supports a broader lesson: capacity planning needs a matrix of packet sizes, protocols, distributions, destinations and control actions.

Testing should include the transition into mitigation. A system may absorb traffic in a steady state but fail when filters are installed, routes move or telemetry volume spikes. It should include partial failure, such as one unavailable scrubbing site or one congested transit path. It should include legitimate traffic mixed with the flood because a perfect attack-only test does not reveal collateral loss.

The evidence should preserve both limits and assumptions. If a platform is tested to a certain packet rate, record the packet-size distribution, rule set, number of prefixes and logging configuration. If capacity is pooled across sites, explain what prevents one region from consuming the reserve needed by another. If a vendor supplies a figure, distinguish laboratory conditions from production observation.

Boards and customers do not need proprietary configuration to understand the risk boundary. They need to know whether the provider tests the relevant resource, whether activation is rehearsed, whether capacity has independent failure domains and whether service-level evidence is retained. A single terabit figure cannot answer those questions.

Scrubbing must prove clean delivery, not only dropped volume

DDoS mitigation has two outcomes: unwanted traffic rejected and wanted traffic delivered. Providers often emphasize the first because attack volume and drop counts are easy to quantify. Customers experience the second. A clean-traffic path that does not complete useful transactions is not successful mitigation.

Classification can use protocol validity, source behavior, reputation, packet shape, destination context, rate and application knowledge. Each technique has false-positive and false-negative risk. A broad UDP block might suppress an attack while breaking legitimate DNS, voice, gaming or monitoring traffic. A per-source rate limit can punish users behind shared addressing. A challenge mechanism can work for browsers and fail for APIs.

The acceptable rule set depends on the hosted service. A provider serving many customers may not know every legitimate protocol pattern in advance. It needs customer-specific controls, escalation paths and a way to change policy without exposing the backbone. Customers need to supply accurate service expectations and emergency contacts.

Recovery evidence should therefore include synthetic and real service probes. A route can be visible while the origin is unreachable. A TCP connection can succeed while the application fails. A global average can hide regional loss. The operator should test from multiple networks and locations, compare application success with router and scrubbing telemetry, and watch the state after the first apparent recovery.

Collateral effects should be recorded rather than erased by the final status. Which protocols or networks were constrained? Which customers required exceptions? Did a filter protect one target while moving load to another? How long did clean delivery remain degraded after aggregate traffic fell? These records help tune future controls and provide a defensible account to affected customers.

The goal is not to publish every filtering rule. Detailed signatures and thresholds can help attackers. A bounded public report can still state the vector, measured scale, major mitigation action, affected interval, recovery signal and unresolved limits. Protected customer or auditor access can carry more sensitive evidence.

OVH's public material establishes the scale and the need for mitigation. It does not disclose a customer-by-customer clean-delivery result. That absence is a known unknown, not evidence that customers either did or did not remain reachable.

Responsibility starts before the traffic reaches the victim

Mirai turned compromised devices into network infrastructure for an attacker. Responsibility therefore begins before packets reach the hosting provider, but it does not collapse onto one actor.

Device manufacturers and software suppliers control defaults, exposed services, update mechanisms, credential policy and end-of-life support. A unique credential, restricted management interface and reliable update path can reduce compromise. ENISA warned that everyday connected devices could become botnet components. [9] The Commerce and Homeland Security botnet report later called for coordinated action across the technology ecosystem. [10][11]

NIST's IoT DDoS work similarly treats device security and network resilience as linked problems. [12] These sources support a system-level control map. They do not prove that a specific manufacturer knowingly caused the OVH attack or that every infected device shared the same weakness.

Device owners control deployment and maintenance within the limits of the product. They can change credentials, restrict exposure, apply updates and replace unsupported equipment. Some owners may lack technical knowledge or vendor support. That reality affects remedy and incentives, but it does not make exposed devices harmless.

Access networks observe traffic leaving customers and can detect scanning, unusual fan-out or sustained attack behavior. They can maintain usable abuse contacts, notify customers and apply proportionate controls. The public record does not justify naming an access network as knowingly negligent. An address seen in attack traffic does not by itself reveal who controlled the device, whether the address was shared or how the provider responded.

Transit providers can supply capacity, blackholing, FlowSpec or coordinated filtering. Their position may allow them to constrain traffic before it reaches the victim's access links. They also face collateral-risk and authorization questions: a poorly scoped blackhole can remove the service it is meant to protect.

OVH controlled its hosting edge, internal capacity, mitigation activation, customer communication and recovery evidence. That makes it the central operator in this article. It did not control device firmware or every source network. Law enforcement controlled investigation and prosecution, not real-time packet filtering. [5]

Accountability follows practical control. It asks what each actor could reasonably observe and change, what evidence it retained, and how its action affected the next operator in the chain. It does not assign every consequence to the largest brand in the story.

Origin-network evidence must be useful without becoming accusation

Direct botnet traffic creates an evidence problem. The source address may be real, but it can identify a subscriber connection, carrier-grade NAT gateway, enterprise edge or compromised device rather than the person who launched the attack. A provider needs enough information to suppress repeat abuse without turning address data into unsupported attribution.

Useful evidence includes timestamp with timezone, source and destination addresses, protocol, ports, packet counts, byte counts, sampling method, confidence, mitigation action and whether spoofing was assessed. Where lawful and proportionate, a short packet sample or signature can help an origin network distinguish the traffic from legitimate use. Contact information should be current and routed to an operational team.

ASN and IP registry records help identify the network responsible for an address range and the contacts published for it. They are ledgers of delegated resources and operational metadata, not sovereign proof of who generated a packet. A route origin shows which autonomous system announced reachability at a time. It does not identify the infected device owner or prove that the announcing network saw the attack.

This is where the Heng.lu reality layer matters. Registry and routing records are valuable when they are accurate, unique, transferable and connected to running operations. They do not make packets stop. The operational result depends on current contacts, observable traffic, filters, customer communication and continuity controls.

An abuse report should therefore be testable and bounded. The recipient needs enough evidence to find the customer or device. The sender should identify measurement gaps and avoid claiming intent. Both sides should retain the ticket, action and outcome. Repeated reports can reveal a systemic problem; one report may reflect a temporary compromise or measurement error.

Industry norms such as MANRS can define expectations for anti-spoofing and coordination. [20] They are useful because they turn broad responsibility into specific practices. They should not become permission theater in which a badge substitutes for current evidence. An operator should be able to show what filtering and response actually did.

For OVH, origin-network evidence could support notifications and targeted mitigation. The public record does not disclose the complete source-AS set or the degree to which each network responded. Those questions remain for evidence holders.

Mitigation activation needs authority, rehearsal and rollback

The moment an operator changes traffic handling during a major attack is itself risky. New filters can block valid packets. Route changes can withdraw the wrong prefix. A scrubbing path can be unavailable. Concurrent responders can apply conflicting actions. The control design must make speed compatible with bounded authority.

An activation policy should identify who may act, which prefixes and services are in scope, which signals justify action, and which evidence confirms success. Automation can reduce delay, but it should be constrained to approved objects and tested paths. Manual intervention can handle unfamiliar conditions, but responders need rehearsed procedures and one authoritative incident owner.

Before an attack, the operator should test route authorization, sessions, communities, prefix lists, clean return paths and monitoring. It should know whether a partial diversion is possible and how stateful services behave under asymmetric routing. It should exercise the loss of one provider or mitigation site rather than testing only the ideal path.

During an attack, every material change should enter a common ledger. That does not mean a slow approval ceremony while service fails. It means responders can see which action is active, who owns the next step and what must be undone. Read-only observers should be able to verify route and service state without competing for write access.

Rollback deserves the same design as activation. A filter that remains after the attack can silently harm customers. Withdrawing mitigation too early can expose the service to a second wave. The operator needs a stable observation period, staged return and a clear trigger to re-enter mitigation.

RFC 4732 warns that denial-of-service defenses can have harmful side effects. [17] RFC 4948 frames broader Internet security challenges that include distributed responsibility and incomplete incentives. [18] Those standards do not prescribe OVH's private runbook. They support the principle that a countermeasure must be assessed by its operating consequences.

Evidence of rehearsal matters because a plan can be internally consistent and still fail at a real boundary. The route may not be accepted. The clean tunnel may be too small. A customer dependency may bypass filtering. The only persuasive closeout is a completed exercise or incident record showing that the intended path carried service.

A defensible evidence pack separates records from results

The strongest post-incident closeout is not a promise that the same attack can never recur. It is a bounded package showing what happened, which controls changed, how they were tested and what remains unknown.

Control surface	Evidence to retain	Operating test	Important limit
Traffic detection	Interface, flow, packet-rate and service telemetry with synchronized time	Multiple signals identify the flood before hard failure	Sampling and aggregation can hide short or local effects
Capacity boundary	Link, forwarding, filter and clean-path limits under stated packet mixes	Representative load stays within tested resources	Laboratory or vendor figures may not match production
Mitigation authority	Approved prefixes, owners, provider sessions and activation policy	Only intended routes and filters change	Approval does not prove external convergence
Route or traffic diversion	Before/after announcements, external observations and provider acceptance	Intended traffic reaches the mitigation path	Collectors do not see every private path
Attack classification	Protocol, source distribution, packet sample and confidence record	Rules suppress the observed vector	Attackers can change vector; signatures can overblock
Clean delivery	Regional probes, application success, latency and origin health	Legitimate transactions complete during mitigation	Synthetic probes may miss customer-specific traffic
Collateral effects	Dropped legitimate classes, exceptions and customer reports	Harm remains within explicit bounds	Some users may not report failures
Origin coordination	Time-bounded abuse reports, contacts, actions and repeat observations	Source networks can find and constrain compromised devices	Address evidence does not prove human identity or intent
Rollback	Change ledger, owner, criteria and staged return	Normal routing resumes without recurrence	A later attack may require renewed mitigation
Remediation durability	Exercises, exceptions, capacity reviews and current runbooks	Controls continue to pass over time	One successful incident is not permanent proof

This table separates documentary evidence from operating proof. A ticket records intent. A capacity plan records assumptions. An ASN record identifies a routing domain. A filter configuration records a rule. None proves that users completed requests during the attack.

The evidence pack should also distinguish public and protected material. Public disclosure can provide timing, scale, vector, major controls, recovery and unknowns. Customers, auditors or regulators under confidentiality may review detailed topology, thresholds, packet samples, contracts and internal decisions. Security-sensitive material need not be published to be retained and reviewable.

The controlling principle is reconciliation. Interface counters should align with scrubbing telemetry. Route changes should align with external observations. Filtering should align with origin and application health. Customer reports should align with regional probes. Disagreement is not a reason to discard a source; it is a signal to investigate measurement boundaries.

What the public record does not prove

The public record supports a significant Mirai attack against OVH infrastructure and an operator-reported peak above one terabit per second. [1]-[4] It supports Mirai's large distributed population and direct compromised-device traffic. It supports the relevance of layered device, network, routing and mitigation controls. It does not answer every accountability question.

It does not disclose the exact OVH targets, every affected customer, duration of each impact, private scrubbing topology, filter rules, activation threshold, capacity reserve or clean-traffic path. It does not provide a packet-level independent audit of the peak figure. It does not establish financial loss, service credits, contractual breach or a legal standard of care.

It does not identify the complete set of infected devices and origin autonomous systems participating in each OVH attack. It does not show whether any named provider knowingly permitted abuse. It does not establish what each device owner knew or could reasonably change.

Later OVH engineering material helps explain packet-rate and router-capacity concerns. [2] Later NIST, NTIA, ENISA, MANRS and IETF materials explain layered controls. [9]-[20] Those sources should not be treated as proof that a specific control was deployed at OVH in September 2016.

The Justice Department record establishes bounded facts about guilty pleas in Mirai-related cases. [5] It does not prove who ordered every attack observed by OVH or justify attributing every packet to the named defendants.

These limits do not make the incident unusable. They define a responsible thesis. The article can assess the controls a hosting operator and its partners should be able to demonstrate. It cannot manufacture a private postmortem from public summaries.

Questions for operators, customers and reviewers

Hosting and transit operators should ask:

Do traffic baselines include packet rate, bit rate, protocol and service success?
Which component becomes the bottleneck for small packets, large packets and mixed traffic?
Which prefixes, sites and customers can be diverted or filtered independently?
Are mitigation sessions, route authorization and clean return paths exercised?
Can responders see provider capacity and filtering state during the event?
Which legitimate traffic classes are protected from broad rules?
Is there one authoritative owner for activation and rollback?
Can source-network reports be generated with precise, privacy-bounded evidence?
Does recovery require the same systems that may be overloaded?
Are customer and external probes reconciled with internal dashboards?

Device makers and owners should ask:

Are credentials unique and management services restricted by default?
Can devices receive authenticated updates for their useful life?
Is end-of-support status visible before the device becomes unmanaged infrastructure?
Can owners observe unusual outbound scanning or attack behavior?
Is replacement or isolation practical when a device cannot be repaired?

Customers should ask:

What attack sizes and packet mixes has the provider tested under realistic conditions?
Is mitigation always on, on demand or hybrid, and what triggers a transition?
Which customer protocols might be constrained during emergency filtering?
How will the provider demonstrate clean delivery and regional recovery?
What evidence and communication are available after an incident?
Are alternate providers, routes or origins genuinely independent and tested?

Auditors and regulators should ask:

Are capacity claims tied to interfaces, packet mixes, rule sets and dates?
Does the evidence show completed service, not only dropped attack traffic?
Are mitigation authority and rollback bounded to approved resources?
Can private packet or topology evidence be reviewed without unsafe public disclosure?
Do remediation claims have current exercise results and exception records?
Are registry and abuse-contact records connected to actual operational response?

These questions do not demand infinite capacity or zero failure. They test whether the operator can detect a known class of threat, act within controlled authority, preserve essential service and explain the result.

Conclusion: capacity becomes accountable when clean traffic survives

OVHcloud's report of a Mirai attack above one terabit per second remains a landmark in the history of DDoS scale. The independent Mirai study shows how a large population of compromised devices could generate distributed direct traffic. Government, standards and industry sources show why the response must cross device security, source-network operations, transit, hosting, filtering and enforcement. [1]-[20]

The central lesson is not that one provider should have purchased an unlimited amount of bandwidth. No credible network can promise to absorb every conceivable flood. The lesson is that a provider's capacity claim becomes accountable only when it is attached to running evidence.

That evidence includes bit rate and packet rate at named boundaries, a documented mitigation trigger, controlled routing or filtering authority, sufficient clean-path capacity, service probes, collateral-effect records, source-network coordination and a rehearsed rollback. It distinguishes a direct botnet flood from reflection-amplification and applies anti-spoofing where the mechanism supports it rather than as a universal slogan.

Responsibility remains distributed. Device makers can reduce insecure defaults. Owners can patch or isolate devices. Access networks can detect and constrain abnormal outbound behavior. Transit and mitigation providers can supply filtering and capacity. OVH can operate the hosting path and demonstrate recovery. Law enforcement can pursue botnet operators. Each actor should be judged by the control it actually held and the evidence it could produce.

Registry entries, autonomous-system numbers, traffic graphs, capacity plans and incident tickets are important records. They are not the service. The reality layer is whether packets with legitimate work reached the intended destination while hostile traffic was bounded. For a hosting network under DDoS pressure, the proof is not the largest number in the postmortem. It is the clean traffic that continued, the constrained resource that stayed within limits and the recovery record another operator could verify.

Sources

OVHcloud, "What is a DDoS attack?": https://www.ovhcloud.com/en-gb/security/anti-ddos/ddos-definition/
OVHcloud, "The rise of packet rate attacks: when core routers turn evil": https://blog.ovhcloud.com/en/posts/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/
USENIX Security 2017, "Understanding the Mirai Botnet" presentation page: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis
Antonakakis et al., "Understanding the Mirai Botnet": https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf
US Department of Justice, Mirai-related charges and guilty pleas: https://www.justice.gov/archives/opa/pr/justice-department-announces-charges-and-guilty-pleas-three-computer-crime-cases-involving
National Security Telecommunications Advisory Committee, Internet and Communications Resilience report: https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20President%20on%20ICR%20FINAL%20%2810-12-17%29%20%281%29-%20508%20compliant_0.pdf
Akamai, Q3 2016 State of the Internet Security executive summary: https://www.akamai.com/site/en/documents/state-of-the-internet/q3-2016-state-of-the-internet-security-executive-summary.pdf
Akamai, Q3 2016 State of the Internet Security report announcement: https://www.akamai.com/content/akamai/it/newsroom/press-release/akamai-releases-third-quarter-2016-state-of-the-internet-security-report1
ENISA, "The Internet of Things: when your washing machine and blood pressure monitor become a target for cyberattacks": https://www.enisa.europa.eu/news/enisa-news/the-internet-of-things-when-your-washing-machine-and-blood-pressure-monitor-become-a-target-for-cyberattacks
NTIA, Commerce and Homeland Security botnet report announcement: https://www.ntia.gov/press-release/2018/us-departments-commerce-homeland-security-release-report-president-promoting-action-against-botnets
US Departments of Commerce and Homeland Security, botnet report: https://www.ntia.gov/sites/default/files/publications/eo_13800_botnet_report_for_public_comment_0.pdf
NIST, "Mitigating IoT-Based DDoS": https://csrc.nist.gov/pubs/pd/2017/12/14/mitigating-iotbased-ddos/final
NIST, "Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation": https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation
NIST Special Publication 800-189: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
IETF, RFC 2827 / BCP 38, Network Ingress Filtering: https://datatracker.ietf.org/doc/rfc2827/
IETF, RFC 3704 / BCP 84, Ingress Filtering for Multihomed Networks: https://datatracker.ietf.org/doc/rfc3704/
IETF, RFC 4732, Internet Denial-of-Service Considerations: https://datatracker.ietf.org/doc/rfc4732/
IETF, RFC 4948, Internet Security Challenges: https://datatracker.ietf.org/doc/rfc4948/
IETF, RFC 7039, Source Address Validation Improvement: https://datatracker.ietf.org/doc/html/rfc7039
MANRS, Network Guide: Anti-Spoofing: https://docs.manrs.org/docs/network-guide/anti-spoofing/