I am most familiar with are in Checkpoint Firewall. They include several features that would limit this through session verification that tracks every packet, the sequence numbers associated (uses prediction), TCP flag states, etc.
When the attacker submitted sequence numbers that were not correct for the connection, it would send a TCP reset to both the client and the server; forcing the attacker to begin the attack sequence again with the first SYN. If it recognized a replay (sequence numbers used twice) like would happen here too, it would also reset the session. There are others as well such as packet data enforcement (if the packet data portions did not match up to a valid session) and session proxying too.
Lastly, it would lock out that attacker as a DDOS based on the traffic patterns (TCP sliding windows have been exceeded, or too much data in one direction and nothing returned).
The idea during design was that there are insecurities the TCP protocol inherently permits (like this one), how can we limit those. The answer basically is that if a session displays 'errant but technically permitted by RFC' behaviors, the firewall should force a reset on the connection.
If your conclusion at this point is can't this block valid traffic, the answer is yes it can, and these features are often turned off or limited for that reason.
Be aware that I have not pieced this together completely - it would take more detailed research and time to provide valid evidence - this is just off the top of my head over few minutes.
When the attacker submitted sequence numbers that were not correct for the connection, it would send a TCP reset to both the client and the server; forcing the attacker to begin the attack sequence again with the first SYN. If it recognized a replay (sequence numbers used twice) like would happen here too, it would also reset the session. There are others as well such as packet data enforcement (if the packet data portions did not match up to a valid session) and session proxying too.
Lastly, it would lock out that attacker as a DDOS based on the traffic patterns (TCP sliding windows have been exceeded, or too much data in one direction and nothing returned).
The idea during design was that there are insecurities the TCP protocol inherently permits (like this one), how can we limit those. The answer basically is that if a session displays 'errant but technically permitted by RFC' behaviors, the firewall should force a reset on the connection.
If your conclusion at this point is can't this block valid traffic, the answer is yes it can, and these features are often turned off or limited for that reason.
Be aware that I have not pieced this together completely - it would take more detailed research and time to provide valid evidence - this is just off the top of my head over few minutes.
HTH...