96 lines
3.1 KiB
Markdown
96 lines
3.1 KiB
Markdown
# Phase 1: Capture and Classification - Discussion Log
|
|
|
|
> **Audit trail only.** Do not use as input to planning, research, or execution agents.
|
|
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
|
|
|
|
**Date:** 2026-03-25
|
|
**Phase:** 1-capture-and-classification
|
|
**Areas discussed:** Protocol mapping, Privilege model
|
|
|
|
---
|
|
|
|
## Protocol mapping
|
|
|
|
### Q1: How granular should protocol classification be?
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Port-aware | ICMP, DNS (53), HTTPS (443), HTTP (80), SSH (22), other-TCP, other-UDP — 7 classes | |
|
|
| Protocol-only | ICMP, TCP, UDP, DNS — 4 broad classes, simpler but less distinctive | |
|
|
| Deep port map | ICMP, DNS, HTTPS, HTTP, SSH, SMTP, NTP, DHCP, other-TCP, other-UDP — 10+ classes | ✓ |
|
|
|
|
**User's choice:** Deep port map
|
|
**Notes:** User wants maximum sonic variety from the classification layer.
|
|
|
|
### Q2: Should the classifier be extensible or hardcoded?
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Hardcoded table | Map in code: port/proto → class name. Simple, fast | |
|
|
| Config-driven | Rules in a Go map/struct that could later be loaded from file | ✓ |
|
|
| You decide | Claude picks the approach | |
|
|
|
|
**User's choice:** Config-driven
|
|
**Notes:** Extensibility for future custom mappings.
|
|
|
|
### Q3: How should unknown traffic be labeled before Phase 3 auto-clustering?
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Single "unknown" | All unrecognized traffic grouped as one class | ✓ |
|
|
| Unknown by proto | "unknown-tcp" and "unknown-udp" as separate buckets | |
|
|
| You decide | Claude picks | |
|
|
|
|
**User's choice:** Single "unknown"
|
|
**Notes:** None.
|
|
|
|
---
|
|
|
|
## Privilege model
|
|
|
|
### Q1: Which platforms should be supported?
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Linux only | Simplest — CAP_NET_RAW or sudo | |
|
|
| Linux + macOS | macOS uses BPF devices, different privilege model | ✓ |
|
|
| All major | Linux + macOS + Windows — significantly more work | |
|
|
|
|
**User's choice:** Linux + macOS
|
|
**Notes:** None.
|
|
|
|
### Q2: How should the tool handle insufficient privileges?
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Detect and guide | Detect OS, show platform-specific fix instructions | ✓ |
|
|
| Just suggest sudo | Simple 'try running with sudo' message | |
|
|
| You decide | Claude picks | |
|
|
|
|
**User's choice:** Detect and guide
|
|
**Notes:** Platform-specific actionable error messages.
|
|
|
|
### Q3: Static or dynamic linking?
|
|
|
|
| Option | Description | Selected |
|
|
|--------|-------------|----------|
|
|
| Static preferred | Single binary, no libpcap needed at runtime | ✓ |
|
|
| Dynamic is fine | Users install libpcap-dev | |
|
|
| You decide | Claude picks based on what's practical | |
|
|
|
|
**User's choice:** Static preferred
|
|
**Notes:** Aligns with single-binary distribution goal.
|
|
|
|
---
|
|
|
|
## Claude's Discretion
|
|
|
|
- CLI output formatting (stderr layout, colors, table width)
|
|
- Default time window duration
|
|
- Default interface selection when `-i` omitted
|
|
- Verbose output format and detail level
|
|
|
|
## Deferred Ideas
|
|
|
|
None — discussion stayed within phase scope.
|