TCP reset attack, number of Reset Packets

Question

I'm reading up on the TCP reset attack, and my understand is that for a third party to interfere with a communication they have to send a reset packet to terminate the communication between the two parties involved. and for the reset packet to be accepted, it's sequence number has to be in the receiver's window.

But since TCP sequence numbers are so large and there are many possibilities for RCV.next and RCV.wnd, how is it possible for an attacker to generate a reset packet to terminate the connection? Is it just a brute-force type attack where they have to generate as many RST packets as possible? Is there a minimum number of packets that could work? I Feel like this might be a little time-consuming and difficult.

Answer 1

What are the capabilities of your attacker? Usually TCP resets are performed by someone with visibility of the network. For example, Comcast got sued (and lost) for killing BitTorrent communications with TCP resets, but since they were inspecting the packets, they knew the sequence numbers to use.

Also, realize that 32 bits is only 4 billion-ish possibilities, and you can divide that by the size of the window you estimate. You can also expect to have to try only half of those on average before hitting the right one. Any TCP implementations whose sequence numbers start at 0 are easy to brute force, and it's only a few GB of traffic to kill even a connection with randomly initialized sequence numbers.