On Thu, Sep 22, 2011 at 3:43 AM, Karsten Loesing <[email protected]> wrote: > Hi Nick, > > a few comments to proposal 186 below: > > On 9/21/11 8:13 PM, Nick Mathewson wrote: >> In consonance with our changes to the (Socks|Trans|NATD|DNS)Port >> options made in 0.2.3.x for proposal 171, I make a corresponding >> change to allow multiple SocksPort options and deprecate >> SocksListenAddress. > > When you say "Socks" in this document in most cases you mean "OR".
Yeowch, you're right. >> The new syntax will be: >> >> "SocksPort" PortDescription Options? > > The syntax allows multiple options per SocksPort line, right? Would > that be "Options*" then? Yup. >> The 'NoListen' option tells Tor to advertise an address, but not >> bind to it. The operator needs to use some other mechanism to >> ensure that ports are redirected to ports that _are_ listened on. > > Do we need to check that we have at least one SocksPort line without the > NoListen option? s/SocksPort/ORPort/ No, but we shouldn't advertise ourselves unless we do, just like we currently don't advertise ourselves unless we have an ORPort set. >> In current operating systems (unless we get into crazy nonportable >> tricks) we need to use one socket for every address:port that Tor >> bind on. As a sanity check, we can limit the number of such >> sockets we use to, say, 64. If you want to bind lots more >> address:port combinations, you'll want to do it at the >> firewall/routing level. > > 64 seems very high for the number sockets to open. If someone wants to > open more than 8 sockets and doesn't know how to edit firewall rules, > that person probably shouldn't be opening this number of sockets. Feels bikesheddy to me; any power of two between 8 and 64 seems fine here. >> Example: Our firewall is redirecting ports 80, 443, and 7000-8000 >> on all hosts in x.244.2.0/24 onto our port 2929. >> >> SocksPort 2929 no-advertise >> SocksPort x.244.2.0/24:80,443,7000-8000 no-listen > > "no-advertise" -> "noadvertise" > > "no-listen" -> "nolisten" > > The "/24" should probably also go away. Done. >> Example: We have a dynamic DNS provider that maps >> tornode.example.com to our current external IPv4 and IPv6 >> addresses. Our firewall forwards port 443 on those address to our >> port 1337. >> >> SocksPort 1337 no-advertise alladdrs >> SocksPort tornode.example.com:443 no-bind alladdrs > > "no-advertise" -> "noadvertise" > > "no-bind" -> "nolisten" done. > I wonder what the effect of putting in a dynamic hostname is. Tor uses > an IP address in the server descriptor anyway, and wouldn't it find out > the IP address(es) by itself? You can already specify a hostname as your Address, I believe; this is meant to work the same. >> It will now be possible for a Tor node to find that some addresses >> work and others do not. In this case, the node should only >> advertise socksport lines that have been checked. > > What if a partial SocksPort line was found to work, that is, if only a > few ports work? Then, by the terms of this document, the whole socksport line is discarded. >> A node must not list more than 8 or-address lines. > > Should there also be a restriction of PORTSPECs per line? I can imagine > how these lines can get quite long: 1.2.3.4:1-2,4-5,7-8,... Good point. Also, they should be disjoint. I've made changes in the torspec git repo corresponding to notes above. Thanks! -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
