[tor-dev] Anycast Exits (related : Special-use-TLD support)

[Jeff Burdges]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150930/fd93a98d/attachment.sig>