Nmap: problem with UDP scanning and --ip-options

[Bogdan <bogdandr () op pl>]

 Hello everybody.

 I have a problem with nmap. It goes like this: when I scan a closed
UDP port with no IP options, nmap sends one UDP packet, gets one
packet back (ICMP destination unreachable, port unreachable),
determines that the port is closed and shows the port as closed in the
results (with reason port-unreachable).
 Now, when I scan the same port with any IP options ("--ip-options U"
is the easiest), nmap sends 2 UDP packets (like it got no response for
the first), gets two ICMP packets back, but shows the port as
open|filtered (like it got no response).
 Enabling debug mode shows:
        Received short ICMP packet (86 bytes).
 The total IP length in the received packets is set to 92 (20 for IP,
8 for ICMP, 20+36 for the erroneous packet with the options and 8 for
the UDP header) and this should be the expected length. But the
received packet isn't shorter, as nmap would suggest. Wireshark
recognises it easily.
 Moreover, there is a second problem with this scan: if the erroneous
packet is artificially shortened to 28 bytes (20 for the shorter IP
header, instead of 56, and 8 for UDP), it is recognised correctly and
the port is marked as closed. But the RFC for ICMP says that the
"Internet header" should be included in the ICMP
destination-unreachable message. It doesn't say "The minimum Internet
header", so I guess it should be the full header, even if it's longer
that the minimum 20 bytes.
 The third problem: the shortened packet's checksums can be freely
modified and nmap will still recognise the packet, parse it and mark
the port as closed.

 Reproducible: each time.

 Steps to reproduce: select a closed UDP port <port> on a machine
<name>, then perform:
        nmap -sU -p <port> <name>
        nmap -sU -p <port> --ip-options U <name>

 Results got:
        closed
        open|filtered

 Results expected:
        closed
        closed

 Furthermore, rejecting incorrect ICMP packets is expected (incorrect
both in terms of checksums and the fact that the ICMP packet did not
contain the nmap's sent packet's header).

 Tested on versions: 5.21 (stable), 5.35DC1, 5.36TEST3 on a WinXP
machine with Zenmap (on admin rights, of course). Target systems:
WinXP & Linux 2.6.x. Wireshark pcap dump available, if required.

 Is this a bug in nmap, am I doing something wrong, or is this the
correct behaviour?

 The last question: is there an "open bug list" for nmap? Searching
the site and mailing lists on my question's topic didn't produce any
results, so I'm not sure if I'm not sending a duplicate report for
something already reported or marked as "not to be fixed".

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org   www.TorProject.org   Soft (EN): miniurl.pl/bogdro-soft
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/