On Sun, Nov 02, 2003 at 02:35:57AM -0600, Tom Kaitchuck wrote: > Cancer nodes currently pose a serious threat to the network. However stopping > them is not simple, especially an anti-specialization attack, as discussed > previously. My previously proposed solution would not work, because someone > could find a hash that works and then start subtracting values until they > find XXX. Toad pointed this out as a problem with SSKs, but it is a problem > with CHKs too.
No it isn't, because XXX depends on the hash of the content on a CHK. I'll look at the rest of your suggestions later... > > I have a better solution. > Take the index key that things are located under now. Split it into two parts. > Hash each part. Then start incrementing one part and hashing it each time > until the last few digits are the same as the hash of the second part. Then > data is routed biased on the hash of the resulting two hashes. This is > basically the same as my previous proposal, except that by hashing the key > after it is split, someone cannot work backwards. > > However this can never be a total solution because it just increases the > amount of work before the attack can start, it does not increase the amount > of work to actually execute it. > > As toad correctly pointed out disconnecting from cancer nodes is not a total > solution. This is because any mechanism that relies on negative trust can be > circomvented, by simply contacting lots of nodes. Also one cannot introduse a > means for nodes to share some sort of list of nodes that they don't trust, > because it relies upon trusting those nodes in the first place, and if you > could trust them, you wouldn't need the list. > > So, what Freenet needs in order to fully thwart cancer node attacks is a > decentralized positive trust biased model. One existing model for how to do > this in GNUnet. It implies a very smart trust biased network, and can place > hard limits on the amount of damage that can be done by an attacker. This > could make both flooding attacks and anti-specialization attacks on freenet > impossible. > > Consider the following: > Suppose we have a system where each node has a particular level of trust in > each other node in it's table. Then each time a node makes a request it risks > a level of trust that is specifies. If the first node successfully returns > the data it may dock it UP TO that amount from it's trust. Then the other > node gives the first one the amount of trust that it specified. Then each > node always tries to selfishly gain as much trust as possible. This way the > requests of the highest priority go through, and inflation is prevented as > there is a finite amount of resources, thus insuring that node is able to > take away more from the network than it put it minus the slack in the > network. (Even requests that gain zero trust will go through if the > bandwidth/CPU useage for that time would otherwise go to waste) > > The way GNUnet does would not work with Freenet. This is that each hop the > request goes towards the destination each node must decrease the trust it is > risking on this transaction by a small amount so that it can be sure it > actually gains something. If all the nodes are doing this and the network is > MORE likely to drop requests as they get closer and closer to their > destination. Also it is possible for a node to get shortchanged if one nodes > trust (because of it's position on the network) is not as valuable to it as > the next's. The solution to this is nontrivial. First each node would need to > compute the relative value of each nodes trust. The logical way to do this > would be to just add trust right in with the NGrouting time estimators, and > consider value as the total overall decrease in routing time from requests > comming from your node if you gain that amount of trust. Then rather then > evaluating incoming requests just biased on the amount of trust we would gain > if we compleated them, we also need to take into account the relative > probability of the request actually succeeding. > > Then once this is in place it is easy to stop flooding attacks. Currently if > an attacker was inserting||requesting large ammounts of data to waste network > bandwidth, they can deprive others of HTL*TheirBandwidth, under this system > they would not be able to do any more damage than having one other computer > receive all of those requests (TheirBandwidth). This could also be used to > prevent anti-specialization attacks, because it is possible to dock the > requesting node the FULL trust level they put in the request at if it is not > in the network. So then, unless they have built up a huge amount of trust, > then the probability of their packets being dropped approaches 1. In order to > build up enough trust to outweigh the normal traffic, then, on average they > will have to have processed htl*fakeRequests successful requests previously. > Even then under load the amount of trust to get their requests through is > higher, and if their attack becomes successful, then the probability of > success goes down, and they are even more likely to be dropped. The counter > argument to this is that any node can process N requests successfully and > then turn around and send out N/htl requests to another node (For whatever > reason). However I would say that this is not too serious as it's overall > contribution to the network is still greater. > > Also to successfully prevent a distributed flooding anti-specialization attack > the failure table needs to be as large as possible. Ideally the failure table > should only be time dependent. However because there is always a limit to > resources. However if the limit only comes into play when the network is > under attack, then it would be better if entries were removed randomly rather > than in order. In order to make this possible TUKs are necessary, otherwise a > large failure table could be a problem for some applications. > > It should be noted that in order to make TUKs work universally they would need > to be implemented differently then discussed in the docs. Here is my current > concept of how they could work: > > First TUKs would take over a role that is normally reserved for the manifest. > When a TUK is requested, if a node has it, it checks the expiration date, and > if it has passed it passes the request up stream anyway to check if there is > a newer version available. Then all the nodes in the chain have the latest > version. The TUK itself is not encrypted and can be modified by the node that > is holding it. However it is signed with the key that it is inserted under, > so any modifications must be sanctioned by the original creator. If the > original creator sends an update it will replace the contents of the TUK, but > will not be accepted if they attempt to increment the version number by more > than one, set the expiration time in the past, or alter static content. The > node that has the TUK stored on it is en charge of enforcing this. So it is > still possible that the creator could try to make their content less > acessable by creating a new TUK that has a very high version number and > keeping it in their data store, and then hoping that they will fall in the > request line for the data. Then they would effectively hijack their own > content in the same way that KSKs can be hijacked now. (Although others would > not be able to hijack it) I don't see any way around this. However if some > other sights simply kept track of the version number the old content would > still retrievable. The data in the key itself could contain simply a link to > the current version, or it could have a version for each of several different > files. (assuming of course that those can fit in an SSK) It could also have > static content, or data that is listed there under a CHK and does not ever > change. Finally it could contain other public keys that are allowed to update > the other parts of the TUK. They should not be able to remove other keys or > add their own, but they should be able to increment version numbers. This > would enable Frost boards to have a maintainer who can allow many people to > post messages and everyone to read them, but also revoke write privileges of > those that abuse them. Additionally it would allow more sophisticated systems > for SSK sites where many people can contribute, while not giving any of them > total access. It should be noted that this (at least from my perspective) is > secondary. The real purpose of TUKs regardless of how they work should be to > eliminate the need to have nodes guess keys, and ultimately reduce network > traffic, as the vast majority of it is used by applications like Frost that > need to make a lot of otherwise unnecessary queries. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
