The first fields in the header are the version and the header length (presence of options). Clearly, the version field provides no traction, as the packet won't even make it to the victim unless it corresponds to a version of IP that the victim cares about, and the field is too narrow to likely provide useful filtering. (We confine our subsequent treatment of IP and ICMP to IPv4.) The presence of options similarly does not provide any traction: options are almost never used due to their performance impact, so they won't show up in either legitimate or reflector traffic; even if the attacker can induce their presence, the victim will almost certainly be able to filter out the traffic without impairing themselves.
The type of service field in some scenarios could in the future be quite helpful. If traffic to the victim normally arrives with a particular Diffserv Code Point (DSCP) [NBBB98], then likely a static filter allowing only such traffic would help screen out reflector traffic, though at a cost of screening out legitimate auxiliary traffic to the victim, too. This latter could be quite expensive, if it includes things like replies to the victim's DNS queries, or the victim's outbound Web surfing. (Whether the attacker can manipulate a reflector into having a particular DSCP attached to its traffic will depend on the classifiers that wind up being deployed at different points in the network. If Diffserv traffic in general is premium traffic, then it appears plausible that often the attacker will not be able to force the marking, because to do so they will have to dupe a classifier upon which billing for the premium traffic relies. Presumably this will be difficult to do, given the financial motivations to secure use of the premium traffic.)
It is hard to see what filtering benefit can be had from the length field, since few forms of reflectors will be limited to sending only particular-length replies, and, even if they did, filtering them out would also filter out legitimate traffic. However, if the traffic to a victim tends to come only in particular sizes, such as small DNS requests, then the victim can possibly filter out any reflector traffic that does not come in that size.
The IP ID field is very difficult for the attacker to manipulate, and carries only a smidgen of useful semantic information. Thus, it is very hard to see how it could be usefully filtered on.
It is likewise difficult to see how the attacker can take much advantage of fragments. It will only be possible to generate them for reflectors that send large replies using TCP/IP stacks that do not implement PMTU discovery [Mo90], or for reflectors that have paths to the victim that transit GRE tunnels [F+00]. Fragments offer the benefit to the attacker of making it difficult for the victim to filter on TCP or UDP header information, since it will only be present in the initial fragments. (Also, that header might itself be split across multiple fragments; some stacks have been observed to do this as part of their normal operation [Pa99].) But due to the limited use of fragments in the Internet, the victim could likely filter out all fragmented traffic and suffer little degraded service, other than for some implementations of protocols like NFS and AFS that frequently send high volumes of fragmented traffic, or for sites that rely on GRE tunnels.
The TTL field is easier for the attacker to manipulate (by choosing the distance from the reflector to the victim, and choosing reflectors according to their particular stacks, and hence their particular initial TTLs). But it is hard to see how the TTL can be used for any useful filtering, unless the only legitimate communication the victim partakes in comes from a small set of remote sites that can be characterized with a narrow TTL range.
The protocol field will determine the next layer of filtering, as discussed below for particular protocols. Clearly, protocols unimportant to the victim can be filtered out based on this field, so the attacker will need to select reflectors that have one of the same protocol fields as the victim's desired traffic. But this will usually be very easy to do, because the desired traffic will almost certainly include TCP and UDP.
The checksum field should provide no traction. It is expensive for a filter to verify, but also appears impossible for the attacker to usefully manipulate.
The final two fields are the source and destination addresses. Obviously, the same filtering traction applies to these as does for ordinary DDOS floods: if either can be identified as an uninteresting address, then the victim can filter out the traffic; the attacker attempts to ensure that this is not the case. Also note that with a reflector attack, the source address will always be legitimate (Figure 2), unlike with the usual direct-spoofing attack (Figure 1).
Summary: assuming the attacker picks source and destination addresses of interest to the victim, the only angle the victim might try at the IP level is filtering on the DSCP.