From d867b84f093fe5270da7e7a49a9c9ea1be7c538c Mon Sep 17 00:00:00 2001 From: Justin Traglia Date: Wed, 8 Jan 2025 15:34:06 -0600 Subject: [PATCH] Add back remark about compression bombs --- specs/phase0/p2p-interface.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md index ab3306d235..1196fca90d 100644 --- a/specs/phase0/p2p-interface.md +++ b/specs/phase0/p2p-interface.md @@ -1721,6 +1721,8 @@ To derive "encoded size limits" from desired application sizes, we take into acc In the case of gossipsub, the protocol supports sending multiple application payloads as well as mixing application data with control messages in each gossipsub frame. The limit is set such that at least one max-sized application-level message together with a small amount (1 KiB) of gossipsub overhead is allowed. Implementations are free to pack multiple smaller application messages into a single gossipsub frame, and/or combine it with control messages as they see fit. +The limit is set on the uncompressed payload size in particular to protect against decompression bombs. + #### Why is there a limit on message sizes at all? The message size limit protects against several forms of DoS and network-based amplification attacks and provides upper bounds for resource (network, memory) usage in the client based on protocol requirements to decode, buffer, cache, store and re-transmit messages which in turn translate into performance and protection tradeoffs, ensuring capacity to handle worst cases during recovery from network instability.