On Thu, 4 Jan 2007, William A. Rowe, Jr. wrote:
> On the matter of your 1GB window (which is, again, the real issue), you have
> any examples of a kernel that permits that large a sliding window buffer by
> default
No, I simply mentioned the hypothetical maximum; common configurations for
high-performance applications call for configs from several megs upward,
and this is increasing with the bandwidth available to consumers.
William, again, this is not a critical issue; I did mention that, and if
it were, I wouldn't report it that way. There were two distinct problems
mentioned, and I probably shouldn't mix them the way I did:
1) A single HTTP request can be used to return 5000x the largest file on
a server regardless of web admin's intent. This is not a common
knowledge, and yes, it is worth reporting, because it can be used to
make a DoS or zombie-based DDoS attacks more painful than usual,
by considerably improving the ratio of bandwidth required to initiate
an attack to the traffic generated at victim's expense (compared to
known attacks using simultaneous HTTP connections, keep-alives, etc).
2) Theoretical window size limits and commonly implemented settings do
have a side effect of making such attacks more feasible for
attackers with a very limited bandwidth available. There's probably
not that much difference between a 10 MB and a 1 GB window size,
anyway: the attacker can establish a dial-up connection to ISP A,
initiate a series of 5000x requests with 10 MB window size, then
reconnect to ISP B, and continue to slowly and calmly spoof ACKs
as coming from his previous IP to the attacked server (he knows
all the sequence numbers). It would take 40 bytes to generate next
10 MB of traffic within an established connection, so it still
sounds like fun for a guy who has a 4 kB/s link. And that's why I
asked whether there was any research done on such issues.
/mz
