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.
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev