Hi, [ moving this to netdev as requested ]
On Tue, 09 Jan 2007, Stephen Hemminger wrote: > Actually, this paper seems to be a zombified version of: > http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf Thanks. In fairness to them, the emphasis is slightly different, Savage et al are more interested in improving a receiver's performance, whereas Sherwood seems more interested in a DoS attack. However... > It is not clear that current Linux systems are prone to the attack for a > couple of reasons. First, Linux does more counts packets not bytes so > extra ack's would be ignored. Turning on ABC would also help. The issue I'm raising is not as much how you could artifically increase Cwnd by dividing ACKs or sending them early. The issue as I see it is that if the receiver doesn't send dup acks, the sender never backs off and may eventually flood its own link. As the receiver need only ACK the odd packet, the amplification can be substantial. As this issue is already moreorless solved (in the research sense), I'm not keen to spend a lot of time writing it up. So, here's a quick throw together of a small example experiment I ran yesterday. http://www.hamilton.ie/gavinmc/drop_dupack_attack/ > Lastly, the patch looks like it could cause more problems. It probably would > break some application and other non-attacking TCP stacks. For this case, IMHO > we need to wait for more research. If you want to pursue the problem, it needs > to go through the RFC process. I must admit I didn't read the patch in detail. As I understand it, the fix should (in principal) be compatible with other TCP stacks who should just see an odd extra dropped packet and react with a duplicate ack as usual. Gavin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
