r16896@tombo: nickm | 2008-07-11 11:45:16 -0400

 Revise proposal 118; turn it into a real proposal.


svn:r15839

doc/spec/proposals/118-multiple-orports.txt

@@ -4,63 +4,82 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Nick Mathewson
 Created: 09-Jul-2007
-Status: Draft
+Status: Accepted
-
+
-Some notes follow. Please feel free to flesh them out, discard them,
+Overview:
-add in better ideas, etc.
+
-
+   This document is a proposal for servers to advertise multiple
-  - Some way to configure which address:port combinations to listen
+   address/port combinations for their ORPort.
-    on, and/or which to advertise.
+
-
+Motivation:
-    (The best way to support lots of ports is to have your firewall
+
-    route all connections from those ports to Tor: this doesn't need
+   Sometimes servers want to support multiple ports for incoming
-    anywhere near as many listening sockets.  You only really want to
+   connections, either in order to support multiple address families, to
-    listen on tons and tons of ports if your firewalling doesn't
+   better use multiple interfaces, or to support a variety of
-    support this, or you don't have access to your local
+   FascistFirewallPorts settings.  This is easy to set up now, but
-    iptables/ipf/whatever.  But if you want to do this with the
+   there's no way to advertise it to clients.
-    firewall, you need the ability to advertise ports you aren't
+
-    actually listening on.)
+New descriptor syntax:
-
+
-    (Cat would also like to see some discussion of the effect this
+   We add a new line in the router descriptor, "or-address".  This line
-    is likely to have in environments that need to ban or limit Tor.
+   can occur zero, one, or multiple times.  Its format is:
-    "Speaking only for myself, in an environment where I need to keep
+
-    a lid on Tor usage, having to chase port settings around makes it
+      or-address SP ADDRESS ":" PORTLIST NL
-    more likely that I'm going to move from limiting Tor to just plain
+
-    banning it.")
+      ADDRESS = IP6ADDR / IP4ADDR
-
+      IPV6ADDR = an ipv6 address, surrounded by square brackets.
-  - Some way to advertise in one's router descriptor which
+      IPV4ADDR = an ipv4 address, represented as a dotted quad.
-    address:port combinations you're listening on.  For backward
+      PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST
-    compatibility this should be a new line, not a change to the
+      PORTSPEC = PORT | PORT "-" PORT
-    format of an existing line.
+
-
+   [This is the regular format for specifying sets of addresses and
-  - Possibly, some way to relay this information in network-status
+   ports in Tor.]
-    documents.
+
-
+New OR behavior:
-  - Some analysis of the impact on network-status and routerinfo
+
-    size.  My guess is "not much", but if it turns out to be a bit, we
+   We add two more options to supplement ORListenAddress:
-    should look into making the notation concise.
+   ORPublishedListenAddress, and ORPublishAddressSet.  The former
-
+   listens on an address-port combination and publishes it in addition
-  - What does this imply for self-testing of servers and testing by
+   to the regular address.  The latter advertises a set of address-port
-    authorities of servers?  What should the authorities do if one
+   combinations, but does not listen on them.  [To use this option, the
-    addr:port works but one doesn't?
+   server operator should set up port forwarding to the regular ORPort,
-
+   as for example with firewall rules.]
-  - Some way to pick which addr:port to use when you have a choice of
+
-    more than one addr:port.
+   Servers should extend their testing to include advertised addresses
-
+   and ports.  No address or port should be advertised until it's been
-  - Some way to avoid having servers open lots and lots of connections
+   tested.  [This might get expensive in practice.]
-    between them when they get extend cells to the same server on
+
-    different ports.
+New authority behavior:
-
+
-    - Suggested rule:
+   Authorities should spot-test descriptors, and reject any where a
-      - If we're told to extend to IP:Port:ID, and we have a connection
+   substantial part of the addresses can't be reached.
-        to some server with ID, and we have confirmed that the server
+
-        likes the address we originally used when connecting to it (via
+New client behavior:
-        means in proposal 105), then use the existing connection.
+
-      - If we're told to extend to IP:Port:ID, and we have a descriptor
+   When connecting to another server, clients SHOULD pick an
-        for the ID, and we have a connection to some server with ID,
+   address-port ocmbination at random as supported by their
-        and the existing connection is to an address listed as valid
+   reachableaddresses.  If a client has a connection to a server at one
-        in the descriptor, then use the existing connection.
+   address, it SHOULD use that address for any simultaneous connections
-      - Otherwise, use a new connection.
+   to that server.  Clients SHOULD use the canonical address for any
-
+   server when generating extend cells.
-  - How this all interacts with coderman's ipv6 stuff (proposal 117).
+
+Not addressed here:
+
+   * There's no reason to listen on multiple dirports; current Tors
+   mostly don't connect directly to the dirport anyway.
+
+   * It could be advantageous to list something about extra addresses in
+   the network-status document.  This would, however, eat space there.
+   More analysis is needed, particularly in light of proposal 141
+   ("Download server descriptors on demand")
+
+Dependencies:
+
+   Testing for canonical connections needs to be implemented before it's
+   safe to use this proposal.
+
+
+Notes 3 July:
+  - Write up the simple version of this.  No ranges needed yet.  No
+    networkstatus chagnes yet.