Page MenuHomePhabricator

Rate limit the processing of incoming addr messages
AbandonedPublic

Authored by PiRK on Jan 31 2022, 10:22.

Details

Reviewers
Fabien
Group Reviewers
Restricted Project
Summary

While limitations on the influence of attackers on addrman already
exist (affected buckets are restricted to a subset based on incoming
IP / network group), there is no reason to permit them to let them
feed us addresses at more than a multiple of the normal network
rate.

This commit introduces a "token bucket" rate limiter for the
processing of addresses in incoming ADDR and ADDRV2 messages.
Every connection gets an associated token bucket. Processing an
address in an ADDR or ADDRV2 message from non-whitelisted peers
consumes a token from the bucket. If the bucket is empty, the
address is ignored (it is not forwarded or processed). The token
counter increases at a rate of 0.1 tokens per second, and will
accrue up to a maximum of 1000 tokens (the maximum we accept in a
single ADDR or ADDRV2). When a GETADDR is sent to a peer, it
immediately gets 1000 additional tokens, as we actively desire many
addresses from such peers (this may temporarily cause the token
count to exceed 1000).

The rate limit of 0.1 addr/s was chosen based on observation of
honest nodes on the network. Activity in general from most nodes
is either 0, or up to a maximum around 0.025 addr/s for recent
Bitcoin Core nodes. A few (self-identified, through subver) crawler
nodes occasionally exceed 0.1 addr/s.

Note: if -maxaddrtosend is specified, we use this instead of MAX_ADDR_TO_SEND (1000) to increase the number of tokens for a peer after sending a getaddr message.

This is a backport of core#22387 [1/5]
https://github.com/bitcoin/bitcoin/pull/22387/commits/0d64b8f709b4655d8702f810d4876cd8d96ded82

Test Plan

ninja all check-all

Event Timeline

PiRK requested review of this revision.Jan 31 2022, 10:22
Fabien requested changes to this revision.Jan 31 2022, 13:36
Fabien added a subscriber: Fabien.

You should squash this PR. It's not that big and most importantly that prevents from introducing a new important feature with no test

This revision now requires changes to proceed.Jan 31 2022, 13:36