I have been following this list for quite some time and have never heard this vulnerability mentioned.
If a server responded (either legitimately or not) to all requests and sent the reply data out reeeaaalllyy ssslllllooooowwwlllyyy, like 1 byte/sec, wouldn't that seriously damage freenet's usefulness? If an evil node that did this dedicated enough ports to doing this, it could cause many, many other nodes to just sit there and wait for the sluggish transfer to complete. Splitting data into multiple parts would make this even worse since there is a better chance that the evil node with be contacted for a part of the request. The consequences: - enough requests would be bogged down to annoy a lot of people into not using freenet - lots of nodes will use up their connection limit - all nodes along a request chain will be affected The solution: If a supplying node is taking too long to transfer data, have the node randomly select another node to try to get the data from and when it finds a better one then it drops the slow-poke. A "minimum acceptable transfer rate" in the config would allow for this rate to be adjusted up as high bandwidth becomes more wide spread. This has the added benefit of biasing the whole freenet towards faster nodes and culling the traffic to slow ones (either maliciously slow or just overloaded) Mike _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
