TCP, when using a large window size, makes it easier for remote attackers to guess sequence numbers and cause a denial of service (connection loss) to persistent TCP connections by repeatedly injecting a TCP RST packet, especially in protocols that use long-lived connections, such as BGP.
Sources:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0230
http://www.rfc-base.org/txt/rfc-5961.txt
For the attack to succeed, the RST needs to be in the valid receive window. The attacker would try to forge many RST segments to try to cover the space of possible windows by putting out a packet in each potential window. To do this, the attacker must have or guess several pieces of information:
- 4-tuple (IP address and TCP port for both sides of the connection).
- Sequence number that will be used in the RST.
- Window size that the two endpoints are using. This value does not have to be the exact window size since a smaller value used in lieu of the correct one will just cause the attacker to generate more segments before succeeding in this mischief. Frequently the attacker, with a fair degree of certainty (knowing the application that is under attack), can come up with a very close approximation as to the actual window size in use on the connection.
- The receive window is the number of bytes a sender can transmit without receiving an acknowledgment.
After assembling the above information, the attacker begins sending spoofed TCP segments with the RST bit set and a guessed TCP sequence number. Each time a new RST segment is sent, the sequence number guess is incremented by the window size.
Every application has control of a number of factors that drastically affect the probability of a successful spoofing attack. These factors include:
- Window size
- Server port number
- Client port number
In other words, the mean number of tries to inject an RST segment is (2^31/window) rather than the 2^31 (2^31 = 2147483648 / 32,768 =65536 ). The bigger the window, the fewer guesses it will take.
Substituting numbers into this formula, we see that for a window size of 32,768, an average of 65,536 packets need to be transmitted in order to 'spoof' a TCP segment that's acceptable to a TCP receiver. A window size of 65,535 reduces this even further to 32,768 packets. At today's access bandwidths, an attack of that size is feasible.
With rises in bandwidth to both home and office, it can only be expected that the values for default window sizes will continue to rise to better take advantage of the newly available bandwidth.
A TCP connection that lasts only a few brief packets, as often is the case for web traffic, would not be subject to such an attack since the connection may not be established long enough for an attacker to generate enough traffic. However, a some applications, such as BGP, are judged to be potentially most affected by this vulnerability. BGP relies on a persistent TCP session between BGP peers. Resetting the connection can result in some unavailability due to the need to rebuild routing tables and route flapping. For applications that can use the TCP MD5 option, such as BGP, that option makes the attacks described in this specification effectively impossible.
RFC 5961 threat mitigation was implemented in PAN-OS 6.0.0