On Thursday 23 March 2006 12:58, Rick Jones wrote: > > For a sender, defense is more difficult because you can't throw away > > unacknowledged data. An attacker can consume 2*mss kernel memory per ack > > it > > WIth ABC in place, isn't that "up to" or "no more than?" And that is > only if the connection is still in the slow-start phase rather than > bandwidth probing.
Yes. I'm using worst case here as an example, because I'm trying to illustrate that even this worst case is not as bad as just opening a new connection. > Would having a lower initial cap on ssthrsh than "whatever the remote > advertises" - say at the present default wmax - be some middle ground? > It might not be completely optimal for those high bandwidth delay > product links but it would mean that once a connection got to current > wmax it would be in the MSS per window realm rather than the other. This would be a real performance killer, and I don't think it buys you much, as the window-inflating attack isn't the primary concern. > > sends, and hold on to it indefinitely. > > Is it really indefinite? I would think that it would be no longer than > it takes the sender to hit his retransmission limits? No, it's not really indefinite, unless the attacker sends out an ack every few minutes (which requires extra state). It's easier and a more effective attack to create new connections if you can. > Doesn't the sending "attack" presume that there is a willing accomplice > on the system - something that both has and is willing to send that > large quantity of data to the remote? Yes, for the window inflating attack. For the simple attack of creating lots of connections, a simple web server with some small (16k) objects to fetch is adequate. -John - 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
