Follow Slashdot stories on Twitter


Forgot your password?
Security The Internet

Understanding TCP Reset Attacks, Part I 10

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."
This discussion has been archived. No new comments can be posted.

Understanding TCP Reset Attacks, Part I

Comments Filter:
  • All this trouble stems from two orthogonal problems.

    • The window width, useful to accept datas
    • The possibility to spoof source IP address and send RST packet.

    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 spo

    • "inappropriate source address"
      • Well, it deserves an explication.

        Let's imagine an ISP providing the range

        It has some routers providng connection to the rest of Internet. The filtering should take place on these routers for packets going from subnetwork to internet.
        If this packet has source, it's probably a legit packet and the router must transfer it.
        If this packet has source -inappropriate- it's a bad packet and must drop it.

        OSrry I didn't make it clear on first time
  • In window (Score:3, Interesting)

    by Carewolf ( 581105 ) on Wednesday May 12, 2004 @09:33AM (#9125853) Homepage
    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.
  • ipSec (Score:3, Interesting)

    by Smallpond ( 221300 ) on Wednesday May 12, 2004 @09:37AM (#9125890) Homepage Journal
    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.

"We don't care. We don't have to. We're the Phone Company."