🎯 Problem to be solved

Charon accepts effectively unbounded traffic from cluster peers on its libp2p protocols. The default wire read limit is 128MB per message, and nothing bounds message rate or the number of concurrent inbound streams a peer can open: charon runs with libp2p.ResourceManager(new(network.NullResourceManager)), and yamux delegates concurrent stream limits to the resource manager.

A compromised or buggy peer can therefore make a node allocate and verify unbounded work. Local kurtosis testing also shows honest peers legitimately reaching 65-128 concurrent in-flight parsigex messages when the receiving node processes slowly, so naive limits would risk cutting off honest traffic on degraded hosts.

🛠️ Proposed solution

Introduce per-peer, per-protocol transport limits, sized from fleet data so they never touch honest traffic:

• Roll out extensive monitoring of traffic. Ship per-protocol/per-peer metrics for message sizes, read errors and handling concurrency (p2p: add message size, read error and concurrency metrics #4680), add them to the fleet remote-write allowlist, and collect fleet data on legitimate usage patterns.
• Limit amount of open connections per protocol. Bound concurrent inbound streams per peer per protocol (each charon message is one libp2p stream), sized from the fleet data of step 1.
• Limit size of messages per protocol. Extend the per-protocol wire read limits: core/parsigex: bound work triggered by received messages #4637 caps parsigex at 32MB; priority and the DKG protocols still use the 128MB default.