Nmap Development mailing list archives

allow_ipid_match matching removed


From: David Fifield <david () bamsoftware com>
Date: Wed, 4 Nov 2009 20:14:21 -0700

Hi,

I just removed the special allow_ipid_match matching that was done in
scan_engine.cc. It applied a heuristic to sometimes match IP IDs in
packets returned in ICMP errors. For some background on this situation
see

http://seclists.org/nmap-dev/2009/q2/580
http://seclists.org/nmap-dev/2009/q2/665

I had to think a lot before making this change. The problem is that
enforcing an IP ID match could cause relevant packets--those that we
have already checked are associated with a probe we sent--to be ignored
in rare cases. In the linked case above, a host was sending back the
IP ID byte-swapped. The surprising thing was that the order in which
hosts were scanned mattered. If the byte-swapping host was scanned
first, the heuristic did not have time to come into effect, the
responses were not ignored, and the scan was accurate. If the order of
hosts was reversed, the first reply made the heuristic assume that all
IP IDs should be correct, the next reply would be ignored, and the scan
would be inaccurate.

As I said, in every case where the IP ID match was done, we already did
other tests to match the reply to one of our probes. The most that the
IP ID could do is cause us to ignore one of our probes and instead match
a different instance of the same probe. (As in, an original probe versus
a retransmission.) In some cases this can have an effect on timing, if a
response is counted as a drop or not. But not always: some probes have
extra information that also allows this discrimination, like most TCP
probes that have an identifier in the SEQ field. I eventually decided
that the potential small loss of some retransmission discrimination was
not worth potentially losing some probes that we are interested in.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: