On Tue, 11 Jul 2006 02:23:52 +0100, Matthew Toseland wrote: > 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.
Make establishing connections harder. For example, require that a node making a connection solves some CPU-intensive problem. This effectively prevents a node from constantly creating new identities. Google for hash cash for a better explanation. Obviously, nodes that have been added by hand don't require this. > 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?
