For most victims, what the attacker really wants is a packet that looks like one sent by a true client of the victim: an initial SYN packet, a packet containing data, an acknowledgment, or a FIN. (An additional type, RST, is discussed shortly.)
However, we first note that any packet from a reflector will have a source port corresponding to the port on which the reflector runs. In particular, for Web servers (the most widely available TCP reflector), this will usually be port 80. Accordingly, the victim can filter out any incoming traffic with a source port of 80 (say), and eliminate any threat from TCP-based reflectors. Naturally, this prevents the victim from access to the same service remotely, which may be a significant difficulty; but perhaps an acceptable one during a time of flooding.
Putting that limitation aside, inspecting the TCP state diagram in [Po81c] shows that there is no way to trigger a reflector into sending an initial SYN packet unless it has an application-level means to do so (e.g., FTP ``bounce'' attack [Ce97]). Furthermore, since the reflector will not have an existing connection open to the victim, the only packets it can send in response to receiving a packet purportedly from the victim are either a RST or a SYN ACK (though see below). If the victim filters out RST packets, this will over time cause its servers to hold more state than they need to, eventually clogging them with stale connections. (However, depending on the service, these connections may be amenable to manual garbage collecting.) If the victim filters out SYN ACKs, then they lose access to remote services (if there isn't more specific port filtering they can employ, per the above); this may or may not be acceptable, depending on the specifics of the victim's operation.
There is, however, another possibility. If the reflector's stack has guessable TCP sequence numbers [Be96], then the attacker can potentially drive the stack through the entire TCP state machine, tricking it into sending data segments, acknowledgments, etc. This is a disaster for the victim. But it is so even without delving into DDOS including slaves and the like--a recently discovered attack exploits such stacks to realize major amplification by duping Web servers into transmitting large items to the victim, and exploiting ``ACK splitting'' techniques [SCWA99] to greatly enhance the sending rate [Gu01]. Other applications such as FTP or streaming media servers could likewise be exploited. If done as part of a reflector attack, then the attacker gains both the benefits of amplification and a highly diffuse flood at the victim, a lethal combination.
Another way an attacker can trick a remote server into sending data packets towards the victim is by forging a T/TCP connection request [Br94] from the victim. T/TCP was designed to resist inadvertent confusion of old network segments with new ones, via the CC/CCECHO mechanism, but the only requirement placed upon the sequence numbers used by the mechanism is simply that they be monotone-increasing. Consequently, it is simple to pick a sequence number in the initial, spoofed T/TCP SYN packet such that the server's stack will find it acceptable. If the SYN packet also contains an expensive request like ``GET hugeimage.jpg'', then the server will begin transmitting the data to the victim immediately.
Three factors limit the severity of the T/TCP attack. First, the T/TCP server will begin in slow start (the specification suggests an initial sending window of 4 KB [Br94], but this is for the client initiating the connection, not the server replying to it). Unless the server's stack has guessable sequence numbers as discussed above, the attacker can't exploit ACK-splitting techniques to move the server out of slow start.
Second, the packets sent from the server to the victim will have CCECHO options in their TCP headers, which makes them amenable to stateless packet filtering, though the filter is potentially somewhat complicated, because due to the use of other TCP options, the location of the CCECHO option in the header will not always be the same. (In addition, such filtering will prevent the victim from accessing external servers using T/TCP; not a significant limitation, however, as they can disable their own use of T/TCP and then the external servers will not use it in reply.)
Third, T/TCP is not widely deployed, so it will be difficult for an attacker to find a large number of T/TCP reflectors. Furthermore, if such reflectors were used in a high-profile DDOS attack, likely many servers would soon be configured to no longer use T/TCP.
Summary: if a site can endure loss of contact to external servers, and can tolerate failing to tear down legitimate connections that the remote peer has reset, then filtering of SYN ACKs and RSTs will protect against the main form of general TCP-based reflector attacks. One exception is if the attacker can find large numbers of remote servers with guessable initial sequence numbers; in addition, due to the amplification of this form of reflection, such servers constitute a potential DDOS threat by themselves, without the attacker even having to coordinate a collection of slaves.