Limit concurrent offers that can be received from each peer in Fluffy

[bhartnett]

In order to reduce the impact of certain DOS attacks we should put limits in place to reduce the impact on Fluffy nodes.

We should enforce the following:

• For each content key/content id we can only receive one concurrent offer from each peer/enr for that content
• Limit the total number of offers that can be received concurrently from each peer/enr. This limit will be configurable as a debug parameter.

Nodes that hit the total number of offers limit will be added to the temporary ban list.

[kdeme]

Yes, I agree that these would be two good limits to have enabled.

[bhartnett]

@kdeme Do you think that content lookups should be included in the limits?

In other words, when a node asks a peer for content to download it should be limited to one concurrent download/upload per contentId and limited to n concurrent downloads/uploads in total. When I say download I mean requesting content from a peer and when I say upload I mean offering content to a peer.

[bhartnett]

Should we also limit the number of concurrent pings and findNodes requests which we respond to?

[kdeme]

Should we also limit the number of concurrent pings and findNodes requests which we respond to?

I think this would be a different type of limit that is more of a rate limiter.

[kdeme]

Do you think that content lookups should be included in the limits?

Not fully sure on this one. It seems more like the responsibility of the application not to do such things. I mean, it's in the hands of the local node and not its peers for this to occur. But maybe there are situations where this can anyhow happen, although probably rare.

[bhartnett]

Not fully sure on this one. It seems more like the responsibility of the application not to do such things. I mean, it's in the hands of the local node and not its peers for this to occur. But maybe there are situations where this can anyhow happen, although probably rare.

What I meant is limiting the number of content lookups which we handle/respond to. My reasoning for applying the limit here as well is that we need to open a utp stream and so it seems reasonable to prevent a single peer requesting too much content. I've implemented this already but happy to revert if we don't want to go this way. See here: a96a134

[kdeme]

Oh, yeah. I misunderstood as I already noticed that feature in your PR.

So yes, that definitely sounds good as a limit protection to have considering it is incoming from other peers.

[bhartnett]

The changes for this task were implemented in this PR: #2885