The Host Requirements RFC  states that a TCP MUST act on an ICMP
error message passed up from the IP layer, directing it to the
connection that created the error.
In order to allow ICMP messages to be demultiplexed by the receiving
host, part of the original packet that elicited the message is
included in the payload of the ICMP error message. Thus, the
receiving host can use that information to match the ICMP error to
the instance of the transport protocol that elicited it.
Neither the Host Requirements RFC  nor the original TCP
specification  recommend any security checks on the received ICMP
messages. Thus, as long as the ICMP payload contains the correct
four-tuple that identifies the communication instance, it will be
processed by the corresponding transport-protocol instance, and the
corresponding action will be performed.
Therefore, an attacker could send a forged ICMP message to the
attacked host, and, as long as he is able to guess the four-tuple
that identifies the communication instance to be attacked, he can use
ICMP to perform a variety of attacks.
I was unaware that TCP services paid any real attention to ICMP messages, since TCP has its own mechanisms for handling errors (unlike UDP).
Vendors like Cisco have published bulletins addressing this problem. Fernando Gont brought this issue to the attention of the UK-based National Infrastructure Security Co-ordination Centre. This is the same organization that worked with Paul Watson on last year's TCP reset vulnerabilities.