Responder-side cookie/mac2 issuance (under-load DoS mitigation)

[GeiserX]

Context

ts_tunnel/src/macs.rs has // TODO: verify non-zero mac2. WireGuard's cookie mechanism (whitepaper §5.4.7) is the under-load DoS mitigation: a responder under load replies to a handshake initiation with a MESSAGE_HANDSHAKE_COOKIE (type 3) demanding the initiator retransmit with a valid mac2 computed from the (XChaCha20Poly1305-encrypted) cookie.

Current state (verified)

• Initiator-side cookie consumption already works — recv_cookie_reply → receive_cookie decrypts the cookie reply and the initiator recomputes mac2 on retransmit. XChaCha is already in the tree. So as a dialing client, this fork can already respond to a real peer's cookie challenge.
• Responder-side cookie issuance is the missing half — when WE are the responder under load, we don't generate/send cookie replies; we currently reject any non-zero mac2.

Scope / priority

This is under-load-only: wireguard-go's IsUnderLoad triggers at ≥128 queued handshake initiations (device/queueconstants_default.go). A normal relay dial never hits it. For a fork that is primarily a dialing client, responder-side issuance is spec-optional and lower priority — it matters only if this node acts as a heavily-loaded responder (e.g. a popular exit/relay node under handshake flood).

Ask (when prioritized)

Implement responder-side cookie generation: a CookieGenerator (mirror wireguard-go device/cookie.go) — a rotating (120s) cookie secret keyed by our static key, IsUnderLoad heuristic, emit MESSAGE_HANDSHAKE_COOKIE when under load, and verify the returned mac2. This is greenfield (a cookie state machine + the type-3 send path); benefits from a design pass first.

Created using Claude Code

[GeiserX]

Note for clarity — the receive-side half of the cookie/mac2 story shipped separately in v0.10.0 (#23): verify_macs no longer rejects an inbound handshake that carries a non-zero mac2 (a peer replying to a CookieReply sets it; since this fork never issues cookies, mac1 is the authenticator and mac2 is ignored — wireguard-go/boringtun parity).

This issue (#27) remains open for the distinct, larger piece: responder-side cookie/mac2 issuance — generating a CookieReply under load (≥128 queued initiations) as a DoS mitigation. That's spec-optional for a dialing client and a separate feature; #23 only stopped the incorrect rejection, it did not add issuance.