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.