incentives.txt 23 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479
  1. Tor Incentives Design Brainstorms
  2. 1. Goals: what do we want to achieve with an incentive scheme?
  3. 1.1. Encourage users to provide good relay service (throughput, latency).
  4. 1.2. Encourage users to allow traffic to exit the Tor network from
  5. their node.
  6. 2. Approaches to learning who should get priority.
  7. 2.1. "Hard" or quantitative reputation tracking.
  8. In this design, we track the number of bytes and throughput in and
  9. out of nodes we interact with. When a node asks to send or receive
  10. bytes, we provide service proportional to our current record of the
  11. node's value. One approach is to let each circuit be either a normal
  12. circuit or a premium circuit, and nodes can "spend" their value by
  13. sending and receiving bytes on premium circuits: see section 4.1 for
  14. details of this design. Another approach (section 4.2) would treat
  15. all traffic from the node with the same priority class, and so nodes
  16. that provide resources will get and provide better service on average.
  17. This approach could be complemented with an anonymous e-cash
  18. implementation to let people spend reputations gained from one context
  19. in another context.
  20. 2.2. "Soft" or qualitative reputation tracking.
  21. Rather than accounting for every byte (if I owe you a byte, I don't
  22. owe it anymore once you've spent it), instead I keep a general opinion
  23. about each server: my opinion increases when they do good work for me,
  24. and it decays with time, but it does not decrease as they send traffic.
  25. Therefore we reward servers who provide value to the system without
  26. nickle and diming them at each step. We also let them benefit from
  27. relaying traffic for others without having to "reserve" some of the
  28. payment for their own use. See section 4.3 for a possible design.
  29. 2.3. Centralized opinions from the reputation servers.
  30. The above approaches are complex and we don't have all the answers
  31. for them yet. A simpler approach is just to let some central set
  32. of trusted servers (say, the Tor directory servers) measure whether
  33. people are contributing to the network, and provide a signal about
  34. which servers should be rewarded. They can even do the measurements
  35. via Tor so servers can't easily perform only when they're being
  36. tested. See section 4.4.
  37. 2.4. Reputation servers that aggregate opinions.
  38. The option above has the directory servers doing all of the
  39. measurements. This doesn't scale. We can set it up so we have "deputy
  40. testers" -- trusted other nodes that do performance testing and report
  41. their results.
  42. If we want to be really adventurous, we could even
  43. accept claims from every Tor user and build a complex weighting /
  44. reputation system to decide which claims are "probably" right.
  45. One possible way to implement the latter is something similar to
  46. EigenTrust [http://www.stanford.edu/~sdkamvar/papers/eigentrust.pdf],
  47. where the opinion of nodes with high reputation more is weighted
  48. higher.
  49. 3. Related issues we need to keep in mind.
  50. 3.1. Relay and exit configuration needs to be easy and usable.
  51. Implicit in all of the above designs is the need to make it easy to
  52. run a Tor server out of the box. We need to make it stable on all
  53. common platforms (including XP), it needs to detect its available
  54. bandwidth and not overreach that, and it needs to help the operator
  55. through opening up ports on his firewall. Then we need a slick GUI
  56. that lets people click a button or two rather than editing text files.
  57. Once we've done all this, we'll hit our first big question: is
  58. most of the barrier to growth caused by the unusability of the current
  59. software? If so, are the rest of these incentive schemes superfluous?
  60. 3.2. The network effect: how many nodes will you interact with?
  61. One of the concerns with pairwise reputation systems is that as the
  62. network gets thousands of servers, the chance that you're going to
  63. interact with a given server decreases. So if 90% of interactions
  64. don't have any prior information, the "local" incentive schemes above
  65. are going to degrade. This doesn't mean they're pointless -- it just
  66. means we need to be aware that this is a limitation, and plan in the
  67. background for what step to take next. (It seems that e-cash solutions
  68. would scale better, though they have issues of their own.)
  69. 3.3. Guard nodes
  70. As of Tor 0.1.1.11, Tor users pick from a small set of semi-permanent
  71. "guard nodes" for their first hop of each circuit. This seems like it
  72. would have a big impact on pairwise reputation systems since you
  73. will only be cashing in on your reputation to a few people, and it is
  74. unlikely that a given pair of nodes will use each other as guard nodes.
  75. What does this imply? For one, it means that we don't care at all
  76. about the opinions of most of the servers out there -- we should
  77. focus on keeping our guard nodes happy with us.
  78. One conclusion from that is that our design needs to judge performance
  79. not just through direct interaction (beginning of the circuit) but
  80. also through indirect interaction (middle of the circuit). That way
  81. you can never be sure when your guards are measuring you.
  82. Both 3.2 and 3.3 may be solved by having a global notion of reputation,
  83. as in 2.3 and 2.4. However, computing the global reputation from local
  84. views could be expensive (O(n^2)) when the network is really large.
  85. 3.4. Restricted topology: benefits and roadmap.
  86. As the Tor network continues to grow, we will need to make design
  87. changes to the network topology so that each node does not need
  88. to maintain connections to an unbounded number of other nodes. For
  89. anonymity's sake, we may partition the network such that all
  90. the nodes have the same belief about the divisions and each node is
  91. in only one partition. (The alternative is that every user fetches
  92. his own random subset of the overall node list -- this is bad because
  93. of intersection attacks.)
  94. Therefore the "network horizon" for each user will stay bounded,
  95. which helps against the above issues in 3.2 and 3.3.
  96. It could be that the core of long-lived servers will all get to know
  97. each other, and so the critical point that decides whether you get
  98. good service is whether the core likes you. Or perhaps it will turn
  99. out to work some other way.
  100. A special case here is the social network, where the network isn't
  101. partitioned randomly but instead based on some external properties.
  102. Social network topologies can provide incentives in other ways, because
  103. people may be more inclined to help out their friends, and more willing
  104. to relay traffic if most of the traffic they are relaying comes
  105. from their friends. It also opens the door for out-of-band incentive
  106. schemes because of the out-of-band links in the graph.
  107. 3.5. Profit-maximizing vs. Altruism.
  108. There are some interesting game theory questions here.
  109. First, in a volunteer culture, success is measured in public utility
  110. or in public esteem. If we add a reward mechanism, there's a risk that
  111. reward-maximizing behavior will surpass utility- or esteem-maximizing
  112. behavior.
  113. Specifically, if most of our servers right now are relaying traffic
  114. for the good of the community, we may actually *lose* those volunteers
  115. if we turn the act of relaying traffic into a selfish act.
  116. I am not too worried about this issue for now, since we're aiming
  117. for an incentive scheme so effective that it produces tens of
  118. thousands of new servers.
  119. 3.6. What part of the node's performance do you measure?
  120. We keep referring to having a node measure how well the other nodes
  121. receive bytes. But don't leeching clients receive bytes just as well
  122. as servers?
  123. Further, many transactions in Tor involve fetching lots of
  124. bytes and not sending very many. So it seems that we want to turn
  125. things around: we need to measure how quickly a node is _sending_
  126. us bytes, and then only send it bytes in proportion to that.
  127. However, a sneaky user could simply connect to a node and send some
  128. traffic through it, and voila, he has performed for the network. This
  129. is no good. The first fix is that we only count if you're receiving
  130. bytes "backwards" in the circuit. Now the sneaky user needs to
  131. construct a circuit such that his node appears later in the circuit,
  132. and then send some bytes back quickly.
  133. Maybe that complexity is sufficient to deter most lazy users. Or
  134. maybe it's an argument in favor of a more penny-counting reputation
  135. approach.
  136. Addendum: I was more thinking of measuring based on who is the service
  137. provider and service receiver for the circuit. Say Alice builds a
  138. circuit to Bob. Then Bob is providing service to Alice, since he
  139. otherwise wouldn't need to spend his bandwidth. So traffic in either
  140. direction should be charged to Alice. Of course, the same attack would
  141. work, namely, Bob could cheat by sending bytes back quickly. So someone
  142. close to the origin needs to detect this and close the circuit, if
  143. necessary. -JN
  144. 3.7. What is the appropriate resource balance for servers vs. clients?
  145. If we build a good incentive system, we'll still need to tune it
  146. to provide the right bandwidth allocation -- if we reserve too much
  147. bandwidth for fast servers, then we're wasting some potential, but
  148. if we reserve too little, then fewer people will opt to become servers.
  149. In fact, finding an optimum balance is especially hard because it's
  150. a moving target: the better our incentive mechanism (and the lower
  151. the barrier to setup), the more servers there will be. How do we find
  152. the right balance?
  153. One answer is that it doesn't have to be perfect: we can err on the
  154. side of providing extra resources to servers. Then we will achieve our
  155. desired goal -- when people complain about speed, we can tell them to
  156. run a server, and they will in fact get better performance.
  157. 3.8. Anonymity attack: fast connections probably come from good servers.
  158. If only fast servers can consistently get good performance in the
  159. network, they will stand out. "Oh, that connection probably came from
  160. one of the top ten servers in the network." Intersection attacks over
  161. time can improve the certainty of the attack.
  162. I'm not too worried about this. First, in periods of low activity,
  163. many different people might be getting good performance. This dirties
  164. the intersection attack. Second, with many of these schemes, we will
  165. still be uncertain whether the fast node originated the traffic, or
  166. was the entry node for some other lucky user -- and we already accept
  167. this level of attack in other cases such as the Murdoch-Danezis attack
  168. [http://freehaven.net/anonbib/#torta05].
  169. 3.9. How do we allocate bandwidth over the course of a second?
  170. This may be a simple matter of engineering, but it still needs to be
  171. addressed. Our current token bucket design refills each bucket once a
  172. second. If we have N tokens in our bucket, and we don't know ahead of
  173. time how many connections are going to want to send out how many bytes,
  174. how do we balance providing quick service to the traffic that is
  175. already here compared to providing service to potential high-importance
  176. future traffic?
  177. If we have only two classes of service, here is a simple design:
  178. At each point, when we are 1/t through the second, the total number
  179. of non-priority bytes we are willing to send out is N/t. Thus if N
  180. priority bytes are waiting at the beginning of the second, we drain
  181. our whole bucket then, and otherwise we provide some delayed service
  182. to the non-priority bytes.
  183. Does this design expand to cover the case of three priority classes?
  184. Ideally we'd give each remote server its own priority number. Or
  185. hopefully there's an easy design in the literature to point to --
  186. this is clearly not my field.
  187. Is our current flow control mechanism (each circuit and each stream
  188. start out with a certain window, and once they've exhausted it they
  189. need to receive an ack before they can send more) going to have
  190. problems with this new design now that we'll be queueing more bytes
  191. for less preferred nodes? If it turns out we do, the first fix is
  192. to have the windows start out at zero rather than start out full --
  193. it will slow down the startup phase but protect us better.
  194. While we have outgoing cells queued for a given server, we have the
  195. option of reordering them based on the priority of the previous hop.
  196. Is this going to turn out to be useful? If we're the exit node (that
  197. is, there is no previous hop) what priority do those cells get?
  198. Should we do this prioritizing just for sending out bytes (as I've
  199. described here) or would it help to do it also for receiving bytes?
  200. See next section.
  201. 3.10. Different-priority cells arriving on the same TCP connection.
  202. In some of the proposed designs, servers want to give specific circuits
  203. priority rather than having all circuits from them get the same class
  204. of service.
  205. Since Tor uses TCP's flow control for rate limiting, this constraints
  206. our design choices -- it is easy to give different TCP connections
  207. different priorities, but it is hard to give different cells on the
  208. same connection priority, because you have to read them to know what
  209. priority they're supposed to get.
  210. There are several possible solutions though. First is that we rely on
  211. the sender to reorder them so the highest priority cells (circuits) are
  212. more often first. Second is that if we open two TCP connections -- one
  213. for the high-priority cells, and one for the low-priority cells. (But
  214. this prevents us from changing the priority of a circuit because
  215. we would need to migrate it from one connection to the other.) A
  216. third approach is to remember which connections have recently sent
  217. us high-priority cells, and preferentially read from those connections.
  218. Hopefully we can get away with not solving this section at all. But if
  219. necessary, we can consult Ed Knightly, a Professor at Rice
  220. [http://www.ece.rice.edu/~knightly/], for his extensive experience on
  221. networking QoS.
  222. 3.11. Global reputation system: Congestion on high reputation servers?
  223. If the notion of reputation is global (as in 2.3 or 2.4), circuits that
  224. go through successive high reputation servers would be the fastest and
  225. most reliable. This would incentivize everyone, regardless of their own
  226. reputation, to choose only the highest reputation servers in its
  227. circuits, causing an over-congestion on those servers.
  228. One could argue, though, that once those servers are over-congested,
  229. their bandwidth per circuit drops, which would in turn lower their
  230. reputation in the future. A question is whether this would overall
  231. stabilize.
  232. Another possible way is to keep a cap on reputation. In this way, a
  233. fraction of servers would have the same high reputation, thus balancing
  234. such load.
  235. 3.12. Another anonymity attack: learning from service levels.
  236. If reputation is local, it may be possible for an evil node to learn
  237. the identity of the origin through provision of differential service.
  238. For instance, the evil node provides crappy bandwidth to everyone,
  239. until it finds a circuit that it wants to trace the origin, then it
  240. provides good bandwidth. Now, as only those directly or indirectly
  241. observing this circuit would like the evil node, it can test each node
  242. by building a circuit via each node to another evil node. If the
  243. bandwidth is high, it is (somewhat) likely that the node was a part of
  244. the circuit.
  245. This problem does not exist if the reputation is global and nodes only
  246. follow the global reputation, i.e., completely ignore their own view.
  247. 3.13. DoS through high priority traffic.
  248. Assume there is an evil node with high reputation (or high value on
  249. Alice) and this evil node wants to deny the service to Alice. What it
  250. needs to do is to send a lot of traffic to Alice. To Alice, all traffic
  251. from this evil node is of high priority. If the choice of circuits are
  252. too based toward high priority circuits, Alice would spend most of her
  253. available bandwidth on this circuit, thus providing poor bandwidth to
  254. everyone else. Everyone else would start to dislike Alice, making it
  255. even harder for her to forward other nodes' traffic. This could cause
  256. Alice to have a low reputation, and the only high bandwidth circuit
  257. Alice could use would be via the evil node.
  258. 3.14. If you run a fast server, can you run your client elsewhere?
  259. A lot of people want to run a fast server at a colocation facility,
  260. and then reap the rewards using their cablemodem or DSL Tor client.
  261. If we use anonymous micropayments, where reputation can literally
  262. be transferred, this is trivial.
  263. If we pick a design where servers accrue reputation and can only
  264. use it themselves, though, the clients can configure the servers as
  265. their entry nodes and "inherit" their reputation. In this approach
  266. we would let servers configure a set of IP addresses or keys that get
  267. "like local" service.
  268. 4. Sample designs.
  269. 4.1. Two classes of service for circuits.
  270. Whenever a circuit is built, it is specified by the origin which class,
  271. either "premium" or "normal", this circuit belongs. A premium circuit
  272. gets preferred treatment at each node. A node "spends" its value, which
  273. it earned a priori by providing service, to the next node by sending
  274. and receiving bytes. Once a node has overspent its values, the circuit
  275. cannot stay as premium. It either breaks or converts into a normal
  276. circuit. Each node also reserves a small portion of bandwidth for
  277. normal circuits to prevent starvation.
  278. Pro: Even if a node has no value to spend, it can still use normal
  279. circuits. This allow casual user to use Tor without forcing them to run
  280. a server.
  281. Pro: Nodes have incentive to forward traffic as quick and as much as
  282. possible to accumulate value.
  283. Con: There is no proactive method for a node to rebalance its debt. It
  284. has to wait until there happens to be a circuit in the opposite
  285. direction.
  286. Con: A node needs to build circuits in such a way that each node in the
  287. circuit has to have good values to the next node. This requires
  288. non-local knowledge and makes circuits less reliable as the values are
  289. used up in the circuit.
  290. Con: May discourage nodes to forward traffic in some circuits, as they
  291. worry about spending more useful values to get less useful values in
  292. return.
  293. 4.2. Treat all the traffic from the node with the same service;
  294. hard reputation system.
  295. This design is similar to 4.1, except that instead of having two
  296. classes of circuits, there is only one. All the circuits are
  297. prioritized based on the value of the interacting node.
  298. Pro: It is simpler to design and give priority based on connections,
  299. not circuits.
  300. Con: A node only needs to keep a few guard nodes happy to forward their
  301. traffic.
  302. Con: Same as in 4.1, may discourage nodes to forward traffic in some
  303. circuits, as they worry about spending more useful values to get less
  304. useful values in return.
  305. 4.3. Treat all the traffic from the node with the same service;
  306. soft reputation system.
  307. Rather than a guaranteed system with accounting (as 4.1 and 4.2),
  308. we instead try for a best-effort system. All bytes are in the same
  309. class of service. You keep track of other Tors by key, and give them
  310. service proportional to the service they have given you. That is, in
  311. the past when you have tried to push bytes through them, you track the
  312. number of bytes and the average bandwidth, and use that to weight the
  313. priority of their connections if they try to push bytes through you.
  314. Now you're going to get minimum service if you don't ever push bytes
  315. for other people, and you get increasingly improved service the more
  316. active you are. We should have memories fade over time (we'll have
  317. to tune that, which could be quite hard).
  318. Pro: Sybil attacks are pointless because new identities get lowest
  319. priority.
  320. Pro: Smoothly handles periods of both low and high network load. Rather
  321. than keeping track of the ratio/difference between what he's done for
  322. you and what you've done for him, simply keep track of what he's done
  323. for you, and give him priority based on that.
  324. Based on 3.3 above, it seems we should reward all the nodes in our
  325. path, not just the first one -- otherwise the node can provide good
  326. service only to its guards. On the other hand, there might be a
  327. second-order effect where you want nodes to like you so that *when*
  328. your guards choose you for a circuit, they'll be able to get good
  329. performance. This tradeoff needs more simulation/analysis.
  330. This approach focuses on incenting people to relay traffic, but it
  331. doesn't do much for incenting them to allow exits. It may help in
  332. one way through: if there are few exits, then they will attract a
  333. lot of use, so lots of people will like them, so when they try to
  334. use the network they will find their first hop to be particularly
  335. pleasant. After that they're like the rest of the world though. (An
  336. alternative would be to reward exit nodes with higher values. At the
  337. extreme, we could even ask the directory servers to suggest the extra
  338. values, based on the current availability of exit nodes.)
  339. Pro: this is a pretty easy design to add; and it can be phased in
  340. incrementally simply by having new nodes behave differently.
  341. 4.4. Centralized opinions from the reputation servers.
  342. Have a set of official measurers who spot-check servers from the
  343. directory to see if they really do offer roughly the bandwidth
  344. they advertise. Include these observations in the directory. (For
  345. simplicity, the directory servers could be the measurers.) Then Tor
  346. servers give priority to other servers. We'd like to weight the
  347. priority by advertised bandwidth to encourage people to donate more,
  348. but it seems hard to distinguish between a slow server and a busy
  349. server.
  350. The spot-checking can be done anonymously to prevent selectively
  351. performing only for the measurers, because hey, we have an anonymity
  352. network.
  353. We could also reward exit nodes by giving them better priority, but
  354. like above this only will affect their first hop. Another problem
  355. is that it's darn hard to spot-check whether a server allows exits
  356. to all the pieces of the Internet that it claims to. If necessary,
  357. perhaps this can be solved by a distributed reporting mechanism,
  358. where clients that can reach a site from one exit but not another
  359. anonymously submit that site to the measurers, who verify.
  360. A last problem is that since directory servers will be doing their
  361. tests directly (easy to detect) or indirectly (through other Tor
  362. servers), then we know that we can get away with poor performance for
  363. people that aren't listed in the directory. Maybe we can turn this
  364. around and call it a feature though -- another reason to get listed
  365. in the directory.
  366. 5. Recommendations and next steps.
  367. 5.1. Simulation.
  368. For simulation trace, we can use two: one is what we obtained from Tor
  369. and one from existing web traces.
  370. We want to simulate all the four cases in 4.1-4. For 4.4, we may want
  371. to look at two variations: (1) the directory servers check the
  372. bandwidth themselves through Tor; (2) each node reports their perceived
  373. values on other nodes, while the directory servers use EigenTrust to
  374. compute global reputation and broadcast those.
  375. 5.2. Deploying into existing Tor network.