Enable TCP traffic through tunnel community

[qstokkink]

Currently the SOCKS5 Server drops TCP traffic. In practice this means that all http trackers are unable to find peers. This can severely impact performance of some torrents.

To fix this, changes should be made to the following classes. These should forward TCP packets (probably using explicit subclassing for decoupling of TCP and UDP behaviors, in line with the SOCKS5Connection):

• The SOCKS5 connection
• The exit node

An experimental implementation (by @devos50) already exists for reference. One possible backward compatible way to forward traffic is to use conversion.is_allowed() to filter out UDP from TCP traffic.

EDIT: Only http trackers should be forwarded (not all TCP traffic), this reduces the chance of exit nodes being misused.

[ichorid]

One possibility is to only support get_peer, hardcode the protocol that everything we DONT recognise would be filtered out. Talk UDP to the exit node and e.node talks TCP to tracker.
Or use SOCKS5 with filtering.
An explicit warning/error for connecting to HTTP-based trackers.

[qstokkink]

@ichorid this is what we currently have to do the filtering:
https://github.com/Tribler/py-ipv8/blob/master/ipv8/messaging/anonymization/tunnel.py#L42-L83

[ichorid]

The only reason for us not to enable unconditional TCP through our tunnels is our concern for the tunnels being abused. We intend our tunnels to be used for moving BitTorrent traffic, i.e. file downloading.
This is not technology by itself, but policy that could be enforced by technology.
We could do the "zero tolerance" policy, meaning that everything beside BT traffic is illegitimate. But why would we want that? Essentially, we would consider an abuse:

1. DDOS attacks
2. Web traffic to 'evil' web resources (cp, extremism, drugs etc.)
3. Encrypted/anonymous communication between two or more parties, of which at least one is 'evil'. For example, inter-terrorist communication, anonymous connection to legitimate web resources with intention of trolling, extortionist to victim communication, etc.

By completely denying TCP traffic, we exclude case (2). By adding filters permitting only uTP and UDP tracker connection we hamper cases (1,3) to the point it becomes much easier for potential abuser use some other anonymization service, like TOR.

We don't care about torrents that are potentially illegal because:

1. We let the community (and channel-level filters) decide what is worth of their traffic;
2. We consider any knowledge to be sacred. And torrents=files=data=knowledge :-)

After we enable the user rating system, we trust it to become our ultimate immune system. But we still need to bootstrap the community. We have a classic chicken-and-egg problem here.

We could enable TCP forwarding, but we need to be sure, that in won't facilitate cases (1,2,3). To do that, we have to implement TCP-based policy filter, that would only allow TCP BT and HTTP tracker traffic. We do not want to put too much effort into that, because we believe it to be important only until our 'immune system' is up. As we don't mean to support every BT implementation out there (we only use libtorrent), and we only want to support 80% of HTTP trackers, we need to create a list of 'markers' of these protocols, and add them to the list of filters @qstokkink has so timely mentioned in the previous comment ))
After that, we would only have to enable TCP forwarding through SOCKS5.

I find it a little bit ironical that to bootstrap freedom-enabling traffic exchange technology like Tribler we have to refer to Deep Packet Inspection traffic policing, that is used by some oppressive states.
"You have to make the good out of the bad because that is all you have got to make it out of" (C) Robert Penn Warren

[qstokkink]

@ichorid Trust is feedback loop:

1. You engage in activities that require trust.
2. If you play by the rules, you build trust.

If we never check anything, you have blind trust, which leads to you getting abused: there is no incentive.

---

As our current filtering does not actually parse the message contents, I disagree with your labeling of the implementation as Deep Packet Inspection. However, there are basically two ideas to get rid of the packet inspection altogether:

1. Covariance-based cross-domain trust calculation (or reusing trust between applications/domains/functionality)
2. Payouts

We are exploring both. @devos50 is handling payout schemes. The one-chain one-trust multiple-domain model is still something I'm exploring.

[synctext]

Quick feedback...

Self-reinforcing trust in Tribler #2540

• token economy = critical feedback loops to get going.
  That means closing 200+ outstanding issues. TCP is minor issue, as content is set as priority 3 in cardinal roadmap issues attack-resilient micro-economy for media #1.

[ichorid]

Related to arvidn/libtorrent#1373

[qstokkink]

@ichorid is this feasible for the 7.1 release or should we move it?

[ichorid]

@qstokkink, I am not sure about this one. There is a possible easier(?) workaround: when initiating download of torrent that only has HTTP tracker address embedded try the same address over UDP tracker protocol instead. However, this solution depends on 2 things yet unknown to me:

1. Do trackers typically serve HTTP and UDP on the same port?
2. Is it trivial for us to check for HTTP tracker in the torrent header, and change it to UDP before initiating connection?

[synctext]

is another option to have an explicit UDP-based protocol for TCP-talk to trackers? Exit nodes convert this and we prevent all abuse by parsing the get_peers() replies.

btw interesting, "one-chain one-trust multiple-domain model".

[egbertbouman]

It's currently only in devel and still a bit experimental, but most of our exit nodes now support HTTP. Exit nodes can opt-in/out of HTTP support, but it's turned on by default.

By only allowing bencoded responses, we filter out non-tracker traffic.

[qstokkink]

Wow 2016, this was on my wishlist for 4 years already 😃

[egbertbouman]

@qstokkink It's still not fully used unfortunately because it still needs to get linked to our "much-loved" TorrentChecker (see #5262). At least the downloads can now access HTTP trackers.