[reactor] header-obfuscation 入站 de-mux 是 O(peers) keyed-Blake2b 扫描：off-path 垃圾 UDP 可放大为单线程 reactor 的 CPU DoS

[jamiesun]

背景

obfuscate=on 是默认。入站选 peer 时，线缆 key_id 被掩码，selectIngressPeer 无法直接索引，须对每个已配置 peer 的 rx link key 逐一 tryDeobfuscate（每次一趟 keyed-Blake2b headerMask）。命中即停；无人认领的垃圾报文要跑满整个 registry 才静默丢弃。

代码路径：

• src/reactor.zig:588-609 selectIngressPeer（obfuscate 分支 594-600 全量试探；miss → drop_udp_unknown_peer）
• src/reactor.zig:199-209 tryDeobfuscate（每次 crypto.headerMask = keyed Blake2b；错误 key 以 < 2^-24 概率误过预筛）
• src/reactor.zig:179-185 obfuscateHeader
• 放大参数：build.zig:23 MAX_PEERS 默认 32（feat: raise default MAX_PEERS to 32 #166），可配 1..128（feat: configurable MAX_PEERS build option (default 16, max 128) #165）

威胁模型

off-path、无需认证。攻击者只要能把 UDP 报文送达监听端口，即可让单线程 reactor 在丢弃前对每个报文做最多 MAX_PEERS 次 keyed-Blake2b。报文可小至 HEADER_LEN(20)+TAG_LEN(16)=36 字节。AEAD 认证在其后，但扫描发生在认证之前，故认证网关拦不住这笔开销。

实测证据（本机，经 #173 新增的 forward-bench）

arch=x86_64 optimize=ReleaseFast, iters=200000：

peers	cleartext select (obf off)	junk 全扫 (obf on)	每 peer	相对 cleartext
16	5.2 ns	5,489 ns	~343 ns	~1055×
32（默认）	9.8 ns	11,016 ns	~344 ns	~1124×
64	25.1 ns	21,973 ns	~343 ns	~875×
128（max）	45.2 ns	43,898 ns	~343 ns	~971×

线性 ~343 ns/peer。对照同轮 AEAD floor（seal/open ≈ 5,300 ns/op）：32 peers 全扫 ≈ 2× 一次 open；128 peers ≈ 8× 一次 open。

复现：

zig build tool:forward-bench -Doptimize=ReleaseFast            # 默认 32
./zig-out/tools/forward-bench
zig build tool:forward-bench -Doptimize=ReleaseFast -Dmax-peers=128
./zig-out/tools/forward-bench --peers 128

放大与边缘外推

单核饱和点（本机 fast x86 ReleaseFast）：128 peers 时 junk 全扫 ≈ 22,780 pkt/s。36B/报 → ≈ 6.6 Mbit/s 垃圾即可打满一核数据面。目标硬件（MIPS/ARM 小路由器）Blake2b 通常慢 15–40×，等效只需 ~150–500 Kbit/s 垃圾即可饱和。off-path、不可认证、可持续；放大比：1 个廉价报文 → N 次受害端 keyed-hash。

预期 vs 实际

设计文档把「obfuscate=on 入站 O(peers) 试探」记为已知性能取舍；但在 MAX_PEERS 提到 32 默认（#166）/ 可配 128（#165）之后，未认证 flood 下的 DoS 放大维度未被单独分析或形式化接受。#173 已提供测量手段，本 issue 请据此定性并决策。

影响范围

• obfuscate=on（默认）。obfuscate=off 走 O(1) key_id 选择不受影响（但失去混淆）。
• 单线程无锁 reactor：该 CPU 与数据面转发争抢同一核。
• 随 MAX_PEERS 线性恶化，与 feat: configurable MAX_PEERS build option (default 16, max 128) #165/feat: raise default MAX_PEERS to 32 #166 直接耦合。

缓解选项（均需对照铁律 #2 零分配 / #3 单线程无锁 / #8 无握手）

1. 源端点快路径：recvmmsg 的外层 UDP 源地址在解混淆前即可得，可先只试「源端点命中的 peer」的 key（稳态 O(1)），未命中再回退全量扫描（保留漫游）。局限：伪造源地址的 flood 仍走全扫——只护住合法漫游，不解决伪源 DoS。
2. 扫描前按源端点做廉价预算/限速（每 tick 或每源的全扫配额），给最坏放大封顶。
3. obfuscate=on 时收紧 MAX_PEERS 上限，或给出容量-放大告警/文档，让部署方知情权衡。
4. 若维持现状：把上表数值与威胁模型写入设计文档，形式化接受（deferred）。

以上没有免费方案；(1) 不解决伪源，(2)/(3) 需谨慎不违反无握手/无分配/单线程。请择一决策并记录。

严重度

Medium（可放大的未认证 off-path 数据面 CPU DoS；边缘设备上成本极低）。按既有 transport 安全硬化项（#146/#147）的量级标 priority: P2；若判边缘 DoS 更关键可升 P1。

关联

• 测量工具：feat(tools): forward-bench measures the obfuscation de-mux sweep cost #173（本 issue 证据即由其产出）
• 放大参数：feat: configurable MAX_PEERS build option (default 16, max 128) #165（MAX_PEERS 可配 128）、feat: raise default MAX_PEERS to 32 #166（默认升 32）
• 既有已知权衡：设计文档「obfuscate=on 入站 O(peers) 试探」

_{weekly-review 2026-07-06 · 评审 #3 · F1/W1 升级（已跨 3 轮复现，本轮由 #173 量化）}

[jamiesun]

weekly-review 2026-09-03 · 评审 #4 · 无新代码进展，补充覆盖边界说明

本轮（551e85a..9c9a6fa）src/reactor.zig 0 diff，本 issue 的结论与实测证据不变，仍 open。

登记一条与本周 #176 相关的覆盖边界，避免误判本 issue 已被新验收矩阵覆盖：

• docs: mandate a Capability Coverage Matrix as the roadmap acceptance chapter #176 在 docs-site/en/src/reference/roadmap.md 新增 Capability Coverage Matrix，其 "Transport security" 行 failure-path 记为 ✅："junk + forged datagrams: zero replies on the wire, daemon survives"。
• 该用例证明的是功能面存活/不回包，并非本 issue 关注的未认证 flood 下 O(peers) keyed-Blake2b 扫描的 CPU 放大上界。"daemon survives" ≠ "CPU 成本有界"：该用例既不驱动持续 pps 饱和，也不测量单核占用。
• 故本 issue 仍是矩阵未覆盖的开放项。若后续采纳缓解选项 (2)/(3) 给最坏放大封顶，建议在矩阵该行补一条"未认证 flood 下 CPU/pps 有界"的 failure-path 证据，届时再 resolve。

证据：roadmap.md 矩阵 "Transport security" 行；src/reactor.zig:588-609 / 199-209（本轮 0 diff）。