diff options
author | Nick Mathewson <nickm@torproject.org> | 2008-07-11 16:33:36 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2008-07-11 16:33:36 +0000 |
commit | 9b3befeb858c10136c05e89c37642be878c92ccc (patch) | |
tree | 39c8b997933e8f2d2b16e20197a8b8dbdc216b3f /doc | |
parent | 9231858ff54d9c8eda671bf9fe69f019b136f35d (diff) | |
download | tor-9b3befeb858c10136c05e89c37642be878c92ccc.tar tor-9b3befeb858c10136c05e89c37642be878c92ccc.tar.gz |
r16896@tombo: nickm | 2008-07-11 11:45:16 -0400
Revise proposal 118; turn it into a real proposal.
svn:r15839
Diffstat (limited to 'doc')
-rw-r--r-- | doc/spec/proposals/118-multiple-orports.txt | 137 |
1 files changed, 78 insertions, 59 deletions
diff --git a/doc/spec/proposals/118-multiple-orports.txt b/doc/spec/proposals/118-multiple-orports.txt index 411d51063..ed6296786 100644 --- a/doc/spec/proposals/118-multiple-orports.txt +++ b/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 - -Some notes follow. Please feel free to flesh them out, discard them, -add in better ideas, etc. - - - Some way to configure which address:port combinations to listen - on, and/or which to advertise. - - (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 - anywhere near as many listening sockets. You only really want to - listen on tons and tons of ports if your firewalling doesn't - support this, or you don't have access to your local - iptables/ipf/whatever. But if you want to do this with the - firewall, you need the ability to advertise ports you aren't - actually listening on.) - - (Cat would also like to see some discussion of the effect this - is likely to have in environments that need to ban or limit Tor. - "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 - more likely that I'm going to move from limiting Tor to just plain - banning it.") - - - Some way to advertise in one's router descriptor which - address:port combinations you're listening on. For backward - compatibility this should be a new line, not a change to the - format of an existing line. - - - Possibly, some way to relay this information in network-status - documents. - - - 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 - should look into making the notation concise. - - - What does this imply for self-testing of servers and testing by - authorities of servers? What should the authorities do if one - addr:port works but one doesn't? - - - Some way to pick which addr:port to use when you have a choice of - more than one addr:port. - - - Some way to avoid having servers open lots and lots of connections - between them when they get extend cells to the same server on - different ports. - - - Suggested rule: - - If we're told to extend to IP:Port:ID, and we have a connection - to some server with ID, and we have confirmed that the server - likes the address we originally used when connecting to it (via - means in proposal 105), then use the existing connection. - - If we're told to extend to IP:Port:ID, and we have a descriptor - for the ID, and we have a connection to some server with ID, - and the existing connection is to an address listed as valid - in the descriptor, then use the existing connection. - - Otherwise, use a new connection. - - - How this all interacts with coderman's ipv6 stuff (proposal 117). +Status: Accepted + +Overview: + + This document is a proposal for servers to advertise multiple + address/port combinations for their ORPort. + +Motivation: + + Sometimes servers want to support multiple ports for incoming + connections, either in order to support multiple address families, 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. + +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 + + [This is the regular format for specifying sets of addresses and + ports in Tor.] + +New OR behavior: + + We add two more options to supplement ORListenAddress: + ORPublishedListenAddress, and ORPublishAddressSet. The former + listens on an address-port combination and publishes it in addition + to the regular address. The latter advertises a set of address-port + combinations, but does not listen on them. [To use this option, the + server operator should set up port forwarding to the regular ORPort, + as for example with firewall rules.] + + Servers should extend their testing to include advertised addresses + and ports. No address or port should be advertised until it's been + tested. [This might get expensive in practice.] + +New authority behavior: + + Authorities should spot-test descriptors, and reject any where a + substantial part of the addresses can't be reached. + +New client behavior: + + When connecting to another server, clients SHOULD pick an + address-port ocmbination at random as supported by their + reachableaddresses. If a client has a connection to a server at one + address, it SHOULD use that address for any simultaneous connections + to that server. Clients SHOULD use the canonical address for any + server when generating extend cells. + +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. |