2b: rendezvous server registration is unauthenticated (registration-overwrite DoS) #37

New issue

Closed

opened 2026-07-06 18:18:46 +00:00 by vxfemboy · 0 comments

vxfemboy commented

2026-07-06 18:18:46 +00:00

(Migrated from github.com)

Context

Whole-branch review of milestone 2b. Availability gap on the internet-exposed yip-rendezvous server. No session compromise (Noise + blind relay hold). Inherent to the unauthenticated soft-state design; honest fix is a 2b.1/2c follow-up.

Problem

RendezvousServer::handle (crates/yip-rendezvous/src/server.rs, Message::Register) does regs.insert(node, Reg{ addr: src, .. }) unconditionally (capacity permitting). A node_id = BLAKE2s("yip-rdv-v1"||pubkey)[..16] is derived from a non-secret public key, so anyone who knows a victim's pubkey can Register{victim_node} from an arbitrary/spoofed source and repoint the victim's entry. Then Lookup{victim} returns the attacker's address and RelaySend{dst=victim} is forwarded to the attacker — the two real peers become unreachable to each other on both discovery and relay. Rate-limiting is keyed on src, which src-spoofing sidesteps.

The data plane stays secure (attacker can't complete Noise; relay is blind), but the spec's Trust-boundary claim that the server preserves availability is stronger than the mechanism delivers.

Related minor (same root): Lookup reflection/amplification — one Lookup emits PeerInfo to src + PunchHint to the registered peer (2 packets, 2 dsts); spoofed-src bypasses per-source rate limiting. Low factor (~1–2.7x), inherent to STUN-like rendezvous.

Fix direction

Signed / challenge-proven registrations (prove possession of the private key for node_id before accepting/updating a binding), and return-routability for Lookup. Belongs with the control-plane hardening (2b.1) or the discovery milestone (2c).

## Context Whole-branch review of milestone 2b. Availability gap on the internet-exposed `yip-rendezvous` server. No session compromise (Noise + blind relay hold). Inherent to the unauthenticated soft-state design; honest fix is a 2b.1/2c follow-up. ## Problem `RendezvousServer::handle` (`crates/yip-rendezvous/src/server.rs`, `Message::Register`) does `regs.insert(node, Reg{ addr: src, .. })` unconditionally (capacity permitting). A `node_id = BLAKE2s("yip-rdv-v1"||pubkey)[..16]` is derived from a **non-secret** public key, so anyone who knows a victim's pubkey can `Register{victim_node}` from an arbitrary/spoofed source and repoint the victim's entry. Then `Lookup{victim}` returns the attacker's address and `RelaySend{dst=victim}` is forwarded to the attacker — the two real peers become unreachable to each other on both discovery and relay. Rate-limiting is keyed on `src`, which src-spoofing sidesteps. The data plane stays secure (attacker can't complete Noise; relay is blind), but the spec's Trust-boundary claim that the server preserves availability is stronger than the mechanism delivers. Related minor (same root): `Lookup` reflection/amplification — one Lookup emits PeerInfo to src + PunchHint to the registered peer (2 packets, 2 dsts); spoofed-src bypasses per-source rate limiting. Low factor (~1–2.7x), inherent to STUN-like rendezvous. ## Fix direction Signed / challenge-proven registrations (prove possession of the private key for `node_id` before accepting/updating a binding), and return-routability for Lookup. Belongs with the control-plane hardening (2b.1) or the discovery milestone (2c).