In a TCP session, the endpoints can negotiate a TCP Window size. When this is taken into account, instead of attempting to send a spoofed packet with all potential sequence numbers, the attacker would only need to calculate a valid sequence number that falls within the next expected ISN plus or minus half the window size. Therefore, the larger the TCP Window size, the the larger the range of sequence numbers that will be accepted in the TCP stream. According to Paul Watson's report, with a typical xDSL data connection (80 Kbps, upstream) capable of sending of 250 packets per second (pps) to a session with a TCP Window size of 65,535 bytes, it would be possible to inject a TCP packet approximately every 5 minutes. It would take approximately 15 seconds with a T-1 (1.544 Mbps) connection. These numbers are significant when large numbers of compromised machines (often called "botnets" or "zombies") can be used to generate large amounts of packets that can be directed at a particular host.
To protect against such injections, RFC 2385 provides a method of using MD5 signatures on the TCP Headers. If this form of verification is supported and enabled between two peers, then an attacker would have to obtain the key used to transmit the packet in order to successfully inject a packet into the TCP session. Another alternative would be to tunnel BGP over IPSec. Again, this would provide a form of authentication between the BGP peers and the data that they transmit. The lack of authentication when using TCP for BGP makes this type of attack more viable.