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."
Its truly a pity noone uses NCP anymore. Hell even IPX/SPX was superior to TCP. But of course my favorite is broadcasting encrypted packets via UDP. Don't have to worry about resets there!
No seriously, TCP is showing its age (not the rfc, just the implementations). Hopefully this will spurn people onto adopting IPv6.
All this trouble stems from two orthogonal problems.
One possibility would be to accept the RST packet with the very right sequence number (beginning of window) and thus making its probability fall back to 2^32 to 1. I guess it would need some serious reimplementation of TCP stack on all systems.
Another possibilty would be for ISPs to drop packet with inappropriate source address, to prevent spoofing. It might work if all ISP do this job and no rogue party has a direct internet connection.
All of the above would be steps in the right direction
My center is giving way, my right is in retreat; situation excellent. I shall attack.
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.