Network Working Group L. Melegassi Internet-Draft Catellix Intended status: Informational 28 May 2026 Expires: 29 November 2026 The MVPS Adversarial-Audit Methodology: A Reproducible Discipline for Measurement-Security Internet-Drafts draft-melegassi-irtf-mvps-methodology-00 Abstract The Multi-Vantage Path Snapshot (MVPS) family of Internet-Drafts is built on a single discipline rather than a single algorithm. This document records that discipline as a set of nine machine-checkable meta-invariants (M-1..M-9): every claim is classified as a Theorem, a Design, or a Conjecture; every Theorem traces to a closed basis of twelve imported results (I1..I12); every Conjecture carries a four-field falsification protocol; every draft ships a proof/validator/receipt trio; and an adversarial-audit ledger of eight rounds and forty-four findings is kept, each finding either defended or reclassified. The contribution is offered to the research community as a template that other measurement-security efforts MAY adopt, independent of MVPS's specific mathematics. This document defines no protocol, introduces no wire format, and requests no IANA action. Its claims are themselves validated: scripts/validate_methodology_discipline.py returns exit 0 over the eleven discipline checks and writes evidence/methodology_discipline_receipt.json. 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 29 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Why a Methodology Draft . . . . . . . . . . . . . . . . . 3 1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Three-Class Claim Taxonomy . . . . . . . . . . . . . . . 4 4. The Closed Import Basis (I1..I12) . . . . . . . . . . . . . . 5 5. The Nine Meta-Invariants (M-1..M-9) . . . . . . . . . . . . . 6 6. The Adversarial-Audit Ledger . . . . . . . . . . . . . . . . 7 7. The Proof/Validator/Receipt Trio . . . . . . . . . . . . . . 8 8. Numerical Receipt . . . . . . . . . . . . . . . . . . . . . . 9 9. Applicability Beyond MVPS . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Invariant-to-Check Map (Normative) . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The MVPS family comprises many Internet-Drafts that share neither a single detector nor a single deployment profile. What they share is a discipline: a fixed set of rules for what may be claimed, on what basis, and with what evidence. This document records that discipline so that it can be reviewed, reused, and -- like every MVPS claim -- falsified. The discipline was not designed in advance. It emerged from eight rounds of adversarial audit (labelled K, G, H, W, S, B, L, N) that found forty-four defects across versions 1.0 through 3.0 and the first new-draft candidates. Version 4.0 defends or reclassifies all forty-four. The rules below are the engineering invariants that survived that process. 1.1. Why a Methodology Draft Measurement-security work fails review for predictable reasons: unstated scope, conjecture presented as theorem, thresholds asserted without calibration, and results that cannot be reproduced. Each of the nine meta-invariants in Section 5 targets one such failure mode and replaces it with a check that returns a deterministic verdict. This is a research contribution in the IRTF sense: not a protocol, but a reproducible method. It is documented here so reviewers of any single MVPS draft can see the frame the draft was built in, and so other efforts can adopt the same frame. 1.2. Scope and Non-Goals This document: o records the claim taxonomy, the import basis, the meta-invariants, and the audit ledger; o ships a validator that checks the eleven discipline conditions and emits a numerical receipt. This document does NOT: o prove any MVPS detection theorem (those live in their own proof companions); o assert optimality of any MVPS construction (MVPS is positioned at maturity step 3 of 5; see Section 5, M-9); o define any wire format, code point, or protocol behavior. 2. Terminology Claim: any assertion uttered in the name of MVPS. Claim class: exactly one of Theorem [T], Design [D], or Conjecture [C]. Imported theorem: one of the twelve external results I1..I12 on which MVPS is permitted to stand (Section 4). Trace: a finite chain of substitutions from a Theorem to one or more imported theorems. Falsification protocol: the four-tuple (observable, data source, statistical test plus significance level, current blocker) attached to every Conjecture. Trio: the (proof companion, validator, numerical receipt) triple that backs a submittable draft. The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 3. The Three-Class Claim Taxonomy Every claim MUST belong to exactly one class: [T] Theorem. Proved from the imported results I1..I12 plus the MVPS axioms. A Theorem MUST name its trace (Section 4). [D] Design. An explicit architectural choice. A Design is not falsifiable but MUST be stated, not assumed. [C] Conjecture. An empirical claim that MUST be accompanied by the four-field falsification protocol. A label outside these three (for example, unqualified marketing language such as "unbreakable" or "detects all zero-days") MUST be rejected. The cardinal error of the framework is inflation: stating a Conjecture as a Theorem. Invariant M-4 is the negative control against that error. 4. The Closed Import Basis (I1..I12) MVPS stands on a closed set of twelve published results. No Theorem may depend on anything outside this basis: I1 Lin 1991 -- Jensen-Shannon divergence bounds I2 Mardia-Kent-Bibby -- D^2 ~ chi^2 (Gaussian, known Sigma) I3 Anderson / Hotelling -- T^2 distribution I4 Glivenko-Cantelli -- empirical CDF convergence I5 Wald 1947 -- SPRT optimality I6 Dempster 1958 -- Mahalanobis geometry I7 Cramer-Rao -- estimation lower bounds I8 McShane-Whitney -- distribution-free bounds I9 Bernstein -- sub-exponential concentration I10 Liggett -- coupling / monotone systems I11 Wilson 1927 -- binomial confidence intervals I12 Minsker / Cohen -- geometric-median max-bias A claim that cannot reduce, by a finite chain, to one or more of I1..I12 is not a theorem; it is an opinion. 5. The Nine Meta-Invariants (M-1..M-9) M-1 EXHAUSTIVE CLASSIFICATION. Every claim maps to exactly one of {Theorem, Design, Conjecture}; any other label is rejected. M-2 IMPORT COMPLETENESS. The import registry is exactly I1..I12, each named to a published result. M-3 THEOREM TRACEABILITY. Every Theorem names a trace into I1..I12. M-4 NO INFLATION. A claim with no valid trace MUST NOT be admitted as a Theorem. M-5 LEDGER COMPLETENESS. The audit ledger covers eight rounds and forty-four findings (35 + 3 + 6), each defended or reclassified. M-6 FALSIFIABILITY. Every Conjecture carries the four-field falsification protocol. M-7 TRIO PRESENCE. Every draft declaring a validator has that validator on disk; the receipt corpus is commensurate with the validator corpus. M-8 COMPANION PRESENCE. The methodology's companion documents are present (the Ten Commandments, the methodology proof, the v4.0 catalogue, the foundations registry). M-9 HONEST MATURITY. The ladder Exist -> Prove -> Calibrate -> Harden -> Optimize is declared; MVPS is positioned at step 3 (Calibrate). Optimality language MUST NOT be used until a step-5 dominance proof exists. Each invariant maps to one or more validator checks; the map is normative and appears in Appendix A. 6. The Adversarial-Audit Ledger The ledger records every audit finding and its disposition. A finding is "defended" when v4.0 implements the corrected mathematics, or "reclassified" when the claim is demoted from Theorem to Design or Conjecture. +--------------+--------------------------+----------+--------------+ | Rounds | Series | Findings | Disposition | +--------------+--------------------------+----------+--------------+ | K,G,H,W,S,B | v1.0-v3.0 (six rounds) | 35 | all defended | | L | cross-draft reconcile | 3 | L_DL; L_LT; | | | | | demote R-NVD | | N | two new-draft rounds | 6 | L_ORB.*; | | | | | L_ZD.* | +--------------+--------------------------+----------+--------------+ | TOTAL | | 44 | 44/44 pass | +--------------+--------------------------+----------+--------------+ The master validator scripts/validate_v4_against_all_attacks.py records, per finding, the original attack and the v4.0 mechanism that defends it, and returns 44/44. 7. The Proof/Validator/Receipt Trio A draft is submittable only when it ships a trio: o a proof companion (the closed-form mathematics, with each claim classified per Section 3); o a validator (a script that checks the proof's numerical and structural claims and returns exit 0); o a numerical receipt (a JSON artifact emitted by the validator, carrying platform metadata and a self-hash for reproducibility). Invariant M-7 checks that every draft declaring a validator has that validator present, and that the receipt corpus is commensurate with the validator corpus. The trio is what makes a claim reproducible by a third party with no access to the authors. 8. Numerical Receipt The methodology is subjected to its own discipline. The validator scripts/validate_methodology_discipline.py evaluates eleven checks covering M-1..M-9 and writes evidence/methodology_discipline_receipt.json. At time of writing all eleven checks PASS: M-CLASS-1, M-TRACE-1, M-TRACE-2, M-NOINFLATE-1, M-AUDIT-1, M-AUDIT-2, M-FALSIFY-1, M-TRIO-1, M-TRIO-2, M-DOC-1, M-PROGRESS-1. The receipt records the claim classes, the I1..I12 registry, the eight audit-round labels, the forty-four finding total, the maturity ladder, the count of draft validators discovered, and a SHA-256 of its own canonicalized body for tamper-evidence. The receipt is in turn bound by the MVPS Proof Envelope [I-D.melegassi-ippm-mvps-proof-envelope]. 9. Applicability Beyond MVPS The discipline is independent of MVPS's detector. Any measurement-security effort MAY adopt: o a fixed claim taxonomy with a machine-checked partition, o a closed, named import basis with mandatory traceability, o an adversarial-audit ledger with defend-or-reclassify dispositions, o a falsification-protocol requirement for every empirical claim, o a proof/validator/receipt trio regenerable in continuous integration. These five elements are the transferable contribution. 10. Security Considerations This document defines no protocol and therefore introduces no new attack surface. Its security relevance is indirect but real: the discipline is what prevents a measurement-security framework from making unfalsifiable detection claims that operators might rely on. The "no inflation" invariant (M-4) and the falsification requirement (M-6) are the load-bearing controls; without them a framework can silently overstate what it detects. The numerical receipt carries a SHA-256 of its canonicalized body and is bound by the MVPS Proof Envelope [I-D.melegassi-ippm-mvps-proof-envelope], so a reader can detect post-hoc tampering with the recorded verdicts. 11. IANA Considerations This document has no IANA actions. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 12.2. Informative References [I-D.melegassi-ippm-mvps-proof-envelope] Melegassi, L., "MVPS Proof Envelope: Tamper-Evident Binding of Proofs, Validators, and Receipts", draft-melegassi-ippm-mvps-proof-envelope-00, May 2026. [I-D.melegassi-ippm-mvps-latency-reconciliation] Melegassi, L., "MVPS Detection-Latency Reconciliation", draft-melegassi-ippm-mvps-latency-reconciliation-00, May 2026. [MVPS-V4] Melegassi, L., "MVPS Mathematical Existence Proof v4.0", May 2026. [TEN-CMDS] Melegassi, L., "The Ten Commandments of MVPS", May 2026. Appendix A. Invariant-to-Check Map (Normative) The validator scripts/validate_methodology_discipline.py implements the following map. A draft conforms to this methodology iff all listed checks return PASS. M-1 EXHAUSTIVE CLASSIFICATION -> M-CLASS-1 M-2 IMPORT COMPLETENESS -> M-TRACE-1 M-3 THEOREM TRACEABILITY -> M-TRACE-2 M-4 NO INFLATION -> M-NOINFLATE-1 M-5 LEDGER COMPLETENESS -> M-AUDIT-1, M-AUDIT-2 M-6 FALSIFIABILITY -> M-FALSIFY-1 M-7 TRIO PRESENCE -> M-TRIO-1, M-TRIO-2 M-8 COMPANION PRESENCE -> M-DOC-1 M-9 HONEST MATURITY -> M-PROGRESS-1 Eleven checks, nine invariants. The receipt records the verdict of each check and a self-hash of its canonicalized body. Author's Address Leonardo Melegassi Catellix Brazil Email: melegassi@catellix.com