On Wed, Jun 21, 2006 at 12:50:37AM +0100, Michael Rogers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dave Baker wrote: > > Is it right that due to A's misbehavior, the connection between B and C is > > treated as overloaded? Likewise, if A sends a request to B, who forwards it > > to C, but it times out between B and C, the connection between B and C will > > be considered overloaded (right?) But will the perfectly healthy connection > > between A and B also be affected? > > I agree - throttling every link along the path of a rejected request is > potentially harmful. It reduces the bandwidth available to innocent > nodes, which could trigger a vicious cycle of rejected requests and > throttling that could spread across the whole network. > > We're caught in a cleft stick here: no node knows whether its > predecessor is the source, so no node can throttle its predecessor > without the risk of affecting innocent nodes. On the other hand, if we > just propagate a "please slow down" message back to the source, a > misbehaving source won't be affected.
But this is not acceptable for security reasons: Under no circumstances is it acceptable on Freenet for the source to behave observably differently to other nodes on the path! HOWEVER there are other ways outlined in recent emails on token passing schemes. > > I also think we need to distinguish between attackers that generate a > large amount of traffic uniformly distributed across the keyspace, and > attackers that generate a large amount of traffic focussed on a small > region of the keyspace. The latter will overload the slowest link or > node between themselves and the target and will thereafter get a high > proportion of their requests rejected, but the former will not get a > higher proportion of rejections than other nodes. They'll make more > requests, and get more rejections, but there's no reason for them to get > a higher proportion of rejections. If we use rejections to trigger > throttling, I don't think we'll contain this type of attack. They can get a higher proportion of rejections, if they are flooding (relative to everyone else). That's the reasoning behind the "add the token to the fullest non-full token bucket" idea. > > Cheers, > Michael -- 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/devl/attachments/20060621/76a0d364/attachment.pgp>
