nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-24 12:23:32 +01:00
Code Issues Packages Projects Releases Wiki Activity

add johnny's further discussion on incentives.

Browse Source 
svn:r6115
This commit is contained in:
Roger Dingledine 2006-03-09 22:21:07 +00:00
parent e11f900a2a
commit 245fb8e8ba
1 changed files with 125 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

127
doc/incentives.txt
View File

@ -55,6 +55,11 @@
accept claims from every Tor user and build a complex weighting /
reputation system to decide which claims are "probably" right.
One possible way to implement the latter is something similar to
EigenTrust [http://www.stanford.edu/~sdkamvar/papers/eigentrust.pdf],
where the opinion of nodes with high reputation more is weighted
higher.
3. Related issues we need to keep in mind.
3.1. Relay and exit configuration needs to be easy and usable.
@ -98,6 +103,10 @@
also through indirect interaction (middle of the circuit). That way
you can never be sure when your guards are measuring you.
Both 3.2 and 3.3 may be solved by having a global notion of reputation,
as in 2.3 and 2.4. However, computing the global reputation from local
views could be expensive (O(n^2)) when the network is really large.
3.4. Restricted topology: benefits and roadmap.
As the Tor network continues to grow, we will need to make design
@ -164,6 +173,15 @@
maybe it's an argument in favor of a more penny-counting reputation
approach.
Addendum: I was more thinking of measuring based on who is the service
provider and service receiver for the circuit. Say Alice builds a
circuit to Bob. Then Bob is providing service to Alice, since he
otherwise wouldn't need to spend is bandwidth. So traffic in either
direction should be charged to Alice. Of course, the same attack would
work, namely, Bob could cheat by sending bytes back quickly. So someone
close to the origin needs to detect this and close the circuit, if
necessary. -JN
3.7. What is the appropriate resource balance for servers vs. clients?
If we build a good incentive system, we'll still need to tune it
@ -255,15 +273,106 @@
third approach is to remember which connections have recently sent
us high-priority cells, and preferentially read from those connections.
Hopefully we can get away with not solving this section at all.
Hopefully we can get away with not solving this section at all. But if
necessary, we can consult Ed Knightly, a Professor at Rice
[http://www.ece.rice.edu/~knightly/], for his extensive experience on
networking QoS.
3.11. Global reputation system: Congestion on high reputation servers?
If the notion of reputation is global (as in 2.3 or 2.4), circuits that
go through successive high reputation servers would be the fastest and
most reliable. This would incentivize everyone, regardless of their own
reputation, to choose only the highest reputation servers in its
circuits, causing an over-congestion on those servers.
One could argue, though, that once those servers are over-congested,
their bandwidth per circuit drops, which would in turn lower their
reputation in the future. A question is whether this would overall
stablize.
Another possible way is to keep a cap on reputation. In this way, a
fraction of servers would have the same high reputation, thus balancing
such load.
3.12. Another anonymity attack: learning from service levels.
If reputation is local, it may be possible for an evil node to learn
the identity of the origin through provision of differential service.
For instance, the evil node provides crappy bandwidth to everyone,
until it finds a circuit that it wants to trace the origin, then it
provides good bandwidth. Now, as only those directly or indirectly
observing this circuit would like the evil node, it can test each node
by building a circuit via each node to another evil node. If the
bandwidth is high, it is (somewhat) likely that the node was a part of
the circuit.
This problem does not exist if the reputation is global and nodes only
follow the global reputation, i.e., completely ignore their own view.
3.13. DoS through high priority traffic.
Assume there is an evil node with high reputation (or high value on
Alice) and this evil node wants to deny the service to Alice. What it
needs to do is to send a lot of traffic to Alice. To Alice, all traffic
from this evil node is of high priority. If the choice of circuits are
too based toward high priority circuits, Alice would spend most of her
available bandwidth on this circuit, thus providing poor bandwidth to
everyone else. Everyone else would start to dislike Alice, making it
even harder for her to forward other nodes' traffic. This could cause
Alice to have a low reputation, and the only high bandwidth circuit
Alice could use would be via the evil node.
4. Sample designs.
4.1. Two classes of service for circuits.
Whenever a circuit is built, it is specified by the origin which class,
either "premium" or "normal", this circuit belongs. A premium circuit
gets preferred treatment at each node. A node "spends" its value, which
it earned a priori by providing service, to the next node by sending
and receiving bytes. Once a node has overspent its values, the circuit
cannot stay as premium. It can either breaks or converts into a normal
circuit. Each node also reserves a small portion of bandwidth for
normal circuits to prevent starvation.
Pro: Even if a node has no value to spend, it can still use normal
circuits. This allow casual user to use Tor without forcing them to run
a server.
Pro: Nodes have incentive to forward traffic as quick and as much as
possible to accumulate value.
Con: There is no proactive method for a node to rebalance its debt. It
has to wait until there happens to be a circuit in the opposite
direction.
Con: A node needs to build circuits in such a way that each node in the
circuit has to have good values to the next node. This requires
non-local knowledge and makes circuits less reliable as the values are
used up in the circuit.
Con: May discourage nodes to forward traffic in some circuits, as they
worry about spending more useful values to get less useful values in
return.
4.2. Treat all the traffic from the node with the same service;
hard reputation system.
This design is similar to 4.1, except that instead of having two
classes of circuits, there is only one. All the circuits are
prioritized based on the value of the interacting node.
Pro: It is simpler to design and give priority based on connections,
not circuits.
Con: A node only needs to keep a few guard nodes happy to forward their
traffic.
Con: Same as in 4.1, may discourage nodes to forward traffic in some
circuits, as they worry about spending more useful values to get less
useful values in return.
4.3. Treat all the traffic from the node with the same service;
soft reputation system.
@ -300,7 +409,10 @@
one way through: if there are few exits, then they will attract a
lot of use, so lots of people will like them, so when they try to
use the network they will find their first hop to be particularly
pleasant. After that they're like the rest of the world though.
pleasant. After that they're like the rest of the world though. (An
alternative would be to reward exit nodes with higher values. At the
extreme, we could even ask the directory servers to suggest the extra
values, based on the current availability of exit nodes.)
Pro: this is a pretty easy design to add; and it can be phased in
incrementally simply by having new nodes behave differently.
@ -337,5 +449,16 @@
5. Recommendations and next steps.
5.1. Simulation.
For simulation trace, we can use two: one is what we obtained from Tor
and one from existing web traces.
We want to simulate all the four cases in 4.1-4. For 4.4, we may want
to look at two variations: (1) the directory servers check the
bandwidth themselves through Tor; (2) each node reports their perceived
values on other nodes, while the directory servers use EigenTrust to
compute global reputation and broadcast those.
5.2. Deploying into existing Tor network.