commit 20a5ec257603e025a8b08dc57c1a8390ac019598 Author: Nick Mathewson nickm@torproject.org Date: Tue Sep 20 15:35:14 2011 -0400

Add a draft for a successor to proposal 118. --- proposals/000-index.txt | 12 +- proposals/118-multiple-orports.txt | 3 +- proposals/ideas/xxx-multiple-orports.txt | 259 ++++++++++++++++++++++++++++++ 3 files changed, 269 insertions(+), 5 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt index c4106e8..bc25574 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -38,7 +38,7 @@ Proposals by number: 115 Two Hop Paths [DEAD] 116 Two hop paths from entry guards [DEAD] 117 IPv6 exits [ACCEPTED] -118 Advertising multiple ORPorts at once [NEEDS-REVISION] +118 Advertising multiple ORPorts at once [SUPERSEDED] 119 New PROTOCOLINFO command for controllers [CLOSED] 120 Shutdown descriptors when Tor servers stop [DEAD] 121 Hidden Service Authentication [FINISHED] @@ -103,7 +103,9 @@ Proposals by number: 180 Pluggable transports for circumvention [OPEN] 181 Optimistic Data for Tor: Client Side [CLOSED] 182 Credit Bucket [DRAFT] -183 Refill Intervals [CLOSED] +183 Refill Intervals [OPEN] +184 Miscellaneous changes for a v3 Tor link protocol [OPEN] +185 Directory caches without DirPort [OPEN]

Proposals by status: @@ -118,7 +120,6 @@ Proposals by status: 179 TLS certificate and parameter normalization [for 0.2.3.x] 182 Credit Bucket NEEDS-REVISION: - 118 Advertising multiple ORPorts at once 131 Help users to verify they are using Tor NEEDS-RESEARCH: 145 Separate "suitable as a guard" from "suitable as a new guard" @@ -134,6 +135,9 @@ Proposals by status: 177 Abstaining from votes on individual flags [for 0.2.3.x] 178 Require majority of authorities to vote for consensus parameters [for 0.2.3.x] 180 Pluggable transports for circumvention [for 0.2.3.x] + 183 Refill Intervals + 184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x] + 185 Directory caches without DirPort ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.3.x] @@ -187,10 +191,10 @@ Proposals by status: 171 Separate streams across circuits by connection metadata [in 0.2.3.3-alpha] 174 Optimistic Data for Tor: Server Side [in 0.2.3.1-alpha] 181 Optimistic Data for Tor: Client Side [in 0.2.3.3-alpha] - 183 Refill Intervals [in 0.2.3.4-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration + 118 Advertising multiple ORPorts at once 124 Blocking resistant TLS certificate usage 149 Using data from NETINFO cells 153 Automatic software update protocol diff --git a/proposals/118-multiple-orports.txt b/proposals/118-multiple-orports.txt index 64a6000..b21f034 100644 --- a/proposals/118-multiple-orports.txt +++ b/proposals/118-multiple-orports.txt @@ -2,7 +2,8 @@ Filename: 118-multiple-orports.txt Title: Advertising multiple ORPorts at once Author: Nick Mathewson Created: 09-Jul-2007 -Status: Needs-Revision +Status: Superseded +Superseded-By: xxx-multiple-orports.txt

[Needs Revision: This proposal needs revision to come up to 2011 standards and take microdescriptors into account.] diff --git a/proposals/ideas/xxx-multiple-orports.txt b/proposals/ideas/xxx-multiple-orports.txt new file mode 100644 index 0000000..fc3a741 --- /dev/null +++ b/proposals/ideas/xxx-multiple-orports.txt @@ -0,0 +1,259 @@ +Filename: xxx-multiple-orports.txt +Title: Multiple addresses for one OR or bridge +Author: Nick Mathewson +Created: 19-Sep-2011 +Supersedes: 118 +Status: Draft + +Overview: + + This document is a proposal for servers to advertise multiple + address/port combinations for their ORPort. + + It supersedes proposal 118. + +Motivation: + + Sometimes servers want to support multiple ports for incoming + connections, either in order to support multiple address families + (ie, to add IPv6 support), to better use multiple interfaces, or + to support a variety of FascistFirewallPorts settings. This is + easy to set up now, but there's no way to advertise it to clients. + +Configuring additional addresses and ports: + + In consonance with our chances 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. + + The new syntax will be: + + "SocksPort" PortDescription Options? + + Options = "NoAdvertise" | "NoListen" | "AllAddrs" | "IPV4Only" + | "IPV6Only" + + PortDescription = PORTLIST | + ADDRESS ":" PORTLIST | + Hostname ":" PORTLIST + + (PORTLIST and ADDRESS are defined below.) + + The 'NoAdvertise' option performs the function of the old + SocksListenAddress option. If it is set, we bind a port, but + don't put it in our descriptor. + + 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. + + The 'AllAddrs' option tells Tor that if no address is given in the + PortDescription part, we should bind/advertise every one of our + publicly visible unicast addresses; and that if a hostname address + is given in the PortDescription, we should bind/advertise every + publicly visible unicast address that the hostname resolves to. + (Q: Should this be on by default?) The 'IPv4Only' and 'IPv6Only' + options tell Tor to interpret such situations as applying only to + IPv4 addresses or to IPv6 addresses. + + As with the client *Port options, only the old format or the new + format are allowed: either a single numeric socksport and zero or + more sockslistenaddress options, or a set of one or more + SocksPorts in the new extended format. + + 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. + + Example: We want to bind on 0.0.0.0:9001 + + SocksPort 9001 + + 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 + + Example: We have a dynamic DNS provider that maps + tornode.example.com to our current external IPv4 and IPv6 + addresses. Our firefall forwards port 443 on those address to our + port 1337. + + SocksPort 1337 no-advertise alladdrs + SocksPort tornode.example.com:443 no-bind alladdrs + +Self-testing: + + Right now, Tor nodes need to check every port that advertise + before they declare themselves reachable. If a Tor has a large IP + a lot of advertised ports, that could be prohibitive. + Instead, it should try a sample of ports for each address. It should + not advertise any given SocksPort line until it has tried + extending to or connecting to a sample of the address/port + combinations. + + 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. + + {Until support is added for extend cells to IPv6 addresses, it + will only be possible to test IPv6 addresses by connecting + directly. We might want to just skip self-testing those until we + have IPv6 extend support.} + +New descriptor syntax: + + We add a new line in the router descriptor, "or-address". This line + can occur zero, one, or multiple times. Its format is: + + or-address SP ADDRESS ":" PORTLIST NL + + ADDRESS = IP6ADDR | IP4ADDR + IPV6ADDR = an ipv6 address, surrounded by square brackets. + IPV4ADDR = an ipv4 address, represented as a dotted quad. + PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST + PORTSPEC = PORT | PORT "-" PORT + PORT = a number between 1 and 65535 inclusive. + + [This is the regular format for specifying sets of addresses and + ports in Tor.] + + A descriptor should not include an or-address line that does + nothing but duplicate the address:port pair from its "router" + line. + + A node must not list more than 8 or-address lines. + + (Q: Any reason to allow more than 2?) + +New authority behavior: + + The same rationale applies as for self-testing. An authority + needs to test the main address:port from the router line, and + every or-address line. For or-address lines that contains + multiple ports, it needs to test all of them if they are few, or a + sample if they are not. + + An authority shouldn't list a node as Running unless every + or-address line it advertises looks like it will work. + +Consensus directories and microdescriptors: + + We introduce a new line type for microdescriptors and consensuses, + "a". Each "a" line has the same format as an or-address line. + The "a" lines (if any) appear immediately after the "r" line for a + router in the consensus, and immediately after the "onion-key" + entry in a microdescriptor. + + Clients that use microdescriptors should consider a node's + addresses to be the address:port listed in the "r" line of a + consensus, plus all "a" lines for that node in the consensus, plus + all "a" lines for that node in the its microdescriptor. Clients + that use full descriptors should consider a node's addresses to be + everything listed in its descriptor. + + We will have to define a new voting algorithm version; when using + this version or later, votes should include a single "a" line for + every relay that has an IPv6 address, to include the first IPv6 + line in its descriptor. (If there are no or-address lines, then + they shouldn't include any "a" lines.) The remaining or-address + lines will turn into "a" lines in the microdescriptor. + + As with other data in the vote derived from the descriptor, + the vote will include whichever set of "a" lines are given by the + most authorities who voted for the descriptor digest that will be + used for the router. + +Directory authorities with more addresses: + + We need a way for a client to configure a TrustedDirServer as + having multiple OR addresses, specifically so that we can give at + least one default authority an IPv6 address for bootstrapping + purposes. + + (Q: Do any of the current authorities have stable IPv6 addresses?) + + We will want to allow the address in a "dir-source" line in a vote + to contain an IPv6 address, and/or allow voters to list themselves + with more addresses in votes/consensuses. But right now, nothing + actually uses the addresses listed for voters in dir-source lines + for anything besides log messages. + +Client behavior: + + I propose that initially we shouldn't change client behavior too + much here. + + (Q: Is there any advantage to having a client choose a random + address? If so we can do it later.) + + Tor clients not running with bridges, and running with IPv4 + support, should still use the address and ORPort as advertised in + the router or r line of the appropriate directory object. + + Tor clients not running with bridges, and running without IPv4 + support, should use the first listed IPv6 address for a node, + using the lowest-numbered listed port for that address. They + should only connect to nodes with an IPv6 address. + + Clients should accept Bridge lines with IPv6 addresses, and + address:port sets, in addition to the lines they currently accept. + + Clients, for now, should only use the address:port from the router + line when making EXTEND cells; see below. + +Nodes without IPv4 addresses: + + Currently Tor requires every node or bridge to have an IPv4 + address. We will want to maintain this property for the + forseeable future, but we should define how a node without an IPv4 + address would advertise itself. + + Right now, there's no way to do that: if anything but an IPv4 + address appears in a router line of a routerdesc, or the r line of + a consensus, then it won't parse. If something that looks like an + IPv4 address appears there, clients will (I believe) try to + connect to it. + + We can make this work, though: let's allow nodes to list themselves + with a magic IPv4 address (say, 127.1.1.1) if they have + or-address entries containing only IPv6 address. We could give + these nodes a new flag other than Running to indicate that they're + up, and not give them the Running flag. That way, old clients + would never try to use them, but new clients could know to treat + the new flag as indicating that the node is running, and know not + to connect to a node listed with address 127.1.1.1. + +Interaction with EXTEND and NETINFO: + + Currently, EXTEND cells only support IPv4 addresses, so we should + use only those. There is a proposal draft to support more address + types. + + A server's NETINFO cells must list all configured addresses for a + server. + +Why not extend DirPort this way too? + + Because clients are all using BEGINDIR these days. + +Why not have address ranges? + + Earlier drafts of this proposal suggested that clients should + provide not only ranges of ports, but also ranges of addresses, + specified with bitmasks. That's a neat idea for circumvention, + but if we did that, you wouldn't want to advertise publicly that + you have an entire address range. + +Coding impact: + + In addition to the obvious changes, we need to audit everything + that looks up or compares OR connections and nodes by address:port + under the assumptions that each node has only a single address or + ORPort. +