R9+: multi-engine DPI verification harness (Zeek, Suricata, rustnet, tshark beyond nDPI)

[vxfemboy]

Summary

The anti-DPI verification harness (R9) currently uses nDPI/ndpiReader as its single adversary (the 3a/3c/3d oracles). A single DPI engine is a weak test — real censors and middleboxes run different stacks with different heuristics. "Undetectable against nDPI" is a far softer claim than "undetectable against a panel of independent classifiers." This issue tracks expanding the oracle into a multi-engine DPI verification harness: run the same captured yip traffic (per transport: raw/obf, quic, tls, relay) through N engines and assert none classifies it as a VPN/tunnel/yip (or that it classifies as the cover protocol with no risk flags).

Candidate adversaries (priority order)

1. Zeek (formerly Bro) — the gold-standard network security monitor; deep protocol analysis + the notice framework. What serious operators (and nation-state censors) actually deploy. Highest value.
2. Suricata — IDS/IPS with protocol detection + large rulesets, including tunnel/VPN-detection signatures; represents real inline middleboxes. High value.
3. rustnet (https://github.com/domcyrus/rustnet) — modern Rust real-time network monitor with DPI/protocol identification. Being Rust, it's a natural fit to vendor/integrate, and a good independent lens. (User-suggested.)
4. tshark heuristic dissectors — we already use tshark for JA4 capture; its protocol classification is a cheap additional lens (tshark -r pcap -q -z ...).
5. Snort3 + OpenAppID — app-detection stack; another deployed inline engine. Medium.
6. (Consider) ntopng (nDPI-based, so correlated with #0) and commercial-signature emulation — lower marginal value.

Harness shape

• One capture per transport → fan out to each engine → a per-engine verdict table.
• Gate: for each mimicry transport, NO engine classifies it as VPN/WireGuard/OpenVPN/tunnel/obfuscated; the flow classifies as the intended cover protocol (or Unknown for raw/obf) with no VPN/obfuscation risk flags.
• Pin each engine's version (reproducibility), mirroring the pinned nDPI SHA in integration.yml.
• Publish the multi-engine verdict table to the README benchmark/undetectability section (ties into the README-overhaul + benchmark-CD workstreams).

Scope / placement

Part of the testing-lab workstream (C) / a dedicated "R9+ multi-engine DPI oracle" milestone — NOT a 3c/3d milestone (those add transports/ports; this hardens the verification of all of them). Great HN/funding-story material: "empirically undetectable against a panel of independent DPI engines."