> The argument about RST spoofing seems somewhat contrived - if you have the means to inject arbitrary packets, chances are you also have the means to read them, so what sequence numbers are being used is known.
hwh addressed this, but to add more context, there are many places where you can inject spoofed packets with absolutely no visibility into the real data flow. If you're connected to an ISP that doesn't do BCP 38 filtering (for whatever reason), you can send packets to any destination from any source, but can only see packets destined for you (and possibly other people in your/nearby subnets). Even if you are subject to BCP 38 filtering, that may be at the network edge, so you can likely spoof packets from any source to a destination within your network.
So, if you have the capability to send a spoofed RST packet and any RST works, you just need to know the connection 4-tuple {Peer1IP, Peer2IP, Peer1Port, Peer2Port} in many common protocols, one of the peer's ip and port is well known, and you may be able to easily determine the other peer's IP and guess the port; 64k packets sent to disrupt someone's IRC connection isn't a lot. If you also have to guess the sequence number, it's a lot harder.
>> What would really suck is if an operating system were to totally ignore the rule to reply with an RST when receiving a packet on a closed socket.
> Isn't this behaviour explicitly encouraged to prevent port scanning and related attacks?
There's a difference between sending a response to a SYN packet, and sending a response to a packet that was sent on a previously established socket. The packet trace shown is really pathological -- because the client is only willing to send one RST, the server is likely to do a lot of retransmits and only figure out the connection is closed when retransmit timers expire; this is wasted effort and resources on the server side, but also for the client's network. At least the client should keep the socket in a FIN_WAIT state for some period of time to send RSTs, but it should also send RSTs when an otherwise unexpected packet comes in that appears to be from an established connection, that way it will stop getting data it can't process. It's reasonable to rate limit sending of RSTs, if you're concerned about DDoS via reflection, or other resource usage issues.