I have attached below the second half of the Special-Use TLD proposal that discusses how a local name service tool contact a peer-to-peer application running on an exist node
There is nothing specific here to providing name services, any peer-to -peer application might potentially want an anycast style gateway from Tor to its own network.
At the same time, this proposal is *very* hackish since Tor seems almost able to provide the same functionality with a judiciously chosen ExitPolicy lines, and a bunch of work on the application's side. And maybe that's really the right way to do it in the end.
There is no discussion here of dealing with bad exit gateways for protocols that Tor does not even know about, presumably that requires some thought as well. I donno if Tor combats exits doing highly targeted DNS manipulation all that well either though.
Jeff
Filename: xxx-anycast-exit.txt Title: Anycast Exit Author: Jeffrey Burdges Created: 28 September 2015 Status: ? Implemented-In: ?
Abstract
Provide an anycast operation to help bootstrap Tor aware peer-to-peer applications.
Overview
Peer-to-peer protocols must define a method by which new peers locate the existing swarm, but available techniques remain rather messy. We propose that Tor provide an "anycast" facility by which peer-to -peer applications built on top of Tor can easily find their peers using the full aka useless descriptors.
Server Side
We propose an AnycastExit Tor configuration option
AnycastExit <protocol> <host>:<port>
Here protocol must be a string consisting of letters, numbers, and underscores.
There are two changes Tor's behavior resulting from this option :
First, Tor adds the line "ACE <protocol> <host>:<port>" to the node's full descriptor.
Second, Tor allows connections to ip:port as if the torrc contains : ExitPolicy allow<host>:<port> As ExitPolicyRejectPrivate defaults to 1, these policies should be allowed even if the ip lies in a range usually restricted. In particular localhost and 127.0.0.1 are potentially allowed.
Client Side
Users enable anycast usage by adding the configuration line
FetchUselessDescriptors 1
Software queries the Anycast lines in the full descriptor by sending Tor control port the line :
GETINFO anycast/<protocol>/<number>
This query returns 250-anycast/<protocol>/<number>="<host>.<identity>.exit:<port>" where <identity> is a node identity for a node whose full descriptor contains the line "Anycast <protocol> <host>:<port>".
After receiving such a query for anycast nodes supporting <protocol>, Tor builds, and later maintains, a list of nodes whose full descriptor contains an "ACE <protocol> .." line in lexicographic order according to <identity>. Tor returns the <number>th node from this list. Also, if <number> exceeds the number of nodes with Anycast <protocol> lines, then an error is returned.
Clients contact the anycast server <host>.<identity>.exit on port <port>. As AllowDotExit defaults to off, applications should use the Tor control port to request a circuit to that particular exit using MapAddress: MapAddress <host>.<identity>.exit=<label> After this, the peer-to-peer application can connect to <label> over the Tor socks port.
MapAddress usually produces a four hop circuit, but many peer-to-peer applications, including name service provides, can accept the small additional latency.
Future Work
Tor directory authorities could aggregate the lists of anycast supporting nodes, so that clients do not need to download the full descriptors.
AnycastExit could support UNIX domain sockets.
Hackish Alternative
In principle, the ExitPolicy line produced by AnycastExit might suffice if both doing so bypasses ExitPolicyRejectPrivate, and the port could identify the protocol.
Additionally, an application could parse the cached-descriptors* files themselves to locate exits with the desired exit policies.
Acknowledgments
Based on discussions with George Kadianakis, Christian Grothoff. Indirectly based on discussions between Christian Grothoff and Jacob Appelbaum about accessing the GNU Name System over Tor.
On 30 Sep 2015, at 14:53, Jeff Burdges burdges@gnunet.org wrote: ... Filename: xxx-anycast-exit.txt Title: Anycast Exit Author: Jeffrey Burdges Created: 28 September 2015 Status: ? Implemented-In: ? … Server Side
We propose an AnycastExit Tor configuration option
AnycastExit <protocol> <host>:<port>
Here protocol must be a string consisting of letters, numbers, and underscores.
There are two changes Tor's behavior resulting from this option :
First, Tor adds the line "ACE <protocol> <host>:<port>" to the node's full descriptor.
Second, Tor allows connections to ip:port as if the torrc contains : ExitPolicy allow<host>:<port> As ExitPolicyRejectPrivate defaults to 1, these policies should be allowed even if the ip lies in a range usually restricted. In particular localhost and 127.0.0.1 are potentially allowed.
Tor exit policies don’t contain hostnames like “localhost", did you mean 127.0.0.0/8 and ::1?
I am concerned about the security considerations of opening up local addresses, as local processes often trust connections from the local machine. Perhaps we could clarify it to say that only the specific port on 127.0.0.0/8 and ::1 is allowed?
I also suggest that we specify the following rules based on the current (0.2.7.3) implementation of policies_parse_exit_policy_internal: * Block all IPv6 if IPv6Exit is 0 * If AnycastExit is set, allow 127.0.0.0/8:port and, if IPv6Exit is 1, [::1]:port * If ExitPolicyRejectPrivate is 1: * reject private addresses (0.0.0.0/8, 169.254.0.0/16, 127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, [::]/8, [fc00::]/7, [fe80::]/10, [fec0::]/10, [ff00::]/8, [::]/127) * reject relay’s configured IPv4 and IPv6 address * reject relay’s interfaces’ IPv4 and IPv6 addresses * Then add the default exit policy
Regards
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Wed, 2015-09-30 at 15:39 +0200, Tim Wilson-Brown - teor wrote:
First, Tor adds the line "ACE <protocol> <host>:<port>" to the node's Second, Tor allows connections to ip:port as if the torrc contains : ExitPolicy allow<host>:<port> As ExitPolicyRejectPrivate defaults to 1, these policies should be allowed even if the ip lies in a range usually restricted. In particular localhost and 127.0.0.1 are potentially allowed.
Tor exit policies don’t contain hostnames like “localhost", did you mean 127.0.0.0/8 and ::1?
I am concerned about the security considerations of opening up local addresses, as local processes often trust connections from the local machine. Perhaps we could clarify it to say that only the specific port on 127.0.0.0/8 and ::1 is allowed?
Yes, that's the effect of the ExitPolicy line described. We should not disable ExitPolicyRejectPrivate, merely ensure that the new exit policy be processed before it. I'll add some language to clarify, slightly. I'm futzing around to make sure that just an ExitPolicy line does this already too.
Jeff