The client knows the server is responsive because of the SYN/ACK,
and the server
knows the client isn’t being spoofed because of the ACK response.
UDP has no specified interactions. The protocol doesn’t have any header fields to
provide any state or connection management information. UDP is all about provid‐
ing a transport layer protocol that just gets out of the way of the application. When a
client
sends a message to a server, it is entirely up to the application how or whether
to respond. Lacking a SYN/ACK message to indicate that the server has received the
communication, the client may have no way of knowing
whether a port is open or
closed. A lack of response may merely mean that the client sent a message that wasn’t
understood. It could also mean an application failure. When performing UDP port
scans, the scanner can’t determine whether a lack of response means a closed port.
Therefore, the scanner would typically have to resend the message. Since UDP might
be
deprioritized in networks, it could take a while for messages to get to the target
and back. This means the scanner will typically wait for a short period of time before
sending again.
This will happen a few times, since the objective is to ensure that the
port is thoroughly ruled out.
This is the same scanning behavior that would happen if there was no response to a
TCP message. This could be a result of a firewall just dropping messages. Instead of a
RST message
or even an ICMP response, the scanner has to assume that the out‐
bound message was lost. That means retries. Retries can be time-consuming, espe‐
cially if you are scanning more the 65,000 ports. Each one may need to be retried
multiple times. The complexity of scanning UDP ports
comes from the uncertainty
from the lack of response.
