[tor-commits] [torspec/master] Turn my multiple-orports draft into proposal 186
nickm at torproject.org
nickm at torproject.org
Wed Sep 21 18:12:44 UTC 2011
commit 7550ae4b33ae4bde083e64991d3a942fe0b0cb20
Author: Nick Mathewson <nickm at torproject.org>
Date: Wed Sep 21 14:14:52 2011 -0400
Turn my multiple-orports draft into proposal 186
---
proposals/000-index.txt | 2 +
proposals/118-multiple-orports.txt | 2 +-
proposals/186-multiple-orports.txt | 263 ++++++++++++++++++++++++++++++
proposals/ideas/xxx-multiple-orports.txt | 263 ------------------------------
4 files changed, 266 insertions(+), 264 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index bc25574..de31a92 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -106,6 +106,7 @@ Proposals by number:
183 Refill Intervals [OPEN]
184 Miscellaneous changes for a v3 Tor link protocol [OPEN]
185 Directory caches without DirPort [OPEN]
+186 Multiple addresses for one OR or bridge [DRAFT]
Proposals by status:
@@ -119,6 +120,7 @@ Proposals by status:
175 Automatically promoting Tor clients to nodes
179 TLS certificate and parameter normalization [for 0.2.3.x]
182 Credit Bucket
+ 186 Multiple addresses for one OR or bridge
NEEDS-REVISION:
131 Help users to verify they are using Tor
NEEDS-RESEARCH:
diff --git a/proposals/118-multiple-orports.txt b/proposals/118-multiple-orports.txt
index b21f034..69ab382 100644
--- a/proposals/118-multiple-orports.txt
+++ b/proposals/118-multiple-orports.txt
@@ -3,7 +3,7 @@ Title: Advertising multiple ORPorts at once
Author: Nick Mathewson
Created: 09-Jul-2007
Status: Superseded
-Superseded-By: xxx-multiple-orports.txt
+Superseded-By: 186-multiple-orports.txt
[Needs Revision: This proposal needs revision to come up to 2011 standards
and take microdescriptors into account.]
diff --git a/proposals/186-multiple-orports.txt b/proposals/186-multiple-orports.txt
new file mode 100644
index 0000000..5b59c77
--- /dev/null
+++ b/proposals/186-multiple-orports.txt
@@ -0,0 +1,263 @@
+Filename: 186-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 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.
+
+ 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 firewall 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 they advertise
+ before they declare themselves reachable. If a Tor has
+ 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? Multiple interfaces, I guess.)
+
+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. If not, why list any more
+ than one IPv4 and one IPv6 address?)
+
+ 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
+ foreseeable 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.
+
+ That is, clients tunnel their directory requests inside OR
+ connections, and don't generally connect to DirPorts at all.
+
+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.
+
diff --git a/proposals/ideas/xxx-multiple-orports.txt b/proposals/ideas/xxx-multiple-orports.txt
deleted file mode 100644
index 4d5b7fb..0000000
--- a/proposals/ideas/xxx-multiple-orports.txt
+++ /dev/null
@@ -1,263 +0,0 @@
-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 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.
-
- 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 firewall 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 they advertise
- before they declare themselves reachable. If a Tor has
- 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? Multiple interfaces, I guess.)
-
-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. If not, why list any more
- than one IPv4 and one IPv6 address?)
-
- 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
- foreseeable 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.
-
- That is, clients tunnel their directory requests inside OR
- connections, and don't generally connect to DirPorts at all.
-
-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.
-
More information about the tor-commits
mailing list