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.
Attachment:
signature.asc
Description: This is a digitally signed message part.