[A·M2] Stateless responders: SYN/ACK + SipHash cookie, UDP, ICMP #10

New issue

Closed

opened 2026-06-24 23:49:40 +00:00 by vxfemboy · 1 comment

vxfemboy commented

2026-06-24 23:49:40 +00:00

(Migrated from github.com)

Cheap, memory-free tier: answer TCP SYN with SYN/ACK using a SipHash SYN-cookie (verified on the client reply), answer ICMP/ICMPv6 echo, and common UDP probes — so mass scans and SYN floods see open ports without per-connection state. Part of #2.

vxfemboy commented

2026-07-06 06:58:09 +00:00

(Migrated from github.com)

Status audit (2026-07-06, during the sub-project B push): only the ICMP/ICMPv6 part of this issue shipped — transport/nfqueue.rs synthesises ICMP/ICMPv6 echo replies in userspace. The stateless TCP SYN/ACK + SipHash cookie responder and the UDP responder were never implemented, and there is no siphash dependency and no DeceptionTransport trait (the abstraction from #9) — the transports are concrete run() functions.

This matters for sub-project B: the B design spec (2026-07-05) assumed B2 would "promote A's existing SipHash SYN-cookie tier to XDP" — but that tier does not exist at any layer. So SYN-flood protection is currently a real gap (Linux kernel tcp_syncookies only protects the box's own listeners, not forwarded/deception traffic for protected tenants).

Reopening the design question: build the stateless SYN-cookie tier here (userspace, tractable) as B2's foundation, or build SYN cookies directly in XDP (B2). See the deployment-readiness discussion.

**Status audit (2026-07-06, during the sub-project B push):** only the **ICMP/ICMPv6** part of this issue shipped — `transport/nfqueue.rs` synthesises ICMP/ICMPv6 echo replies in userspace. The **stateless TCP SYN/ACK + SipHash cookie responder** and the **UDP responder** were never implemented, and there is no `siphash` dependency and no `DeceptionTransport` trait (the abstraction from #9) — the transports are concrete `run()` functions. This matters for sub-project B: the B design spec (2026-07-05) assumed B2 would "promote A's existing SipHash SYN-cookie tier to XDP" — but that tier does not exist at any layer. So SYN-flood protection is currently a real gap (Linux kernel `tcp_syncookies` only protects the box's own listeners, not forwarded/deception traffic for protected tenants). Reopening the design question: build the stateless SYN-cookie tier here (userspace, tractable) as B2's foundation, or build SYN cookies directly in XDP (B2). See the deployment-readiness discussion.