Send addr to outbound connection #17871

Currently there is this logic in place https://github.com/bitcoin/bitcoin/blob/593f5e239f277e3fd917737122c2aed3c615430c/src/net_processing.cpp#L2985-L2994

That prevent a node to send addr to outbound nodes to prevent a fingerprint attack Is this still a valid point?

With feeler connections that test address validity, wouldn't be fair to send to outbound connections some addresses we have validated?

I think this would help having a better distributed address propagation, or did I miss some points?

That prevent a node to send addr to outbound nodes to prevent a fingerprint attack Is this still a valid point?

Yes. Well, it prevents from responding to ADDR requests. A node would still actively announce itself through those connections every day, as well as forward other's ADDR packages.

With feeler connections that test address validity, wouldn't be fair to send to outbound connections some addresses we have validated?

This does not help to prevent fingerprinting by any means (well, maybe an attacker would have to keep their sybil fingerprinting nodes running for a bit, but that's a very small improvement). You might get a better idea of this code by looking at the corresponding PR.

I think this would help having a better distributed address propagation, or did I miss some points?

Well, first of all, just removing this check would not change this at all — honest Bitcoin nodes would not send GETADDR requests through inbound. If you want to enable that as well — I'd want to see some more reasoning about "better address propagation". I don't have an intuition that this should help. We use GETADDR only during node bootstrap, and all the further addr propagation is done via unsolicited periodic ADDR forwarding (every day every node announces itself to its peers, those announcements are then aggregated with self-announcements from other nodes and forwarded).

Alright, so it seems you are suggesting to do unsolicited forwarding of those addresses which were recently checked as feelers. (which has nothing to do with the code you link). Unfortunately, this feeler test would allow an attacker to collect information about the topology graph. Because an attacker can: a) after every feeler check from node X, an attacker reads all nodes AddrMans (this is doable) and sees which ones have attacker's node. Those will be X's connections. No good! b) An attacker selectively responds to feeler checks and make their address propagate in the network in a specific way, which can make malicious collecting information even more effective.

More importantly, I don't see much value in doing this. Frankly speaking, we don't have a clear framework for measuring AddrMan performance. But maybe you can show why this would help "would help having a better distributed address propagation"? Also, take into account those self-announcements I mentioned in the previous message.

I think I got your points and probably I did a bad reasoning mixing connection sides but I think this could still be a valid issue in other terms, let's try to think about it:

suppose you start a a fresh node, you get some addresses by DNS seed then you attach to a malicious peer and that peer gives you (unsolecited?) addresses he's in control of, now you sync with it (and maybe connect to other peers he send you eventually) without problems and at this point you accept incoming connections and you start giving other peers the malicius address that have been passed to you (they arent' fake, are working node but malicious)

At this point you are spreading the plague because you reply to inbound peers your addrman containing mostly malicious peers, and you can't ask to these peers their address because they nagete it giving the code above (for them you are an outbound connection)

At this point such a client contains a lot of malicious peer addresses and can't get better ones because its inbound refuse it, isn't this a risk?

What's the biggest risk, being under control of malicious peers or being fingerprinted? Which would be easier to achieve? Wouldn't replaying to gedaddr in both directions mitigate this risk?

Anyway my question arised because I'm implementing a client in another language and I was trying to talk with a bitcoin core test node that wasn't replaying to my gedaddr messages and I found this code that represents a problem for my simple setup (but not that big) so I wanted to know if this code was still valid after all the time that passed since it was introduced

I wanted to know if this code was still valid after all the time that passed since it was introduced

It is still valid.

I was trying to talk with a bitcoin core test node that wasn't replaying to my gedaddr messages

It would reply, if it's an inbound connection asking getaddr.

What's the biggest risk, being under control of malicious peers or being fingerprinted? Which would be easier to achieve? Wouldn't replaying to gedaddr in both directions mitigate this risk?

Filling addrman with garbage peers is currently possible, but fairly impractical, due to bucketing, new/tried table, honest self-announcements. (Although I'd love to see measurements on this! I hope to find time to do this sometime) I'm not persuaded that the change you are suggesting would make anything reasonably more secure. While the new privacy leak it would cause is pretty straightforward.

Also, if you want to have more good records in AddrMan — better ask your outbound peers. Outbound peers are more trusted in a way. Intuition: it's very easy for an attacker to create 100 inbound connections to a victim, but making the victim to connect to an attacker via victim's outbounds is significantly harder.

then you attach to a malicious peer and that peer gives you (unsolecited?) addresses he's in control of

We put addresses learned from 1 peer in only a subset of buckets (64 out of 1024 I believe). So 1 peer can't screw you very fast. If you connect to 4 bad peers out of 8 — year, probably that might escalate quickly. But even here I'm not sure your solution is effective.

thanks for the insights, I think I'll close the issue as it is now.