Not a well-known attack
I looked into this question myself in 2015. Nobody talked about this back then, and looking for it again recently, it's still not a well known risk. You are right: with a standard gigabit connection (which was already quite standard in 2015) you can work through the couple of terabytes needed in a matter of minutes. Or, on 100mbps, in a few hours.
The problem is that you can't do any sort of handshake. You can't spoof a TLS session, even if the server uses a self-signed certificate and a super tiny public key. Pretty much any unknown byte multiplies the amount of data you need to send. If you need to guess a single digit, the attack will need (on average) five times more data. If you need to guess more than a few digits (let alone a few bytes), it still becomes prohibitively expensive. So if you steal credentials but notice that there is an IP whitelist, you can't login a session with a spoofed TCP connection, because you'll never learn the value of the session cookie (and session cookies are designed to be impossible to guess).
Routers may additionally protect against traffic coming in on the wrong interface. If a system has an internal management interface and a public interface, you can't just send a packet to the public interface originating from the internal IP range, because "by default the Linux kernel checks to see the path a hypothetical return packet would take. If the return packet is over another interface it silently dropped. This mechanism is controlled by the rp_filter kernel parameter." (source) If you run
ip route get 172.16.0.1 from 172.16.0.2 dev eno1 (where
eno1 is the public interface and
172.16.0.0/24 is your internal range), you'll see that it returns an error about a cross-device link.
Finally, you may encounter trouble spoofing IP addresses outside of your ISP's network range at all, as more and more ISPs start filtering bad source IPs from their traffic (ingress filtering / BCP38). Especially the private ranges like
127.x, etc. will be very hard to route across the Internet.
Proof of concept
It is relatively easy to make your own proof of concept. Something like Scapy is not fast enough, but if you take the ready-made packets (for example from a Wireshark capture), modify them to include a variable seq/ack number, and write a few lines of socket code, you can easily test this attack on your LAN. I did so and originally described the results in this blog post: https://lgms.nl/blog-2
There is code and a pcap available, so you can look at the results and toy around with the proof of concept yourself.
It is not a huge risk. IP address-based whitelisting has fallen out a bit of style in favor of username/password or public key authentication. Circumventing IP address-based blacklists or bans with this method is a bit pointless: you'll have the aforementioned limitations and you need to transmit terabytes of data before you can do a single request. It is typically much easier to find yourself another IP address.
Nevertheless, there are totally cases where this attack circumvents hardening or, in very rare cases, circumvents security altogether. I nearly never come across it in my work as a pentester, but that might be because I mainly see networks where someone cares to keep it secure (they care enough to pay my employer's rates for an expert analysis).
There are three possible solutions:
Stop relying on IP addresses for security in the first place.
People seem to be doing this already, but rather because it is harder to manage than because they know of this security risk.
Update the TCP protocol or create a new protocol like TCPv2.
People are having trouble introducing new protocols and speak of the ossification of the Internet. If we can hardly introduce anything alongside TCP and UDP, I doubt we can change TCP itself with broad consensus. (I think "TCPv6" would paint an accurate picture.)
Add a layer on top of TCP that has additional random numbers.
Encryption is popular and very effective at this. We could add TLS to everything. Even if the encryption turns out to be poor, it would prevent the attack because you almost certainly need to use some random bytes, which you can't do off-path (at least, not while also trying to guess the acknowledgement number).