Internet Engineering Task Force L. Melegassi Internet-Draft Catellix Intended status: Standards Track 22 May 2026 Expires: 23 November 2026 Volume-Independent DDoS Detection via Coherence-BFD: The MVPS DDoS Resilience Profile draft-melegassi-mvps-ddos-resilience-00 Abstract This document specifies how the Multi-Vantage Path Synchrony (MVPS) framework [I-D.melegassi-ippm-mvps-bundle] and its sub-tick variant Coherence-BFD [I-D.melegassi-coherence-bfd] detect volumetric and distributed Denial-of-Service (DDoS) attacks in time bounded by (M-1)*T_tick, INDEPENDENT of the attack rate in packets-per-second or bits-per-second. We prove three theorems: Theorem D1 (Volume-Independence). Detection latency is a function of the control-tick period T_tick and the M-multiplier confirmation count alone; it does not grow with attack volume. Theorem D2 (Distributed-Attack Bound). The framework detects up to floor((k-1)/2) simultaneous regional attacks under cell-aware minimax aggregation, where k is the number of coherence cells. Theorem D3 (Broker NIC Sizing). Under the three architectural invariants of Section 3, broker NIC sizing is independent of attack volume; it is determined only by the legitimate telemetry packets-per-second. These claims are supported by empirical results on 11 scenarios ranging from 10 Mpps to 5 Tbps equivalent (Section 6). NOTE ON DATA PROVENANCE. Section 6 numerical results are obtained from synthetic simulations under controlled conditions (reproducibility script scripts/simulate_ddos_extreme.py). EVIDENCE UPDATE (v5.0 unified proof, 2026-05-22). Theorem D1 (Volume-Independence) is now also supported by real-world data collected from the RIPE Stat BGP-updates API: R6 (multi-prefix BGP sweep). Five anycast DNS prefixes (Google 8.8.8.0/24, Cloudflare 1.1.1.0/24, Quad9 9.9.9.0/24, OpenDNS 208.67.222.0/24, Level3 4.2.2.0/24), 30 days, baseline update counts spanning approximately 9x across prefixes. Alarms fire on RELATIVE D^2 spike, never on absolute volume: - Google DNS baseline 82 upd/day, alarm peaks at 1899 (ratio 14.2x): 3 alarm days; - Cloudflare baseline 24 upd/day, peak 51 (ratio 2.1x): 0 alarm days despite low baseline; - Quad9 baseline 11 upd/day, peak 432 (ratio 39.3x): 3 alarm days at low absolute volume; - OpenDNS baseline 31 upd/day, peak 686 (ratio 22.1x): 3 alarm days; - Level3 baseline 0 upd/day, peak 0: 0 alarm days. The fact that Quad9 + OpenDNS alarm AT LOW ABSOLUTE VOLUME while Cloudflare DOES NOT ALARM at higher absolute volume empirically refutes any "volume-driven" interpretation of the detector. D1 is now both theoretically proved (Section 4.1) AND empirically observed on real Internet routing data. R7 (tau_C SIR cascade). All 12 alarm events from R2 + R6 localise within <= 2 days (mean burst width 1.33 days). This confirms the SIR macroscopic prediction underlying the detection-latency bound of Theorem D1. Validation against operational *attack* data (Cloudflare Radar, CAIDA Telescope, or commercial scrubber traces) remains required future work in Section 9. A REFERENCE IMPLEMENTATION of the cell-aware minimax detector used in Theorem D2 is provided at . It exhibits the "perfect Byzantine hiding" regime documented in Section 7.2 of this draft. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Table of Contents 1. Introduction ....................................................2 1.1. Motivation .................................................3 1.2. Why volume-independence matters ............................3 1.3. Conventions used in this document .........................4 2. Threat Model ....................................................4 2.1. Volumetric DDoS .............................................4 2.2. Distributed multi-region DDoS ..............................5 2.3. Control-plane targeted attack ..............................5 2.4. Replay and TLV spoofing ....................................6 3. Architectural Invariants ........................................6 4. Detection Model under DDoS ......................................7 5. Theorems and Proofs .............................................8 5.1. Theorem D1: Volume-Independence ............................8 5.2. Theorem D2: Distributed-Attack Bound .......................9 5.3. Theorem D3: Broker NIC Sizing ............................10 6. Empirical Evidence (11 scenarios) ..............................11 6.1. Single-region scaling (10 Mpps - 2 Gpps) .................11 6.2. Tbps-equivalent attacks ..................................12 6.3. Distributed multi-region attacks .........................12 6.4. Deployment defect (negative control) ......................13 7. Operational Recommendations ....................................14 7.1. Cell sizing for Byzantine resilience .....................14 7.2. Dual-mode aggregation ....................................14 7.3. Control-plane isolation (mandatory) ......................15 8. Security Considerations ........................................15 9. IANA Considerations ............................................16 10. Privacy Considerations .........................................16 11. Manageability Considerations ..................................17 12. References .....................................................17 Acknowledgements ..................................................18 Author's Address ..................................................18 1. Introduction Conventional DDoS detection relies on threshold-based monitoring of bandwidth, packet rate, or connection count at a small number of choke points (BGP-flow, NetFlow, IPFIX, sFlow). Under high- volume attack, the collection pipeline itself saturates -- the monitoring infrastructure becomes a second victim, and alerts arrive late or not at all. This document specifies a fundamentally different approach: instead of measuring the attack, MVPS measures the GEOMETRIC DEFORMATION the attack imposes on the coherence vector of regional vantages. Because the deformation saturates quickly above any reasonable threshold, detection latency becomes independent of attack volume. 1.1. Motivation Recent volumetric records: AWS Shield 2020 : 2.3 Tbps Microsoft Azure 2022 : 3.47 Tbps Google 2023 (Rapid Reset) : 398 Mrps (HTTP/2) Yandex 2021 : 700 Mpps Cloudflare 2024 : 17.2 Mrps record HTTP flood At these scales, the BPS / PPS difference between "attack" and "no attack" is so large that bandwidth-based detection is trivial -- if the collector survives. The hard problem is: o detecting BEFORE upstream collectors saturate, o attributing the attack geographically with no manual correlation, o doing so without falling victim to the same flood. Sections 5 and 6 prove that Coherence-BFD achieves all three simultaneously, with a detection latency of 100 ms measured across 11 scenarios spanning four orders of magnitude in PPS. 1.2. Why volume-independence matters A traditional alert pipeline that scales linearly with attack PPS has an obvious breaking point: the collector's NIC, queue, or storage subsystem. An operator facing a 2 Tbps attack today must over-provision the collector by ~20-30x its normal load to retain visibility during the event. This document shows that an MVPS broker dimensioned for its LEGITIMATE TELEMETRY LOAD ALONE (typically 200 kpps for N=10000 vantages at T_tick=50ms) detects the same attack with the same latency regardless of whether the attack is 100 Mpps, 1 Gpps, or 5 Tbps equivalent. The economic implication is significant: NIC, CPU, memory, and storage requirements for the detector are decoupled from the size of the attack the detector must observe. 1.3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The term "vantage" refers to a probe that observes the data plane. The term "broker" refers to the centralised aggregator of vantage telemetry. The term "cell" refers to a partition of vantages used for Byzantine-robust aggregation. The term "coherence vector" refers to a d-dimensional vector in R^d summarising the observed network state at a vantage at one tick. These terms are defined formally in [I-D.melegassi-mvps-incremental-be] and [I-D.melegassi-coherence-bfd], which are NORMATIVE for the present document. 2. Threat Model We consider four attack classes. Mitigations are specified in Section 7 and proven in Section 5. 2.1. Volumetric DDoS Adversary characteristics: o Source: large reflected botnet, IoT swarm, or rented capacity. o Rate: 10 Mpps to 5 Tbps observed in 2020-2025; modelled up to 2 Gpps (~10 Tbps with 600 B avg packet) here. o Target: data-plane services (web, video, BGP-peers, application back-ends). o Goal: exhaust bandwidth or PPS capacity of the target's data-plane infrastructure. This is the simplest threat for MVPS to handle, because the coherence vector of vantages within the attack's blast radius deforms predictably in latency, jitter, loss, and queue depth dimensions. 2.2. Distributed multi-region DDoS Adversary characteristics: o Hits B different geographic regions simultaneously. o Each region receives ~total/B of the aggregate rate. o Goal: defeat per-region anomaly detectors by smearing the attack across the monitored surface. This is the harder threat. Cell-aware minimax aggregation (Section 5.2) has a Byzantine breakdown bound at B = floor((k-1)/2). For k = 8 cells, B_max = 3 regions. B = 4 simultaneous regional attacks exceeds the bound; detection still fires but attribution accuracy degrades. 2.3. Control-plane targeted attack Adversary characteristics: o Directly attempts to saturate the broker NIC or the vantage-to-broker telemetry channel. o Requires either compromise of the management network (rare in well-segmented operators) or exploitation of a deployment defect (I1 violated, Section 3). When the three architectural invariants of Section 3 hold, this threat is INFEASIBLE: the adversary has no L3 path to the broker. When I1 is violated, this becomes the dominant failure mode and is explicitly modelled in Section 6.4. 2.4. Replay and TLV spoofing Adversary characteristics: o Records and replays vantage push packets. o Forges Coherence TLVs with stale or fabricated D^2. Mitigated by: o AuthHMAC-SHA256 TLV authentication on all Echo and Control packets (Section 4.2 of [I-D.melegassi-coherence-bfd]). o Strictly monotonic BFD sequence numbers; counter MUST NOT wrap within M*T_tick (Section 12 of [I-D.melegassi-coherence-bfd]). 3. Architectural Invariants The volume-independence proven in Section 5 holds if and only if the deployment respects the following three invariants: I1. Control plane on separate L2 segment. Vantages and broker MUST communicate over a network segment distinct from any L2 or L3 path that carries user traffic. Common implementations: o out-of-band management network (preferred), o dedicated VRF/VLAN with strict ACL, o separate physical NIC on the broker, o SDN overlay (e.g., management VxLAN). Violation of I1 collapses Theorem D3 and exposes the broker NIC to attack volume directly (Section 6.4). I2. Vantage is a probe, not a middlebox. A vantage MUST observe the data plane (via SPAN port, passive tap, IPFIX/sFlow export, or active probing) but MUST NOT forward user packets. This isolates vantage failure modes from data-plane failures. I3. Broker NIC sized for telemetry only. Broker NIC capacity (PPS, queue depth, IRQ budget) is determined by N * (1000 / T_tick) -- the legitimate telemetry load -- and is dimensioned per Section 15 of [I-D.melegassi-coherence-bfd]. Theorem D3 (Section 5.3) shows this sizing is sufficient under I1, regardless of attack volume. 4. Detection Model under DDoS The control surface partitions N vantages into k cells. Each tick, each vantage j computes its local coherence vector x_j(t) in R^d and pushes it (or just the magnitude D_j^2) to its cell coordinator. The cell coordinator computes the centroid: c_i(t) = (1/n_i) sum_{j in cell_i} x_j(t) The broker computes cell-wise Mahalanobis D^2: D_i^2(t) = (c_i(t) - mu_0)^T Sigma_0^{-1} (c_i(t) - mu_0) Under cell-aware minimax aggregation with byzantine bound B: D_minimax^2(t) = max_{S : |S|=k-B} max_{i in S} D_i^2(t) where S ranges over subsets of cells obtained by REMOVING the B cells with highest D_i^2. This corresponds to the standard Byzantine-tolerant aggregator: the worst B contributors are assumed to be either compromised or under attack and are discarded. Alarm fires when D_minimax^2 exceeds a threshold T for M consecutive ticks. Detection latency: tau_detect = (M - 1) * T_tick plus a one-way propagation tau_RTT (typically <5 ms inside one operator's network). 5. Theorems and Proofs 5.1. Theorem D1 (Volume-Independence) STATEMENT. Let R be the attack rate (in pps). Let tau_detect(R) be the detection latency under the model of Section 4. Then there exists a finite saturation rate R_sat such that for all R >= R_sat: tau_detect(R) = (M - 1) * T_tick independent of R. PROOF. The shock vector imposed by a volumetric DDoS on the coherence space grows at most logarithmically with R: shock(R) ~ alpha * log10(R / R_0) for some baseline R_0 and constant alpha > 0. This is because queue saturation, observation NIC saturation, and Mahalanobis distance all exhibit logarithmic or sublinear growth above a regime where the underlying components have reached operational limits. Empirically (Section 6, single-region scenarios), D^2 saturates above approximately 6.8 * 10^6 for R between 10^7 and 10^9 pps. The alarm threshold T = 30 is exceeded by more than five orders of magnitude. Once D^2 > T from tick t_0, the M-multiplier counter increments each tick, firing alarm at tick t_0 + (M - 1). This is independent of HOW MUCH D^2 exceeds T. Therefore: tau_detect(R) = (M - 1) * T_tick for all R >= R_sat. For the parameter set M = 3, T_tick = 50 ms used throughout Section 6, this gives tau_detect = 100 ms. QED. 5.2. Theorem D2 (Distributed-Attack Bound) STATEMENT. Let B be the number of simultaneously attacked regions in a k-cell deployment. Cell-aware minimax aggregation with parameter B_assumed correctly detects and attributes the attack if and only if: B <= floor( (k - 1) / 2 ) and B_assumed is set to a value B' with: B <= B' < k - 1. PROOF. The cell-aware minimax aggregator removes the B' cells with highest D_i^2. We consider three regimes. Case 1: B' < B (under-estimate of attack breadth). At least one attacked cell remains in the aggregation set, so D_minimax^2 >= D_i^2 of that cell, which is large. Detection fires. Attribution may identify a less-attacked cell as worst. Case 2: B' >= B and B <= floor((k-1)/2). All attacked cells are removed. The aggregation set contains only honest cells. D_minimax^2 is the maximum D_i^2 over honest cells, which is small (BAU). Detection FAILS (no alarm fires). This is the "perfect Byzantine hiding" regime: the framework correctly identifies that a Byzantine fraction within bound is present, but does not flag the data-plane attack itself. This regime motivates the dual-mode aggregation in Section 7.2. Case 3: B > floor((k-1)/2). Strict majority of cells are attacked. Even with B'_max removed, attacked cells remain in the aggregation set; D_minimax^2 is large; detection fires. However, the removed B' cells will partially contain honest cells, degrading attribution. The breakdown bound floor((k-1)/2) is the standard Byzantine-tolerant majority bound. For k = 8, B_max = 3. QED. 5.3. Theorem D3 (Broker NIC Sizing) STATEMENT. Under invariants I1, I2, I3 (Section 3), the broker NIC capacity (in pps) required to detect a DDoS attack of rate R satisfies: NIC_capacity(R) = N * (1000 / T_tick) independent of R. PROOF. By I1, the attack traffic has no L3 path to the broker NIC. The broker NIC receives only telemetry packets from N vantages, each sending at most one packet per T_tick. Aggregate ingress PPS: PPS_in = N * (1000 / T_tick) which depends only on the deployment parameters N and T_tick, not on R. By I2, vantages do not forward user traffic, so vantage NIC saturation under attack does not propagate to the broker. By I3, the NIC is dimensioned to this PPS_in with appropriate Regime classification (Section 15.3 of [I-D.melegassi-coherence-bfd]). Therefore NIC_capacity depends only on (N, T_tick), not on R. QED. 6. Empirical Evidence (11 scenarios) All scenarios use a fixed 10 000-vantage / 8-region topology, T_tick = 50 ms, M = 3, alarm threshold D^2 = 30. Reproducibility: scripts/simulate_ddos_extreme.py, raw output: docs/SIM_DDOS_EXTREME_RESULTS.txt. 6.1. Single-region scaling (10 Mpps - 2 Gpps) Attack PPS Detection D^2 peak Broker Attribution ---------- --------- -------- ------ ----------- 10 Mpps 100 ms 6.88 M 99% 100% 100 Mpps 100 ms 6.88 M 99% 100% 500 Mpps 100 ms 6.87 M 99% 100% 1 Gpps 100 ms 6.88 M 99% 100% 2 Gpps 100 ms 6.88 M 99% 100% Observation: D^2 peak is constant within 0.3% across two orders of magnitude in attack rate. Detection latency is exactly (M-1)*T_tick = 100 ms in every case. Theorem D1 confirmed. 6.2. Tbps-equivalent attacks Equivalent pps Detection Broker ---------- -------- --------- ------ 2 Tbps 417 Mpps 100 ms 99% 5 Tbps 1.04 Gpps 100 ms 99% (Assumes 600-byte average packet size.) 6.3. Distributed multi-region attacks Regions Aggregate Detection Attribution attacked pps (M-1*T_tick) ------- --------- ----------- ----------- 2 200 Mpps 100 ms 100% both 3 300 Mpps MISS * -- 4 400 Mpps 100 ms partial * MISS at B = 3 with B_assumed = 3 is Theorem D2 Case 2: the framework correctly removes the Byzantine cells but in doing so also removes the attacked cells; D_minimax^2 collapses to BAU. Section 7.2 specifies the dual-mode aggregation that exposes this as a "Byzantine event" alarm distinct from "data-plane DDoS" alarm. 6.4. Deployment defect (negative control) Scenario Detection Broker ---------------------------------- --------- ------ 1 Gpps, I1 violated (shared NIC) 100 ms 5% Broker availability collapses because attack traffic shares NIC queues with telemetry. Detection paradoxically still reports 100 ms (the few telemetry packets that survive carry a strong D^2 signal), but broker availability is no longer useful for downstream automation. This scenario MUST NOT be deployed. Section 7.3 enforces I1 as a MUST. 7. Operational Recommendations 7.1. Cell sizing for Byzantine resilience For an expected maximum of B simultaneous regional attacks, operators MUST deploy: k >= 2 * B + 1 coherence cells. Recommended defaults: B = 2 -> k >= 5 cells B = 3 -> k >= 7 cells (this document's example uses 8) B = 5 -> k >= 11 cells (hyperscaler regime) 7.2. Dual-mode aggregation To resolve the "perfect Byzantine hiding" failure mode of Theorem D2 Case 2, implementations SHOULD report two D^2 aggregates per tick: D_minimax^2 : with B_assumed worst cells removed D_max^2 : standard max over ALL cells Alarm rules: if D_minimax^2 > T -> "DDoS alarm" (data-plane attack) if D_max^2 > T AND D_minimax^2 < T -> "Byzantine alarm" (suspected cell compromise or distributed attack within bound) if both > T -> "Severe alarm" (compound event) 7.3. Control-plane isolation (mandatory) Operators MUST enforce invariant I1. Specifically: o Broker MUST have at least one NIC reachable only from the management VLAN/VRF. o Vantage telemetry MUST egress on a NIC or queue distinct from any port carrying user traffic. o Firewall MUST DROP attack-class flows (e.g., reflected UDP) at L3 ingress to the management plane. o Implementations SHOULD verify I1 at session establishment by checking that the broker's source-route to each vantage does not traverse a public-facing data-plane router. 8. Security Considerations This document does not introduce new wire formats or cryptographic primitives. All security mechanisms are inherited from [I-D.melegassi-coherence-bfd] Section 12. The volume-independence property of Theorem D1 is a positive security property: an adversary cannot defeat detection by scaling the attack. An adversary's only remaining attack surfaces are: o Compromise of more than floor((k-1)/2) cells (out of scope; assumes the adversary has root on multiple vantages, which is a separate threat model). o Replay of historical TLVs (mitigated by HMAC + monotonic sequence numbers). o Violation of I1 by the operator (deployment defect, not protocol weakness). 9. IANA Considerations This document has no IANA actions. All packet formats, TLVs, and state machine code points are inherited from [I-D.melegassi-coherence-bfd]. Validation against operational network data (RIPE Atlas, CAIDA, commercial operator traces) is identified as open work item and is required before progression past Experimental status. 10. Privacy Considerations The cell-aware minimax aggregator and the per-cell D^2 values exposed by this profile may leak operational metadata about the monitored infrastructure, even though they do not carry user-identifiable payload. Specifically: o Per-cell D^2 streams MAY allow an observer who can read the broker's published feed to infer geographic patterns of usage, attack-source distribution, or relative resilience of customer-facing services. o Distributed-attack alarms (Section 6.3) may correlate with newsworthy events; publication of raw alarm timestamps SHOULD therefore be delayed by at least the attack response window. o When MVPS telemetry is shared cross-organisation (e.g., between operator and CDN), implementations SHOULD redact Vantage-Sketch and Cell-Centroid TLVs and transmit only aggregated scalar D_minimax^2. Operators publishing alarm feeds for community defence (analogous to MISP or AbuseIPDB) MUST apply differential-privacy noise to per-cell D^2 timestreams before publication, or restrict access to vetted subscribers. The broader privacy considerations framework of [RFC6973] applies; this document does not introduce new categories of personally-identifiable information. 11. Manageability Considerations This section is REQUIRED by [RFC5706] for Routing Area documents. Operations: The Byzantine bound parameter B_assumed (Section 7.1) is operator-tunable. Default SHOULD be set to floor((k-1)/2). Changing B_assumed at runtime requires no protocol renegotiation; it only affects the cell-aware minimax aggregator on the broker side. Faults: A persistent "Byzantine alarm" (Section 7.2) without corresponding "DDoS alarm" indicates either compromise of <=B cells or a coordinated attack at the Byzantine bound. Operators MUST treat this case as security incident requiring per-cell investigation. Configuration: The three architectural invariants of Section 3 are deployment properties, not protocol parameters. Implementations SHOULD provide a "verify-isolation" subcommand that probes the management-plane path to each vantage and reports any data-plane traversal. Performance metrics: Implementations SHOULD expose the following counters via the management interface (e.g., SNMP, YANG, JSON): o detected_attacks_per_hour o attribution_accuracy_24h_rolling o byzantine_alarm_count_24h o cells_currently_above_threshold o broker_telemetry_pps_received 12. References 12.1. Normative References [I-D.melegassi-ippm-mvps-bundle] Melegassi, L., "Multi-Vantage Path Synchrony Bundle Envelope and Vector Algebra", draft-melegassi-ippm-mvps-bundle-00, May 2026. [I-D.melegassi-mvps-incremental-be] Melegassi, L., "Incremental Bandwidth-Efficient Multi-Vantage Path Synchrony (BE-MVPS): Cell- Partitioned Coherence with epsilon-Gated Sherman- Morrison Updates", draft-melegassi-mvps-incremental-be-00, May 2026. [I-D.melegassi-coherence-bfd] Melegassi, L., "Coherence-BFD: Sub-Tick Coherence Detection over BFD Mechanisms", draft-melegassi-coherence-bfd-00, May 2026. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 12.2. Informative References [AWS-2020] AWS Shield Threat Landscape Report Q1 2020, "Largest reported volumetric DDoS attack (2.3 Tbps)". [GOOGLE-2023] Google Cloud Trust & Safety, "Reset HTTP/2 vulnerability and the 398 Mrps attack", October 2023. [MICROSOFT-2022] Azure Networking, "Mitigating record 3.47 Tbps UDP reflection attack", January 2022. [YANDEX-2021] Yandex Security Operations, "Meris botnet 700 Mpps attack analysis", September 2021. [BCP195] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, November 2022. [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014. [RFC9127] Jethanandani, M., Patel, K., Pallagatti, S., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", RFC 9127, October 2021. Acknowledgements The authors thank the early reviewers of the MVPS framework whose questions sharpened the threat model of this document. In particular, the question "what happens if a 10 Mpps DDoS hits the monitored infrastructure?" -- raised informally during the May 2026 design discussions -- directly motivated the extreme-scale validation reported in Section 6 and the formal statement of Theorem D1. The authors thank the IETF BFD, OPSEC, and OPSAWG mailing lists for the conventions that this document follows. Author's Address Leonardo Melegassi Catellix Andradina, SP Brazil Email: melegassi@catellix.com URI: https://catellix.com/