[tor-dev] Anycast Exits (related : Special-use-TLD support)
burdges at gnunet.org
Wed Sep 30 12:53:45 UTC 2015
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.
Title: Anycast Exit
Author: Jeffrey Burdges
Created: 28 September 2015
Provide an anycast operation to help bootstrap Tor aware peer-to-peer
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
applications built on top of Tor can easily find their peers using
full aka useless descriptors.
We propose an AnycastExit Tor configuration option
AnycastExit <protocol> <host>:<port>
Here protocol must be a string consisting of letters, numbers, and
There are two changes Tor's behavior resulting from this option :
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 :
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.
Users enable anycast usage by adding the configuration line
Software queries the Anycast lines in the full descriptor by sending
control port the line :
This query returns
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
contains an "ACE <protocol> .." line in lexicographic order according
<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
As AllowDotExit defaults to off, applications should use the Tor
port to request a circuit to that particular exit using MapAddress:
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
Tor directory authorities could aggregate the lists of anycast
nodes, so that clients do not need to download the full descriptors.
AnycastExit could support UNIX domain sockets.
In principle, the ExitPolicy line produced by AnycastExit might
if both doing so bypasses ExitPolicyRejectPrivate, and the port could
identify the protocol.
Additionally, an application could parse the cached-descriptors*
themselves to locate exits with the desired exit policies.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the tor-dev