SOCKS5 proxy support does not include BIND ?

[cjard 3]

Hi all

SOCKS 5 includes the ability of the client to quote a BIND request, which makes the server open up a listening port, and then tell the client what port it opened up.. So far, after watching the socks traffic in uTorrent (investigating the bad protocol version bug) I notice that I have never seen it issue a BIND request..

As the SOCKS equivalent of a UPnP port mapping, this potentially very useful, incoming-connection-allowing step doesnt seem to be taken. Will it be?

[Greg Hazel 0]

(from a developer here)

The thing with SOCKS5 BIND command is that it is specifically

designed for protocols like FTP, where you know which computer will

connect to you. I presume they did this as a security feature,

because you can only listen on incoming connections from a specific

IP address. At least this is my interpretation, the specification is

not very clear on this point:

"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. In is expected that

a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND

request."

from: http://www.faqs.org/rfcs/rfc1928.html

If my interpretation is correct, that means that there's no way to

get incoming connections through a SOCKS5 server (unless one uses a

rendevouz server of some sort).

On the other hand though, it would be possible to extend the DHT

support for SOCKS5 by using the UDP ASSOCIATE command (which opens up

a UDP relay).

[cjard 3]

ah yes... Re-reading this part of the spec I can see that in some ways it doesnt go far enough/is limited..

Im guessing that the most significant problem occurs shortly after the remote client makes the connection to the server's listening socket. The spec implies that the server would unbind at this point because there is no provision for accepting another remote client.. i.e. when the remote client disconnects, if the server left the binding open, there would be no way for the server to inform our client that a new remote client had connected. Further, because we issue a bind and then expect to accept a single connection from a single remote client over that established route, there is no scope for accepting multiple connections from multiple remote clients over a single BINDed socket.

The solution would be an extension to the SOCKS spec, to request the server listen for connections on a particular port, and upon a remote client successfully connecting there, the server establish a new connection back to our client.

Given that an extension could take months or years, what is the likelihood that BIND could be used to bind a few waiting connections and them be used sequentially by remote clients?

Im not sure how the torrent protocol is configured in this case - If the original port range of 6880-6889 was to allow up to ten instances of a commandline client (and each client tried to bind and address until it succeeded) then there isnt much scope for working this in.

If, however, the original commandline client opened 10 ports because it wasnt programmed for accepting multiple connections on one port (which, given bram's ingenuity with the rest of the spec, I find hard to believe he couldnt code that) then the spec may reveal some way existing socks servers could be made to work (The spec doesnt mandate that a CONNECT occurs first, so a well behaved SOCKS server can probably be asked to bind 10 ports, and hopefully wait (forever?) for a client to connect and not necessarily expect it to be from an existing CONNECTed client..)

Does anyone know the torrent spec in better detail to explain to me how it allows a client to broadcast what listening ports it has opened?

[arvid 0]

The listen port is announced to the server, and to the DHT, and through peer exchange. All of those would need extensions or clients could assume that other clients may be listening to a range from the announced port to the port + 10 or something. I doubt that is necessary though. If you re-issue a BIND command as soon as possible, you would have a race condition, making some connection attempts fail, but most clients will try again at some point anyway, so I don't think that's such a big problem.

[cjard 3]

OK, sounds sensible.. I'm waiting on some answers from people as to how they (authors of SOCKS proxies) chose to interpret the RFC1928 w.r.t bind; do you have any comment on it?

[leniviy 0]

Hi. cjard Socks servers do not listen forever. They have listen timeout (usually 1 minute).

My thought of using socks is a separate program which runs on both peers and initially has one "control" connection between them. The problem is how to establish the first connection: necessary info (address and port) can be sent for example through e-mail.

After that the prog must act as a programmable port forwarder.

In the end Bittorrent client connects to local ip and local port, not the socks address.