Skip to content

test(reassembly): empirically characterize anomaly-threshold false-positive rates against a labelled corpus #101

Description

@Zious11

Summary

The TCP anomaly thresholds — overlap_alert_threshold=50, small_segment_alert_threshold=100, out_of_window_alert_threshold=100 (src/reassembly/config.rs:125-129) — are conservative engineering defaults. They are CLI-overridable with Snort-aligned ranges (src/cli.rs:77-106) and the module doc states plainly they are "conservative engineering defaults, not values calibrated against prior art." There is no published false-positive / true-positive characterization for them.

Context (develop @ 0082a0c)

  • Defaults confirmed in src/reassembly/config.rs.
  • Real NIDS punt this to the operator: Snort stream_tcp.overlap_limit and small_segments both default to 0/disabled; Suricata reassembles-then-inspects; Zeek ships no small-segment notice. There is no industry "calibrated value" to match.
  • wirerust shipping enabled + conservative defaults + full tunability + documented rationale is more opinionated than the prior art, not less.

What this issue tracks

This is not "the thresholds are wrong" — it is empirical-characterization debt. An analyst currently cannot reason about expected noise from the defaults. Build or obtain a labelled benign+adversarial capture corpus, measure FP/TP rates per detector, then either confirm the defaults or document measured guidance.

Severity

Low. Tracked known-limitation; not a blocker. (Originally lesson P2.05 / STATE.md drift item 1.)


Validated by the research agent per policy DF-VALIDATION-001 (.factory/policies.yaml). Verdict: VALIDATED (as known-limitation) against develop @ 0082a0c.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttestTest coverage

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions