P2p Dos And Eclipse

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:

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 O(N²) times, saturating bandwidth in an "echo chamber" pattern. NEAR / Tendermint / Geth have all had variants of this bug. Combined with seen-cache poisoning, an attacker can both flood the network AND censor legitimate items.

Tag: [P2P-AMPLIFY:re-gossip-dedup:{file}:{line}] and [P2P-CACHE-POISON:record-before-verify:{file}:{line}]

2h. Sequential broadcast vs parallel broadcast

Many P2P implementations naively use for peer in active_peers { client.send(peer, msg).await; } to broadcast. Each peer's response time blocks the next. A single slow peer (intentional or not) delays the entire broadcast cycle.

Check:

• For each broadcast loop, identify whether peers are processed sequentially with .await or in parallel with tokio::join_all / FuturesUnordered / select!.
• For sequential broadcast loops, calculate worst-case wall-clock: peer_count × per-peer-timeout. If this exceeds block time, propagation is broken under adversarial peer growth.
• Cap the total broadcast peer count to a constant (e.g., 200 randomly sampled peers); rely on gossip amplification for full propagation.

Tag: [P2P-CPU:sequential-broadcast:{loc}]

3. Eclipse Attack Vectors

An eclipse attack isolates a target node by monopolizing its peer table entries.

3a. Peer table structure

• Identify the peer table data structure (Kademlia k-buckets, flat table, discovery v5 ENR table)
• For each bucket, what is the k value and eviction policy?
• Is peer selection stratified by IP/ASN diversity, or purely by XOR distance?

3b. Peer ID generation cost

• How expensive is it to produce a peer ID that lands in a target bucket?
• Ethereum discovery v5: node ID = hash(public key). Generating thousands of node IDs is cheap.
• Some protocols require proof-of-work for peer IDs; most don't.
• Is there a rate limit on accepting new peer announcements?

3c. Bootstrap / rejoin vulnerability

On restart, the node uses a static bootstrap list, then populates its peer table from responses. If an attacker can intercept or outrun the bootstrap response, they control the initial peer set.

Check: What bootnodes are used? Are they hardcoded or configurable? What happens if all bootnodes are unreachable?

3d. ENR/record poisoning

Discovery v5 uses signed ENRs. Can an attacker poison a victim's ENR cache with malicious entries?

Check: ENR signature verification on every incoming record. ENR seqnum monotonic update.

Tag: [ECLIPSE:{vector}:{countermeasure-state}]

Known exemplar class: devp2p issue #109 (Ethereum discv5 eclipse concerns); academic low-resource eclipse attacks on older Geth.

4. Peer Scoring and Banning

Most clients have a peer scoring system: peers that misbehave (send invalid data, stall, equivocate) accumulate negative score and get banned.