After looking at the gossipsub Iwant/Ihave handlers, I realised that there is a missing spam prevention check when opening the Ihave messages from a received ControlMessage.
We do checked that the remote peer stayed within the number of Ihave messages, and that we didn't exceed the message ID count for asked messages, but it doesn't check anything related to the size of the array of message IDs per each topic I have.
This PR adds that missing spam protection step, ensuring that we only read the first maxMessageLength messages of each Ihave as @MarcoPolo suggested.
Let me know if there is anything else that should be added or modified.
Description
After looking at the gossipsub
Iwant/Ihavehandlers, I realised that there is a missing spam prevention check when opening theIhavemessages from a receivedControlMessage.To give some context, the spec defines that each Ihave message should have an upper limit of aggregated message IDs, which in this go implementation is defined by
maxMessageLength = 5_000message IDs per Ihave and topic, asIhavemessages can be aggregated in a single RPC call.This spam check is already done at the moment of emitting the Gossips. However, I can't see a similar check at the moment of handling each of the message IDs within the
Ihavemessages.We do checked that the remote peer stayed within the number of
Ihavemessages, and that we didn't exceed the message ID count for asked messages, but it doesn't check anything related to the size of the array of message IDs per each topic I have.This PR adds that missing spam protection step, ensuring that we only read the first
maxMessageLengthmessages of eachIhaveas @MarcoPolo suggested.Let me know if there is anything else that should be added or modified.