Feature: Add support for SOCKS5 BIND

[0xThiebaut]

Currently accepting inbound connections when a proxy is present relies on proxy_accept_incoming (#7726), optionally with a mixture of announce_ip and announce_port. This however causes a tight configuration coupling between the proxy and libtorrent where libtorrent needs to announce the proxy's listen port or vice versa. The SOCKS5 protocol provides functionality to accept inbound TCP connections through the BIND operation. This issue is to discuss whether we could add support for this into libtorrent and, if so, which approach would be best.

If implemented, it would enable libtorrent to negotiate a working TCP listening port with compatible SOCKS5 proxies and ensure this is automatically announced to TCP-based trackers.

@arvidn is this something you could see added into libtorrent?

[arvidn]

As far as I know, SOCKS5 BIND is already supported, as well as UDP ASSOCIATE for incoming TCP and uTP connections respectively.

BIND isn't quite meant for this use case, so it doesn't necessarily work that well with most proxies.

[0xThiebaut]

I know that outbound connectivity is implemented (CONNECT for TCP, ASSOCIATE for UDP) and, through hole-punching, it also provides inbound UDP. But inbound TCP would need BIND which I don't see being attempted. Is this located behind a specific setting?

[arvidn]

I thought I had implemented it, but I may be wrong. I can't find it either.

[Neustradamus]

@0xThiebaut: Good catch!

[Masong19hippows]

Saw this and I'm confused on how an approach would work for this.

Per the spec, "
It is expected that the client side of an application protocol will
use the BIND request only to establish secondary connections after a
primary connection is established using CONNECT"

It's my understanding that this means you must have a primary connection to some server before you initiate the bind setup. Ex: the socks client would need to send a connect to some application server before it sends a bind to the socks server for that application server.

It also says "The client will
typically use these pieces of information to notify (via the primary
or control connection) the application server of the rendezvous
address." Wich I take to mean that this port is more meant only for that one connection.

I don't see how you would implement something like this without having control of the socks server to handle these requests correctly. Am I missing something?