Another problem with very large window sizes is that it becomes more easy for an attacker to guess valid sequence numbers.
With window scaling, the maximum shift is 14 (as per RFC 1323), so the window might become as large as 65535*2^14=1GB. Sequence numbers are 32-bit unsigned integers, so if both peers would actually advertise 1GB windows (1/4th of the sequence number space), an attacker would have a 1 to 16 chance to pass the sequence number tracker by using random values for seq and ack. He could send RSTs until he gets the firewall to close the state entry, tearing down your connection (assuming he already knows the addresses and ports used). Also, if one peer advertises a 1GB window, the other is invited to send 1GB of data before waiting for an ack. Assuming an MTU of 1500 bytes, that's more than 700000 packets. If just one of them gets lost, the entire bunch of them would have to be retransmitted (unless you also support SACK). So, on the networks I know, such large windows would never be reached, and a wscale 14 would be less than helpful. :) Maybe someone with experience in fast networks can comment on how average packet loss and latency affect the maximum TCP window you might want to use. With an MTU of 1500 or lower, over the Internet, do your windows actually go beyond 65535 bytes, even if you enable scaling? Daniel
