Proposal: Using Perspective Access to Grow the Tor Network

[Robert Hogan]

Motivation:
  Perspective access is one of the bigger use-cases of Tor outside censorious
  regimes. The anonymity requirements of perspective-access users differ from
  the rest of Tor's user base - they don't really care about it.
  Perspective access is a collateral benefit of Tor and currently falls
  outside the project's core mission. On the other hand, one of the project's
  greatest challenges is incentivising user to run Tor servers - Tor has
  millions of users yet only a thousand or so servers up and running at any
  one time.


Proposal:

  Tor servers should offer perspective access on a distinct port (the PAPort).
  Access to this port should be restricted to the listed, running Tor servers
  that have their ORPort, DIRPort and PAPort open. The PAPort should allow and
  serve client traffic on one-hop connections. All traffic received on a
  server's PAPort exits at that server. In summary: fast, efficient
  perspective-access using non-anonymous, one-hop connections is deployed as
  an incentive to attract stable, accessible servers to the Tor network.


Benefits:

  - Users who want fast perspective-access traffic will migrate to using the
    PAPort on the Tor network. This will reserve much of the computational
    overhead of the network for anonymity users.
  - In order to use the PAPort on other servers they will have to run their
    own, fully accessible (PAPort, ORPort and DIRPort) Tor servers. This will
    add to the overall bandwidth of the network.
  - In order to use Tor's perspective access network efficiently they will need
    to run a fairly stable Tor server. This is because of the usual delay in a
    server's listing propagating through the network. If listing propagation
    becomes efficient, PAPort access could be limited to Tor servers listed as
    'stable' and 'running' only.


Problems:

1. This scheme partitions the network into anonymous and non-anonymous users.
The anonymity properties of the network are potentially damaged by this
partitioning - ORPort users become a suspect 'hard-core'.

  Mitigant: Another way of looking at this is that the scheme migrates
  non-anonymous users to server operators, which is what they should be in the
  first place. PAPort users have anonymity needs of their own and will still
  use the OR network for these needs.

  Variant To Address Problem: The PAPort could be a virtual OR connection. In
  other words, the user connects to an OR as normal and then informs the OR
  that they want to use perspective access. The OR connection then becomes a
  PA connection.

2. Could fast perspective-access usage swamp network resources?

  Mitigant: In order to use network resources, a PAPort user is forced to
  contribute network resources. This would seem to rule out overall damage to
  network performance.


Implementation:

  - A PAPort user is by definition a full ORPort, DIRPort and PAPort server.

  - The PAPort could be virtual, i.e. it could be a service negotiated on the
    ORPort after the normal OR handshake between two Tor servers. In this
    implementation, the server could advertise the availability of perspective
    access through it's descriptor.

  - Servers accepting connections on their PAPort should:
      - test the PAPort, ORPort and DIRPort of the connecting client are
        reachable and usable before permitting access.
      - test that the connecting client is a listed Tor server and can
        authenticate themselves as such.

  - PAPort servers could:
      - Log all activity on their PAPort in a compact format if they wish. The
        retention of these logs is at the user's discretion.
      - Have the ability to maintain a blacklist of PAPort clients.

  - The PAPort connection operates as a simple one-hop exit OR connection with
    another OR server.

  - The PAPort connection should have a separate ExitPolicy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20080914/fe17006b/attachment.pgp>