Apart from the preference issue, the other obvious question with opennet and the new load limiting algorithm is flooding attacks. This is not entirely a matter of the new load limiting algorithm; there are issues with any load limiting algorithm and opennet.
In the new load limiting algorithm, nodes may not send a request unless they have a token from the node which they want to send the request to. Tokens are effectively propagated; a new token is created when a request completes. The result is that load is effectively managed, hopefully. Of course we must create some tokens in the first place: When a new node is added, we allocate it a certain number of new tokens. A malicious node which wants to maximize its performance, as opposed to one which wants to actively attack the network, would probably do something like the following: Log every node it ever hears about, and attempt to connect to each node. Reject all requests from all connected nodes. (To conserve valuable upstream bandwidth! Remember most domestic connections are asymmetric). Exploit the newbie node's marginal trust by using all the initially allocated tokens to send requests. Constantly shift identities, in order to connect to nodes more than once. Constantly make announcement requests, either sending packets to known seednodes, or pretending to relay announcement requests from one of its alternate identities. Several issues here: * A node can get more than its fair share by refusing to serve requests for nodes it is connected to; pretending that it is a slow node. The solution is simply to take it at its word: if it is a slow node, don't accept many requests from it, don't give it many tokens. * A node can get more than its fair share by just keeping connecting to more and more nodes. On a large network there is little that we can do about this, as far as I can see. A node will be able to connect to other nodes via path folding, or via announcements. In both cases the success rate is low; most of the time mostnodes do not require any more connections. We can limit the number of announcements from a single node identity, but see the next bit. * A node can get more than its fair share by pretending to be multiple nodes. It is perfectly legal to have multiple nodes on the same IP. In fact if we are dealing with large ISP NATs, then it is likely, and legitimate, to have a large number of nodes on the same IP address and different port numbers. Thus there is very little we can do about Sybil attacks - attacks involving a node pretending to be many nodes - even if the node is limited to a single IP address. Short of hashcash on node identities or other user-hostile measures. So, what can be done? - Reasonably strict tit-for-tat. If a node is not idle, then it should only accept requests from nodes which are responding to its requests. Of course we will need to allow a newbie node a small number of requests initially. But if it is not able to serve some of our requests, we should not serve its, after the first few. Obviously there are many difficulties with tit-for-tat; for example, one request in does not necessarily correspond to one request out, they will often fork. Another issue is is a DNF success? - Anything else? -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060711/f0bf83c4/attachment.pgp>
