[tor-dev] Proposal 186: Multiple addresses for one OR or bridge

Nick Mathewson nickm at torproject.org
Thu Sep 22 21:19:17 UTC 2011


On Thu, Sep 22, 2011 at 3:43 AM, Karsten Loesing
<karsten.loesing at gmx.net> 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


More information about the tor-dev mailing list