-----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. 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. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEmInNyua14OQlJ3sRAlppAJsGdrGxBsTJ0t/AIivioMlMGp9O2gCcCJ4W aSEbvRjLLisjy8Pn7vKy1jA= =8/xl -----END PGP SIGNATURE-----
