DHT communication should be filtered by loaded blocklists

[x190]

In the current nightlies, incoming UDP messages are not processed if found to be from an address in a loaded blocklist. jch, since this is bit like locking the barn door after the horses have escaped, and also since most of us do not have the ability to use iptables to accomplish this, we need your help in filtering any potential outgoing DHT communication such as bootstrapping, node building, and announces.

We have the function in session.h! I think we just need to extract a compatible address type to pass it. :)

bool         tr_sessionIsAddressBlocked( const tr_session        * session,
                                         const struct tr_address * addr );

[jch]

No.

While the Kademlia algorithm is robust in the presence of a small number of rogue nodes, it fundamentally assumes transitive connectivity. In other words, either you participate in the DHT, in which case you must collaborate with all other nodes lest you endanger the integrity of the DHT, or you don't participate in the DHT at all (which you can do by disabling the DHT in the preferences).

At any rate, I want to remind people that BitTorrent? is *not* an anonymous protocol. Please remember that if you're downloading something over BitTorrent?, you broadcast this information to the tracker, to 8 DHT nodes, and to any peer you're conencted to. A manual blocklist will not help you remain anonymous. So please don't get into trouble.

-- jch

[Username]

I will try to reopen this ticket because: while DHT is quite robust, etc, some nodes are still malicious and would expose unpleasant/weird/problematic behavior.

Some nodes would try to flood me as long as they see I'm online and dropping their incoming packets is cool, but this does not reduces traffic. As for me, I would prefer to completely abandon all traffic to and from these nodes. Once they can't have proof that I'm still online they usually abandon flood since they do not have bandwidth to flood all dead IPs of the internet.

Some nodes are clearly trying to pollute DHT tables by injecting dozens of "malicious" nodes who're clustered around very few IPs in certain datacenters. Since DHT is not meant to be supported by datacenters in this way, this is indication that they are rather trying to direct traffic to self. Maybe to attack certain hashes, etc. It's not like if this completely succeeds, but as for me I see a very little reason to communicate with corrupted nodes.

Actually, malicious nodes could attempt to shift random hashes distribution to non-random and may apply somewhat different "rules" to our "game", like only returning closest neighbours from their own cluster.

On other hand, just blocking nodes does not changed DHT properties, it's just like if those nodes died. This does not affects uniformity of hashes distribution and does not fills anyone's buckets with corrupt nodes.

Btw, you may want to see how aMule/eMule deals with DHT abuses. They have a dozen of interesting countermeasures against malicious behaviour since their DHT has been abused by anti-p2p guys a way too much.

Well, and the reason for reopening this ticket: if I told app to block traffic to certain IP, it have to obey rather than backstab me by ignoring blocklist rules in one place and obeying in others. Blocklist either blocks all traffic or this is a snake oil, regardless of anonymity, DHT integrity and other stuff.

[jch]

Jordan, would you care to explain r12544 to me?

-- jch

[jordan]

As the comments say, it attempts to stop processing messages from blocked IP addresses.

I agree with comment:2 but the other side to that is that if Transmission supports blocklists, it's reasonable to be consistent about that support.

My preference for solving this question would be to remove blocklists, since the only thing they're good for is a false sense of security.

[jordan]

This isn't a high priority issue.

[jordan]

I'm going to close this as a duplicate of #4016 -- after talking it over with jch, there's a Transmission-level (rather than DHT-level) way of handling this.