A critical denial-of-service vulnerability in libp2p-rendezvous exposes rendezvous servers to out-of-memory crashes. Any peer can register unlimited unique namespaces, forcing the server to allocate memory indefinitely until it dies. Tested on libp2p v0.56.1, a single attacker peer registers 10,000 namespaces and bumps server memory usage from 18 MB to 28 MB RSS. Scale to 100 sybil identities, and you hit 1 GB; 1,000 peers kill it outright.
Libp2p powers peer-to-peer networks like IPFS, Ethereum clients, and countless decentralized apps. Its rendezvous protocol helps peers behind NATs and firewalls find each other by registering namespaces on public servers. These servers act as directories: peers register under namespaces, others query them. But the server code in protocols/rendezvous/src/server.rs lacks any cap on registrations per peer. The Registrations::add() function uses a BiMap keyed on (PeerId, Namespace), preventing duplicates per peer-namespace pair. Nothing stops flooding 10,000 distinct ones.
Vulnerability Mechanics
Each registration stores entries in three structures: registrations_for_peer (BiMap), registrations (HashMap), and next_expiry (FuturesUnordered of heap-allocated BoxFutures). Namespace strings cap at 255 bytes (MAX_NAMESPACE = 255), but count is unlimited. TTL lasts up to 72 hours (MAX_TTL = 72h), so entries linger even after disconnects—only expiry timers clean them.
No authentication guards the endpoint. Anyone on the network connects and floods. The codebase has no max_registrations_per_peer in Config or elsewhere. Disconnecting the attacker doesn’t help; memory stays allocated until TTLs fire, which could take days.
protocols/rendezvous/src/server.rs
└── Registrations::add() ← no per-peer count check anywhere
protocols/rendezvous/src/lib.rs
├── MAX_NAMESPACE = 255 ← length capped, count is not
└── MAX_TTL = 72h ← entries persist a long time
A simple fix: Add max_registrations_per_peer to Config, check it in add() before insertion, reject excess. Developers should deploy this immediately.
Proof-of-Concept Reproduction
Reproduce on libp2p v0.56.1. Start the server:
cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rendezvous-example
Launch the flood client (adapt from provided rzv-flood.rs):
cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rzv-flood
The client registers namespaces flood-00000000 to flood-00009999, chaining on each Registered confirmation. Server accepts all 10,000 without rejection. Monitor with ps aux: baseline 18 MB RSS climbs to 26 MB mid-flood, 28 MB after. Screenshots confirm: RSS graph rises steadily, all registrations succeed.
One peer does minor damage. Sybil attacks amplify: 100 peers exhaust 1 GB, 1,000 crash any server. No crypto puzzles or special access required—just TCP connectivity.
Why This Matters and Broader Context
Rendezvous servers are public, well-known endpoints—prime targets. Knocking one offline disrupts discovery for dependent clients, fragmenting networks. In IPFS, this breaks content addressing; in Ethereum, it hampers light client bootstrapping. Libp2p’s adoption in DeFi, file sharing, and IoT amplifies risk: a downed server cascades to thousands of users.
This isn’t isolated. P2P protocols often skimp on server-side DoS defenses, assuming distributed resilience. But rendezvous centralizes discovery, creating single points of failure. Similar issues hit early IPFS nodes (e.g., DHT poisoning) and BitTorrent trackers. Libp2p maintainers fixed related bugs before, like request flooding in other protocols, showing responsiveness—but this slipped through.
Operators: Monitor PeerId registration counts, rate-limit by IP/PeerId, cap total registrations. Rotate multiple servers with load balancers. Users: Diversify rendezvous points; query Kademlia DHT as fallback. Skeptically, libp2p remains solid for P2P—v0.56.1 is recent—but deployers must harden servers themselves. No evidence of active exploits yet, but public PoC changes that. Patch now: add the per-peer limit, test under load. Unfixed servers invite easy downtime.
Word count: 612
