LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

DDoS Mitigation in 2026

22 min read Networking Deep Dives
ddosnetwork-securityanycastscrubbingbgpnetworking
Contents

The uncomfortable truth about distributed denial-of-service defense is that it is fundamentally an arms race of aggregate capacity, and you almost certainly lose it on your own. When a botnet aims 2 Tbps at your single 10 Gbps uplink, no clever firewall rule, no kernel tuning, no autoscaling group saves you — the packets saturate the pipe upstream of anything you control, and your origin goes dark not because it crashed but because the link to it is full of garbage. Modern DDoS mitigation works by inverting that capacity asymmetry: instead of one fat link to one datacenter, the defender presents hundreds of distributed edge locations, each announcing the same IP space via anycast, so that a globally-sourced attack is geographically diluted the instant it leaves the botnet. The largest scrubbing networks now field tens of Tbps of edge capacity precisely because the attacks have crossed into Tbps territory. This post is about the actual mechanisms — the attack taxonomy that determines which defense applies, the BGP plumbing that diverts traffic into scrubbing centers, the GRE tunnels that carry clean packets back, the L7 logic that separates a human from a headless Chrome instance, and the honest costs nobody puts on the marketing page.

The Attack Taxonomy Determines the Defense

There is no single thing called “a DDoS attack.” There are three structurally different categories, and the defense for one does almost nothing against the others. Confusing them is the most common reason a mitigation deployment fails in production.

Volumetric attacks aim to exhaust bandwidth. The goal is raw bits per second, measured in Gbps or Tbps, to fill the victim’s transit links or the links of any intermediate device too small to forward the load. These attacks do not care about your application; they care about your pipe. The defining trait is that mitigation must happen upstream of the saturated link, because once the link is full, anything downstream is already drowning.

Protocol (state-exhaustion) attacks target the finite state tables in stateful devices — the SYN backlog in a TCP stack, the connection table in a firewall or load balancer, the flow table in a NAT. These attacks are often low bandwidth (a SYN flood at a few hundred Mbps can be devastating) because each tiny packet forces the target to allocate a relatively expensive chunk of state. Packets-per-second (pps) is the relevant metric here, not bps.

Application-layer (L7) attacks look like legitimate requests. An HTTP flood issues real, well-formed GET /search?q=... requests, completes the TLS handshake, and asks the origin to do expensive work — a database query, a cache miss, a render. Because each request is individually valid, you cannot drop it on packet inspection alone; you have to make a judgment about intent, which is where false positives live.

Category Example vectors Metric Typical amplification Primary mitigation
Volumetric (reflection/amplification) DNS, NTP monlist, memcached, SSDP, CLDAP, SNMP bps (Gbps–Tbps) DNS ~28–54x, NTP ~556x, memcached ~10,000–51,000x, CLDAP ~56x Anycast dilution + scrubbing, ACLs on UDP source ports
Volumetric (direct flood) UDP flood, ICMP flood, IP fragmentation flood, GRE flood bps / pps none (1:1) Edge rate limiting, fragment drop, scrubbing
Protocol / state exhaustion SYN flood, ACK flood, RST flood, sockstress, fragmented SYN pps none SYN cookies, conntrack tuning, stateless filtering at edge
Application layer (L7) HTTP/1.1 GET/POST flood, slowloris, SSL renegotiation, HTTP/2 Rapid Reset (CVE-2023-44487) requests/sec logic-dependent Rate limiting, challenges, fingerprinting, bot management

The amplification numbers in that table are the whole game for reflection attacks, so they deserve a closer look.

Amplification and Reflection: Turning a Trickle Into a Flood

A reflection attack abuses any UDP service that returns a response larger than the request, combined with the fact that UDP has no handshake and source IPs can be forged on networks that fail to implement BCP 38 ingress filtering. The attacker sends a small query with the victim’s IP spoofed as the source. The server dutifully sends a large response — to the victim. Multiply across thousands of open reflectors and the victim drowns in traffic it never asked for, sourced from legitimate servers the attacker never had to compromise.

The amplification factor is the ratio of response size to request size. A few have been historically catastrophic:

  • DNS — a 60-byte query with EDNS0 and DNSSEC can elicit a response of 3,000+ bytes from an open resolver or an ANY query against a large zone, for roughly 28–54x. There are still millions of misconfigured open resolvers.
  • NTP — the legacy monlist command returns the last 600 addresses the server talked to, ballooning a ~234-byte request into kilobytes, historically ~556x. This drove the 400 Gbps attack on Spamhaus/CloudFlare-era targets in 2014.
  • memcached — UDP-enabled memcached (port 11211) was the worst ever discovered: a few-hundred-byte request could return up to ~750 KB, an amplification of 10,000x to 51,000x. This produced the 1.35 Tbps attack on GitHub in February 2018 and a 1.7 Tbps attack on a Netscout customer days later. The mitigation was largely social: get operators to stop exposing memcached UDP to the internet, and have networks block source port 11211.
  • CLDAP (Connectionless LDAP, UDP 389) — ~56–70x, a persistent favorite because so many directory servers are exposed.

The structural defense against reflection is twofold. First, the internet-hygiene fix that never fully happens: BCP 38 / RFC 2827 source-address validation at the network edge, which would make IP spoofing impossible and kill reflection at the root. Second, the practical defense at the victim’s scrubbing layer: because reflected traffic arrives from a known set of UDP source ports (53, 123, 389, 11211, 1900), it is comparatively easy to filter in bulk — you drop unsolicited UDP from those source ports destined for hosts that never initiated such conversations. The catch is that this filtering must happen on infrastructure large enough to receive the flood without melting, which loops us straight back to anycast.

Anycast: Dividing the Attack by Geography

Anycast is the single most important architectural primitive in volumetric defense, and it works because of a property of BGP routing rather than any DDoS-specific cleverness. The defender announces the same IP prefix — say the /24 containing the protected service’s address — from dozens or hundreds of points of presence simultaneously, all using the same origin AS. Every router on the internet independently selects the topologically nearest announcement. The result is that traffic from a given region is delivered to the nearest PoP, including attack traffic. (For the routing mechanics underneath this, see Anycast Explained and BGP for Engineers.)

This is the key insight: a botnet is globally distributed by design — compromised hosts in Brazil, Vietnam, Germany, Nigeria, the United States. Without anycast, every one of those bots sends its packets to a single datacenter, and the aggregate converges on one link. With anycast, the Brazilian bots hit the São Paulo PoP, the Vietnamese bots hit the Singapore PoP, the German bots hit Frankfurt — the attack is partitioned by the routing fabric itself before any filtering happens. A 5 Tbps attack against a network with 300 PoPs is, on average, a ~17 Gbps problem at each PoP, which is eminently survivable on modern edge hardware.

         BOTNET (globally distributed sources)
   Brazil    Vietnam    Germany    Nigeria    USA
     |          |          |          |         |
     v          v          v          v         v
  ┌──────────────────────────────────────────────────┐
  │   ANYCAST EDGE: same /24 announced from N PoPs     │
  │                                                    │
  │  [São Paulo]  [Singapore]  [Frankfurt]  [Ashburn]  │
  │      |             |            |            |      │
  │  BGP delivers each source to its NEAREST PoP       │
  │  -> 5 Tbps total / 300 PoPs ≈ 17 Gbps per PoP      │
  └──────────────────────────────────────────────────┘
           |  filter at edge (ACLs, SYN cookies,
           |  challenges) -> only clean traffic remains
           v
   ┌────────────────────────────────────────┐
   │  Clean traffic to ORIGIN via GRE/IPsec  │
   │  tunnel or private interconnect          │
   └────────────────────────────────────────┘
                      |
                      v
                ┌───────────┐
                │  ORIGIN   │  (small, single-homed,
                │  server   │   never sees the flood)
                └───────────┘

Anycast also degrades gracefully under capacity loss. If a PoP is genuinely overwhelmed and stops announcing its routes (or is administratively withdrawn), BGP reconverges and that region’s traffic — attack and legitimate alike — shifts to the next-nearest PoP. You lose some performance locality, but the service stays up. This is why anycast networks can absorb attacks that would instantly kill a unicast deployment of equivalent raw capacity: the load balancing is done by the internet, for free, at the routing layer.

Scrubbing-Center Architecture: BGP Diversion, Flowspec, and GRE Return

Not everyone fronts their service with an always-on anycast proxy. Many enterprises run their own IP space and want protection only when under attack — the on-demand scrubbing model — or want their own datacenter traffic cleaned without re-architecting around a reverse proxy. This is the world of NETSCOUT Arbor, Akamai Prolexic, and the on-demand tiers of the cloud providers, and it runs on BGP diversion.

Diversion: pulling traffic into the scrubbing center

Under normal conditions, traffic flows directly to the customer’s origin. When an attack is detected (by NetFlow/IPFIX/sFlow telemetry crossing a threshold), the scrubbing provider announces the customer’s prefix — or a more specific subnet of it — into BGP with better attributes, pulling all inbound traffic for that prefix into the scrubbing center instead of the origin. Because routers prefer the most specific prefix, announcing a /24 when the customer normally announces a covering /22 is a common diversion trick. The traffic now arrives at the scrubbing center, gets cleaned, and the clean remainder is delivered back to the origin.

The granular version of this is BGP Flowspec (RFC 8955), which distributes not just “route this prefix here” but actual match-action filter rules over BGP — match on source/dest prefix, protocol, ports, packet length, TCP flags, and apply an action of drop, rate-limit, redirect to VRF, or mark DSCP. A Flowspec rule that rate-limits all UDP/53 responses to a victim prefix can be pushed to every edge router in an AS in seconds, surgically, without blackholing the whole address. An example NLRI expressed in human terms:

flowspec rule:
  match { destination 203.0.113.10/32; protocol udp; source-port 11211 }
  action { discard }            # drop memcached reflection at the edge

The blunt instrument is Remote Triggered Black Hole (RTBH) filtering, RFC 5635. Here the victim (or its upstream) announces the attacked host as a /32 tagged with a well-known BGP community (commonly 65535:666, the conventional blackhole community) that the upstream’s routers interpret as “set next-hop to the discard/null interface for this prefix.” Every router that honors the community drops all traffic to that host. A typical configuration on the customer edge:

ip route 203.0.113.10 255.255.255.255 null0
route-map BLACKHOLE-OUT permit 10
  match ip address prefix-list BH
  set community 65535:666           # RTBH community honored by upstream
  set ip next-hop 192.0.2.1         # trigger next-hop on local router

The honest problem with RTBH is right there in the mechanism: it completes the attacker’s objective. Blackholing 203.0.113.10 means the attacked host is now unreachable from everyone — the attacker wins, you just chose where the victim dies so the rest of your network survives. It is collateral-damage containment, not mitigation. Destination-based RTBH sacrifices the target to save its neighbors; the more sophisticated source-based RTBH (using uRPF to drop traffic from attacker prefixes) avoids killing the victim but requires reliable attacker-source identification, which spoofed reflection attacks deliberately deny you. RTBH remains the last-resort tool when the attack exceeds your scrubbing capacity and you must protect the rest of the network.

Return path: getting clean traffic back to the origin

Once traffic is scrubbed, the clean remainder must reach the origin, and it cannot simply be re-announced normally (that would just pull it back into the scrubbing center in a loop). The standard solution is a GRE tunnel (or IPsec/private interconnect) from the scrubbing center to the customer’s router. The scrubbed packets are encapsulated and delivered over the tunnel directly, bypassing the diverted BGP path. A Linux-side GRE endpoint looks like:

ip tunnel add gre-scrub mode gre \
   local 198.51.100.5 remote 192.0.2.50 ttl 255
ip link set gre-scrub up
ip addr add 169.254.10.2/30 dev gre-scrub
ip route add 0.0.0.0/0 dev gre-scrub   # clean traffic returns via tunnel

GRE has a real cost: the 24-byte GRE+IP overhead lowers the effective MTU on the tunnel to roughly 1476 bytes, which means you must clamp TCP MSS (commonly to 1436) or suffer fragmentation and PMTUD black holes. Misconfigured MSS clamping on a GRE return path is one of the most common “the scrubbing turned on and now some users can’t load the site” incidents.

Always-on vs on-demand

Always-on (inline) On-demand (BGP-triggered)
Activation Continuous; traffic always traverses scrubber Triggered on detection (minutes of exposure)
Latency cost Constant added latency on every request Zero in steady state; added only during attacks
Time-to-mitigate Effectively instant BGP convergence + detection lag (often 1–10 min)
Best for Internet-facing web apps, high-value targets Whole-network/enterprise prefixes, cost-sensitive
Pricing Higher (you pay to be inline 24/7) Lower base, surge/event fees

The trade-off is exposure versus cost. On-demand is cheaper and adds no steady-state latency, but there is a window — detection plus BGP reconvergence, frequently several minutes — during which the attack reaches the origin unfiltered. For a fast volumetric hit, several minutes is enough to cause a full outage before mitigation even engages. Always-on eliminates the window at the price of paying for inline scrubbing on every byte forever and accepting the latency it adds.

Protocol Attacks and Kernel Hardening

The classic protocol attack is the SYN flood: the attacker sends a stream of TCP SYN packets (often with spoofed sources), the server allocates a half-open connection in its SYN backlog and replies SYN-ACK, and the final ACK never comes. The backlog fills, and legitimate handshakes are refused. The canonical defense is SYN cookies, which let the server encode the connection state into the initial sequence number and avoid allocating state at all until the handshake completes. Relevant Linux sysctls:

# /etc/sysctl.d/99-syn-hardening.conf
net.ipv4.tcp_syncookies = 1          # emit SYN cookies when backlog overflows
net.ipv4.tcp_max_syn_backlog = 4096  # larger half-open queue before cookies kick in
net.ipv4.tcp_synack_retries = 2      # stop retransmitting SYN-ACK to spoofed srcs sooner
net.core.somaxconn = 65535           # accept-queue depth for the listening socket
net.ipv4.tcp_abort_on_overflow = 0   # drop, don't reset, on accept-queue overflow

You can shed obvious abuse cheaply at the edge with a stateless rate limit. With nftables, limiting new TCP connections per source without consuming a conntrack entry per packet:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    tcp flags syn limit rate 200/second burst 50 packets accept
    tcp flags syn drop          # excess SYNs dropped before they hit the backlog
    # ... rest of policy ...
  }
}

The iptables equivalent uses the limit or hashlimit match:

iptables -A INPUT -p tcp --syn -m hashlimit \
  --hashlimit-name synflood --hashlimit-mode srcip \
  --hashlimit-above 50/sec --hashlimit-burst 100 -j DROP

A critical, frequently-missed point: the conntrack table is itself a state-exhaustion target. If you run stateful filtering (ct state / -m state), an attacker who can create connection-table entries faster than they expire can fill nf_conntrack_max and cause the kernel to drop new legitimate connections with nf_conntrack: table full in dmesg. Under volumetric or pps attacks you often want to run the edge filter stateless — match on TCP flags and rate limits without conntrack — precisely so the defense itself cannot be exhausted. This is the deeper reason DIY kernel tuning has a ceiling: every stateful structure you add is a new resource the attacker can target, and none of it helps once the link is full anyway.

HTTP/2 Rapid Reset (CVE-2023-44487)

The most consequential protocol-ish attack of recent years lives at L7 but exploits the transport. HTTP/2 multiplexes many streams over one connection and lets a client cancel a stream by sending RST_STREAM. In the Rapid Reset attack, disclosed in October 2023, the client opens a stream (HEADERS) and immediately cancels it (RST_STREAM), over and over, on a single connection. The server does real work to set up and tear down each stream, but the cancellation means streams never count against the concurrent-stream limit, so the client can churn through enormous request volumes on one connection. Google measured peaks of 398 million requests/second, Cloudflare 201 million rps, AWS 155 million rps — an order of magnitude beyond the prior record, all from comparatively modest botnets. The fix combined patching server stacks to count and penalize excessive resets (NGINX added keepalive_requests tightening and reset accounting; many stacks cap RST-per-connection) with edge mitigation that closes connections exhibiting the abusive churn. It is the cleanest recent demonstration that a protocol feature, not bandwidth, can be the lever. (The QUIC/HTTP3 transport that increasingly replaces HTTP/2 has its own surface; see QUIC and HTTP/3 Deep Dive.)

Layer 7: Where Mitigation Becomes Judgment

L7 floods are the hardest problem because the packets are valid. The defense is a layered funnel that gets progressively more expensive and more intrusive, applied only as suspicion rises.

Rate limiting is the first gate — per IP, per ASN, per path, per fingerprint. NGINX’s limit_req with the leaky-bucket algorithm is the workhorse:

http {
  limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
  limit_req_zone $server_name        zone=persite:10m rate=1000r/s;

  server {
    location /login {
      limit_req zone=perip burst=20 nodelay;   # bursty humans OK, bots throttled
      limit_req_status 429;
    }
  }
}

The honest weakness of IP-based rate limiting is that a real botnet has tens of thousands of source IPs each sending a low per-IP rate, sliding under any per-IP threshold, while a single corporate NAT or mobile carrier CGNAT can put thousands of legitimate users behind one IP. Per-IP limits therefore both miss the attack and punish the innocent — the false-positive engine of L7 defense.

So the funnel adds challenges. A JavaScript challenge serves a small computational/browser-environment test that a real browser passes transparently but a naive HTTP client (curl, a basic Go bot) fails because it does not run JS. A managed challenge (Cloudflare’s term) dynamically picks the least-intrusive check — a non-interactive proof-of-work, a browser-integrity probe, or as a last resort an interactive CAPTCHA — based on the request’s risk score. The escalation chain is roughly: pass silently → JS challenge → managed/non-interactive → interactive CAPTCHA → block.

Underneath the challenges sits fingerprinting and bot management. The defender builds a signal vector: JA3/JA4 TLS fingerprints (the ordered cipher suites and extensions in the ClientHello, which differ between real browsers and tooling), HTTP/2 frame-ordering and SETTINGS fingerprints, header order and casing, the presence and consistency of browser APIs, and behavioral signals (mouse movement, request timing, navigation graph). These feed an ML scoring model that emits a “likely bot” score, and policy decides what to do at each score band. The good bots (Googlebot, Bingbot, monitoring) are allowlisted by verified reverse-DNS or published IP ranges so the bot manager does not strangle legitimate crawlers.

The trade-off is unavoidable and worth stating plainly: every L7 control trades false negatives for false positives. Set the bot score threshold loose and attackers slip through; set it tight and you challenge real users — privacy-tool users, Tor exits, accessibility tooling, older browsers, automation your own partners depend on. A challenge page shown to a paying customer at checkout is a conversion you just lost. There is no setting that is correct for everyone, which is why mature deployments run per-path policies (aggressive on /login and /api, permissive on static assets) rather than one global knob.

How the Big Networks Differ

The major providers solve the same problem with meaningfully different architectures, and the difference matters for what you should buy.

Provider Model Architecture Strengths Notable limits
Cloudflare Always-on reverse proxy Anycast across 330+ cities, every PoP runs full L3–L7 stack; ~388+ Tbps edge capacity Instant mitigation, unmetered L3/4 DDoS even on lower tiers, integrated WAF/bot mgmt You proxy through them (they terminate TLS); origin must be hidden
NETSCOUT Arbor (Sightline/TMS/AED) On-demand + on-prem appliance NetFlow detection (Sightline) + Threat Mitigation System scrubbing; AED is an inline stateless on-prem box Carrier-grade, owns its own IP space, deep telemetry, vendor to many ISPs Appliance + scrubbing center capex/opex; you operate it
Akamai Prolexic On-demand BGP diversion 20+ global scrubbing centers (~20+ Tbps), GRE return, 24/7 SOCC Protects whole prefixes/non-web protocols, strong for enterprise + finance Diversion latency on activation; routes through Akamai scrubbers
AWS Shield Inline at AWS edge Shield Standard always-on at CloudFront/Route 53/ELB; Shield Advanced adds DRT, cost protection, higher SLAs Native to AWS, Standard is free, Advanced gives DDoS cost protection Best for AWS-fronted assets; Advanced is $3,000/mo + data fees

The architectural divide is reverse-proxy always-on (Cloudflare, AWS Shield at the edge) versus network-layer diversion (Arbor, Prolexic). The proxy model is best when your asset is a web app you are willing to front entirely — Cloudflare or CloudFront terminates the connection, so they can apply full L7 logic, but your origin must stay hidden or attackers bypass the whole thing by hitting the origin IP directly (a real and common failure: leaked origin IPs in DNS history, mail headers, or TLS certificates). The diversion model is best when you must protect entire IP ranges, non-HTTP protocols, or infrastructure you cannot or will not reverse-proxy — but it pays the activation-latency tax and the GRE-return complexity. NETSCOUT’s Arbor lineage matters here: a large share of the world’s carriers run Sightline for detection and TMS for scrubbing, which is why ISP-level mitigation often “just works” before your own provider even engages.

The Honest Costs and Why DIY Loses

Every layer of this stack costs something real, and the marketing pages omit most of it.

Scrubbing adds latency. Always-on inline mitigation routes every packet through filtering infrastructure that is, by definition, not the shortest path to your origin. On-demand adds nothing in steady state but adds a detection-plus-convergence window — frequently several minutes — during which a fast attack lands fully on your origin before mitigation engages. You are choosing which cost to pay, not whether to pay one.

False positives block real users. This is not hypothetical. Every challenge page, every aggressive rate limit, every bot-score threshold turns away some legitimate traffic. CGNAT and corporate NAT mean per-IP controls punish shared egress; privacy tooling and older clients fail browser-integrity checks; a tightened threshold during an attack will block customers. The collateral damage is a business cost that rarely shows up in the security team’s metrics but absolutely shows up in conversion.

Always-on protection is priced like insurance you cannot skip. AWS Shield Advanced is $3,000/month per organization with a 1-year commitment, plus data-transfer-out fees on protected resources. Enterprise always-on WAF/bot-management tiers run into five and six figures annually. The pricing reflects reality: maintaining tens of Tbps of globally distributed, always-available scrubbing capacity that sits mostly idle waiting for the bad day is genuinely expensive, and you are buying a share of it.

Blackholing is self-inflicted denial. RTBH, the last-resort tool, completes the attacker’s goal for the targeted host. It protects the neighborhood by sacrificing the victim. Useful, but never confuse it with defense.

And the load-bearing conclusion: you cannot self-host your way out of a volumetric attack. This is arithmetic, not opinion. If a 2 Tbps attack arrives and your transit is 100 Gbps — generous for a single enterprise — the link is 20x oversubscribed and full of attack traffic before a single packet reaches any device you own. No firewall, no eBPF/XDP drop program, no kernel tuning operates on packets that never make it down a saturated pipe; the drop has to happen upstream of the congestion, on infrastructure whose aggregate capacity exceeds the attack. XDP and DPDK absolutely matter for surviving pps attacks at a given node — dropping tens of millions of packets per second in the driver before they touch the stack is real and valuable — but they do nothing about a bps flood that fills the link feeding that node. The only entities with enough aggregate edge capacity to absorb Tbps-class volumetric attacks are the large anycast networks and carriers, and the entire economic logic of buying DDoS protection is renting a slice of capacity you could never justify building. The same capacity-aggregation logic underpins modern content delivery generally; see A Modern CDN, Honestly for the broader picture, and From ARPANET to BGP for why the routing trust model that anycast exploits exists at all.

Verdict

DDoS mitigation in 2026 is fundamentally a capacity-aggregation business wearing a security costume. The defense that matters most — anycast — is not a filter at all but a routing technique that lets the internet itself partition a globally-sourced attack across hundreds of edge locations before any cleaning happens, turning an unsurvivable Tbps flood into a survivable tens-of-Gbps problem per PoP. On top of that sit the genuinely security-flavored layers: bulk filtering of reflection traffic by known UDP source ports, stateless SYN-cookie and rate-limit defenses against state-exhaustion attacks, BGP diversion with Flowspec for surgical filtering and RTBH as the sacrificial last resort, GRE tunnels carrying clean traffic home, and an L7 funnel of rate limits, challenges, and ML bot-scoring that trades false negatives against false positives with no setting that is correct for everyone. The provider you choose comes down to one architectural question: are you willing to reverse-proxy your asset (Cloudflare, CloudFront/Shield — instant always-on mitigation at the price of hiding your origin and paying inline), or must you protect whole prefixes and non-web protocols (Arbor, Prolexic — diversion-based, cheaper at rest but with an activation window)? The honest costs are latency, false positives, real money for always-on capacity, and the collateral damage of blackholing. And the one rule that survives every architecture and every vendor pitch is arithmetic: you cannot self-host your way out of a volumetric attack, because the packets fill the pipe upstream of everything you control. The mitigation has to live where the capacity lives, and for Tbps-class attacks, that is never your datacenter.

Sources

Comments