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

New issue

Open

opened 2026-07-15 04:53:07 +00:00 by vxfemboy · 0 comments

vxfemboy commented

2026-07-15 04:53:07 +00:00

(Migrated from github.com)

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)

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.
Suricata — IDS/IPS with protocol detection + large rulesets, including tunnel/VPN-detection signatures; represents real inline middleboxes. High value.
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.)
tshark heuristic dissectors — we already use tshark for JA4 capture; its protocol classification is a cheap additional lens (tshark -r pcap -q -z ...).
Snort3 + OpenAppID — app-detection stack; another deployed inline engine. Medium.
(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."

## 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."