ADR 0024 — MÓDULO SPAN.Art — Line-Rate Packet Capture¶
- Status: Accepted (formalized 2026-05-12 with v3.7.0 — TS bridge scaffolds Wave 4-5; SPAN-1 Go libpcap ingress shipping 2026-05-13 Tier-3 batch G at
pkg/span-collector/; SPAN-2..5 shipped 2026-05-13 Tier-3 batches H/I/J/K + SPAN-5a IPv6 polish batch L. 3-way fusion evolution proposed in ADR 0034 — SPAN-7 wave (#688 ADR merged, #689 backend merged). DUT Inspection Effectiveness Validation 6-pillar strategy proposed in ADR 0035 — SPAN-7c + SPAN-8 + SPAN-9 waves (100% materialized in v3.9.0). 6th ingest tier (T6 — inline bypass NIC tap) proposed in ADR 0036 — HyperBridge.Art wave.) - Date: 2026-05-10
- Deciders: TLSStress.Art project
- Targets: v5.x (Phase 1 Materialization scaffolds: SPAN-1..5 partially done Wave 4)
- Patent claim family: claim #16
Context¶
The bench has rich telemetry from SYSLOG and FLOW collectors but no first-class packet-capture path. Customers asked for: 1. Cross-vendor TLS metadata extraction — JA3/JA4 fingerprints, cipher suite negotiation observed on the wire (NGFW logs are vendor-specific; SPAN gives ground truth) 2. DUT validation triangulation — comparing what the DUT logged (Syslog) with what actually crossed the wire (SPAN) catches NGFW misclassification + dropped logs 3. Discovery Hub source #6 — richest URL source for PURE Test Kind (full TLS SNI / HTTP Host visible)
Decision¶
Introduce MÓDULO SPAN.Art as the line-rate packet-capture MÓDULO
at OOBI slot .230. Tiered ingest path (libpcap → AF_XDP → DPDK →
SmartNIC) lets a single MÓDULO scale from 1 Gbps lab to 100 Gbps
edge.
5-tier ingest¶
| Tier | Backend | Capable bandwidth | When to use |
|---|---|---|---|
| T1 | libpcap | up to 1 Gbps | dev, lab, single-tenant |
| T2 | AF_XDP | 1-10 Gbps | mid-bench (most customers) |
| T3 | DPDK | 10-40 Gbps | large bench, dedicated NIC |
| T4 | SmartNIC offload | 40-100 Gbps | enterprise, NIC-side filtering |
| T5 | switch SPAN port | 100+ Gbps | external collector, SPAN ingress over copper |
Operator picks tier at install via the LDS wizard (Phase 5 capacity check). Misconfigured tier → preflight check warns + suggests next viable tier.
Function set¶
SPAN.Art collector
├ packet ingress (T1-T5)
├ TLS metadata extractor
│ ├ JA3 fingerprint (ClientHello)
│ ├ JA4 fingerprint (ClientHello + extensions)
│ ├ cipher suite negotiated
│ └ SNI / ALPN observed
├ HTTP Host header extractor (TLS-decrypt-aware via NGFW MITM cert)
├ Syslog cross-correlator (compares with SYSLOG.Art records)
├ Discovery Hub source #6 emitter (PURE pipeline)
└ DUT validation report (delta: Syslog vs wire)
Cross-correlation flow¶
SPAN.Art captures packet at line rate
↓
TLS metadata extracted in-line (JA3/JA4/cipher/SNI)
↓
SYSLOG.Art receives matching log from NGFW (out-of-band)
↓
SPAN cross-correlator compares:
├ same flow? same source? same dest?
├ DUT classification matches observed traffic?
└ DUT logged the flow at all? (drop detection)
↓
Validation report emitted to FLOW.Art TSDB
Discovery Hub integration (per ADR 0021)¶
SPAN is source F in the 8-source Discovery Hub. Richest source because: - Full TLS SNI visible (Syslog often truncates) - Full HTTP Host header (when DUT decrypts) - ALPN (h2 / h3 / etc.) observable - No NGFW-side log throttle limit
For PURE, SPAN-derived URL set is preferred when bandwidth allows (T2+ tier).
Architecture¶
Slot allocation (per ADR 0019)¶
OOBI slot .230 (single instance — HA via failover to standby SPAN
on slot .231 reserved but not deployed by default).
Performance envelope¶
| Tier | CPU | Memory | NIC | Disk |
|---|---|---|---|---|
| T1 | 2c | 8 GB | 1 Gb | 100 GB SSD |
| T2 | 4c | 16 GB | 10 Gb (XDP-capable) | 500 GB NVMe |
| T3 | 8c (DPDK pinned) | 32 GB hugepages | 40 Gb DPDK NIC | 1 TB NVMe |
| T4 | 8c (SmartNIC offload) | 32 GB | 100 Gb SmartNIC (P4) | 2 TB NVMe |
| T5 | external — bench scrapes from collector | n/a | n/a | n/a |
Consequences¶
Pros¶
- Cross-vendor TLS metadata (JA3/JA4) without vendor-specific parser
- DUT validation triangulation = compelling sales narrative ("we caught your NGFW dropping logs")
- Richest source for PURE Discovery Hub
- Patent moat: SPAN tiered ingest + cross-correlator = claim #16
Cons / risks¶
- T3+ requires DPDK kernel module + hugepages config (operator pain)
- T4 needs SmartNIC ($$) — not many customers have these on-hand
- libpcap (T1) bottlenecks above 1 Gbps — must clearly communicate tier fitness
- Storage retention: PCAP files are large; default retention 7 days for compliance forensics, configurable
Compatibility¶
- Single-node dev benches: T1 only
- Multi-node bench: T2 default, T3+ opt-in
- Existing benches without SPAN: Discovery Hub falls back to other 7 sources
References¶
- Memory:
discuss_cloud_endpoint_span_2026_05_10.md - Code:
k8s/oobi/80-span-art.yaml(SPAN-1 scaffold, Wave 4) - ADR cross-ref: 0019 (OOBI slot allocation), 0021 (Discovery Hub source #6), **0034 (3-way fusion evolution — adds NetFlow input
- operator-configurable source set), 0035 (DUT Inspection Effectiveness Validation — 6-pillar approach across SPAN-7c + SPAN-8 + SPAN-9 waves), 0036 (HyperBridge.Art — adds T6 inline bypass NIC tap, eliminates customer dependency on switch SPAN)**
- Patent claim: #16 (this ADR scaffolds claim #16; ADR 0034
sharpens the adaptive-multi-source element; ADR 0035 extends
with lifecycle correlation +
deny_ineffectiveverdict and proposes two new claim families — Decryption Posture and Fast-Path Detection)