[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [torspec/master] Turn my multiple-orports draft into proposal 186



commit 7550ae4b33ae4bde083e64991d3a942fe0b0cb20
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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.
-

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits