Evicting and filling attack for linking multiple network addresses #28760

1. 
   naumenkogs commented at 12:45 pm on October 31, 2023: member

   I’ve discovered a paper published earlier this month. I haven’t found any discussion in the repo, so I will summarize the relevant parts here and share my thoughts.

   Let’s say we have a node that operates both over ipv4 and TOR. We don’t want an observer to link these two addresses to the same node. For example, ADDR caching (#18991) was implemented for this reason.

   The paper suggests the following attack:

   1. Fill all (115?) victim’s inbound slots in networkA.
   2. Make sure these connections are candidates for eviction (higher latency, etc.).
   3. Make connection to the presumably-victim’s node in networkB
   4. Observe whether networkA connections from (1) are dropped as you add connections in networkB.

   I haven’t verified the experiments, but even understanding the attack assures me the problem exists. Authors claim to reach high precision at a very low cost (optimized by inspectingVERSION data and block relay data).

   They suggest the following countermeasures:

   1. Have separate connection pools (for the sake of eviction) for each network (say TOR and ipv4).
   2. Make eviction unpredictable (e.g. after a random delay)
2. 
   naumenkogs commented at 12:48 pm on October 31, 2023: member

   Recently, someone at the meetup told me that other projects usually consider this a lost cause. Apparently, it’s easier to maintain two separate nodes and connect them if needed. This is probably not the case for Bitcoin, where the difference between run one multi-homed node and run two single-homed nodes is substantial enough for a regular user, so we better facilitate it (at least continue implementing basic privacy improvements).

   At the same time, things like #27509 hopefully reduce the node mapping risks w.r.t. transaction relay privacy.

   I intend to think more about adequate solutions to this issue and suggest a PR.

3. 
   mzumsande commented at 7:46 pm on October 31, 2023: contributor

   I may be too pessimistic but think that preventing fingerprinting as a whole is close to a lost cause currently - not in theory, but in the sense that solving all possible fingerprinting vectors would be a lot of work.

   I think there are fingerprinting vectors in all three relay types (addrs, transactions, blocks) - some are public, e.g. #24571, some maybe aren’t documented but are pretty obvious (probably not helpful to document specifics in one public place, so I won’t do that here) - and many of them are really hard to fix without affecting other important functionality.

4. 
   jonatack commented at 9:14 pm on October 31, 2023: contributor

   Introducing some randomness into the eviction algorithm to make it less deterministic – instead of, or in addition to, random disconnection delay – might be a potentially low-hanging countermeasure.

   “Bitcoin allows multiple connections from one single address (Saad et al. 2021). This property significantly reduces the attack cost.”

   #28248 proposes to improve or address this in several ways, though I’m not sure what that line in the paper refers to.

   “We disclosed the attack to Bitcoin Core developers before the publishing of this article.”

   I wonder to whom it was disclosed.

5. willcl-ark added the label P2P on Jan 24, 2024
6. willcl-ark added the label Brainstorming on Jan 24, 2024

Contributors
naumenkogs mzumsande jonatack

Labels
Brainstorming P2P