Before we address the question, let's discuss how UDP port scanning is typically done. 

When a host receives a UDP packet, what is supposed to happen is that if the host isn't listening on that port, it should reply with a ICMP Port Unreachable (ICMP Type 3, Code 3).  If it is listening on that port, the packet contents are fed to the listening application and processed.  If the application does not understand the packet contents, it might reply with an error, but most likely will drop the packet and not reply at all.

If there is any kind of a firewall involved, either on the host itself or in the network path, then quite often no reply at all will be received for the sent packet.

So an open port and a port protected by a firewall will often look the same to a scanner.  This can be a real problem when scanning UDP ports, as ports listening with a running service will look exactly like firewalled ports, which of course do not have a service available to the scanning station.

What UDP Protocol Awareness brings is a better payload.  With protocol awareness, a scan of the UDP DNS port for instance (udp/53), might be a an actual dns request.  A scan of an NTP (network time protocol) port could be an NTP timestamp or time request.  The application receives a valid packet, and if there is a listening port, a valid response is sent back to the scanner, and the scanner can now know for certain that this port is open!

To illustrate - first, let's scan an NTP (Network Time Protocol) server's NTP port with an older version of Nmap (5.0).  This behaviour is typical of most port sc

C:> nmap -sU -p123 192.168.122.254

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-28 13:17 Eastern Standard Time

Interesting ports on 192.168.122.254:
PORT    STATE         SERVICE
123/udp open|filtered ntp
MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 1.91 seconds

As you can see, the port shows as open/filtered.  From the packet trace below, you can see that an emtpy packet is sent to udp/123, no valid NTP data is contained, and the NTP server simply drops the packet.  There really is an NTP server running, but there's no way to tell for sure using this method of scanning.

Now let's run the same scan with Nmap 5.2, which has UDP protocol awareness.

C:>nmap -sU -p 123 192.168.122.254

Starting Nmap 5.20 ( http://nmap.org ) at 2010-01-21 22:15 Eastern Standard Time

Nmap scan report for 192.168.122.254
Host is up (0.0019s latency).
PORT    STATE SERVICE
123/udp open  ntp
MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 6.88 seconds

The difference is immediately apparent, the port now has a state of open, instead of open/filtered.  Let's take a look at the packet and see exactly why ..

As you can see, Nmap is sending an actual NTP client timestamp of the NTP server, and it gets an NTP server response back.  This identifies both the fact that the host is actually listening on that port, as well as the fact that it's an actual NTP service that's listening.

Currently NMAP 5.21 supports protocol specific payloads for:
udp/7           echo
udp/53        domain
udp/111      rpcbind
udp/123      ntp
udp/137      netbios-ns
udp/161      SNMP
udp/177      xdmcp
udp/500      ISAKMP
udp/520      route
udp/1645 and udp/1812   RADIUS
udp/2049    NFS
udp/5353    zeroconf
udp/10080 amanda

This is an exciting development, allowing us to scan these particular ports with a LOT more accuracy than previously possible.   Again, Fyodor and the NMAP crew have replaced a number of other tools simply by adding some new features to NMAP - great job!

=============== Rob VandenBrink, Metafore =================