Slashdot Mirror
Understanding TCP Reset Attacks, Part I
Jeremy Andrews writes "A vulnerability in TCP, the transmission control protocol, recently received some exposure in the media. Paul Watson released a white paper titled Slipping In The window: TCP Reset Attacks at the 2004 CanSecWest conference, providing a much better understanding of the real-world risks of TCP reset attacks. The resulting articles in the major media painted a doom and gloom picture of the threat. To better understand the reality of this threat and how it affects all operating systems, KernelTrap spoke with Theo de Raadt, the creator of OpenBSD, an operating system which among other goals proactively focuses on security. In this article, we aim to provide some background into the workings of TCP, and then to build upon this foundation to understand how resets attacks work. This is the first article in a two part series. The second article will look into how TCP stacks can be hardened to defend against such attacks. Toward this goal, we spoke with members of the OpenBSD team to learn what they have done so far, and what further plans they have to minimize the impact of reset attacks."
IPv6 provides other means to prevent IP spoofing (a prerequisite for TCP reset attacks).
Um.....does IPv6 matter in this equation? TCP will just sit on top of IPv6 anyway.
Doesn't matter at all. For a reset attack, you need to match source IP address (known), destination IP address (known), source port (unknown, but guessable), destination port (known), and TCP sequence number (unknown, but guessable). All the unknowns are in the TCP layer.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
It seems the attacks rely on being able to guess the right window, but say the connection is currently actively transmitting and receiving, then part of the window will always be full, and thus while the attack might hit the window, it will not work as expected since the receiver already have a packet at that sport.
It mostly seem to be a problem for silly application protocols that expects to keep idle TCP-connections up all the time.
Long-term TCP connections on the public internet that have a high cost to re-establish can use ipSec to avoid this problem.
Random source port allocation from a large pool, combined with smaller window sizes should be sufficient for the rest. Why do you need more than a 1K window width? Because packet sizes are too small. TCP is from '91, so 1K packets were considered "big", transmission speeds were slow, and the network was presumed to be fairly unreliable. Now with higher speed and huge memory, a packet size of 64K would reduce overhead as well as the need for large packet windows.