/p2p-dos-and-eclipse

name: "p2p-dos-and-eclipse"
description: "L1 trigger - audits peer-to-peer networking for DoS vectors (resource exhaustion, amplification), eclipse attack susceptibility, and discovery table poisoning (Kademlia/devp2p)."

Injectable Skill: P2P DoS and Eclipse Attacks

> **L1 trigger**: `L1_PATTERN=true` AND (`p2p/` OR `network/` OR `discovery/` OR `libp2p` OR `devp2p` OR `enr` OR `discv5` detected in recon subsystem map) > **Inject Into**: `depth-network-surface` > **Language**: Go and Rust > **Finding prefix**: `[P2P-N]` > **Status**: v0.1 draft, Round 4 exemplars pending

Orchestrator Decomposition Guide

• Sections 1, 2: depth-network-surface (attack surface + DoS)
• Section 3: depth-state-trace (peer table state)
• Section 4: depth-edge-case (boundary/adversarial peer states)

When This Skill Activates

Recon identifies a P2P subsystem. Most attacks in this class are out-of-scope for typical bounty programs but are **in scope for Plamen audits** — firms like Sigma Prime and OpenZeppelin explicitly cover them. Severity downgrades to Low/Info when the exploit only eclipses a single node (see severity-matrix.md); upgrades when reachable by arbitrary peers and amplifies across the network.

1. Attack Surface Enumeration (Entry Points)

Every P2P subsystem has a finite set of entry points for remote adversary bytes. Enumerate them using LSP `workspace/symbol` and ast-grep:

| Entry point type | How to find | Example functions | |---|---|---| | **Message handlers** | Trait/interface impl names ending in `Handler`, `Service`, `Listener` | `handleGetBlockHeaders`, `on_new_pooled_transaction_hashes` | | **Decoders** | Functions taking `&[u8]` or `Reader` and returning protocol types | `decode_enr`, `rlp_decode` | | **Connection accepters** | TCP/QUIC listener accept loops | `acceptLoop`, `handle_connection` | | **Discovery responders** | UDP packet handlers for discovery protocol | `handleDiscv5Packet`, `process_find_node` | | **Gossip handlers** | Pubsub topic subscribers | `process_gossip_message` |

Write the enumeration into `scratchpad/p2p_surface.md` before proceeding.

2. DoS Classes to Check per Entry Point

2a. Asymmetric processing cost

Attacker sends N bytes, node does O(N²) or O(N*log(N)) work. Classic example: decompression bombs, hash-map insertion of attacker-chosen keys (hash DoS), large RLP lists.

**Check**:

• For each decoder, is there a **max size limit** before parsing begins?
• For each list/vector field, is there a **max element count** enforced?
• For each recursive decoder, is there a **max recursion depth**?
• For each hash-map insert of attacker-controlled data, is the map key pre-hashed or is a SipHash-random-keyed map used?

Tag: `[P2P-ASYMMETRIC:{loc}:{input-size}→{work-cost}]`

2b. Unbounded memory growth

Handlers that buffer or queue indefinitely.

**Check**:

• Every channel/queue: does it have a bounded capacity? What happens on overflow — block, drop, or OOM?
• Every `append` / `Vec::push` in a loop that can be driven by adversary: is there a bound?
• Every peer-keyed map (peer → state): is there an eviction policy when size > threshold?

Tag: `[P2P-UNBOUNDED:{structure}:{growth-driver}]`

2c. Unbounded CPU: infinite loops or pathological inputs

Handlers that can loop forever or spend minutes on malicious input.

**Check**:

• Every `for` loop in a handler: what bounds termination? Attacker-controlled?
• Regex with catastrophic backtracking (if any regex is used on peer input)
• Crypto operations on unvalidated length inputs

Tag: `[P2P-CPU:{loc}:{termination-condition}]`

2d. Connection slot exhaustion

Attacker opens N connections with M peers, filling the connection table.

**Check**:

• What is the max inbound connection limit? (Geth: 50, Bitcoin: 125)
• Is there a per-IP limit? Per-/24-subnet limit? Per-ASN limit?
• How long can a half-open (TCP SYN + no handshake) connection hold a slot?
• Does the node prioritize connections from diverse IP ranges?
• **Outbound bootstrap handshake cap**: when a joining node receives a peer list from a bootnode, does it cap the number of addresses it attempts to handshake in parallel? Without a cap, a malicious bootnode (or a peer-list response with N>>peer-table-size) forces the joiner to exhaust file descriptors / memory / connection slots during startup. Verify both the per-bootstrap response cap AND the in-flight handshake concurrency limit.

Tag: `[P2P-SLOTS:{limit}:{diversification}]`, `[P2P-BOOTSTRAP-FLOOD:{cap-or-unbounded}]`

2e. Amplification

Attacker sends small message, node sends large response — used to DDoS third parties.

**Check**:

• For every request-response pair, compare input size vs output size
• Discovery protocols (UDP) are especially dangerous — no handshake, easy spoofing
• Is source-address validation (rate-limited ENR responses, etc.) in place?

Tag: `[P2P-AMPLIFY:{request-bytes}→{response-bytes}]`

2g. Re-gossip dedup discipline (echo-chamber amplification)

For each gossip handler that RECEIVES data and then FORWARDS it to other peers (re-gossip), trace the dedup path. This is a separate concern from 2a (single-message cost) — it covers network-multiplication attacks.

**Check**:

• Is there a "recent-seen" or "recent-valid" cache that BLOCKS re-broadcast on duplicates?
• Is the cache check BEFORE the broadcast spawn / `.send()` call, not after?
• Is the cache key the message hash (not the message contents, which an attacker can mutate while preserving semantics)?
• Is the cache populated AFTER signature/validity verification, not before? Recording-as-seen pre-verification creates a "seen-cache poisoning" primitive: an attacker injects an invalid item with a valid ID, the cache records it, the legitimate version from honest peers is then dropped as "already seen".
• For each handler, walk the order of operations: `verify_signature` → `record_seen` → `broadcast`. Any other order is a finding.

**Fail mode**: an N-peer network re-gossips each message