[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Add a draft for a successor to proposal 118.
commit 20a5ec257603e025a8b08dc57c1a8390ac019598
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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.
+
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits