Why does a LAN-side UDP flood take up the target's CPU resources and make it sluggish?
This depends on a number of factors, one of the primary being what action is taking place on the system receiving the UDP flood. Let's take a look at the basics of the process.
To begin, the host receives the UDP traffic. All received traffic must be processed to some degree. At the very least, the destination port of the UDP traffic needs to be determined. This means the Ethernet and IP headers are removed as it moves through the network stack and is handed off to be processed as a UDP segment. There may also be firewall rules to process as well.
The destination port is checked to see if there is an application listening on that UDP port (either a service bound to the port or a port used by outbound traffic that may be expecting reply traffic).
If there is an application listening on the UDP port, the UDP headers are removed and passed to the application. The application then needs to process the data in whichever way it is configured to do so.
If there isn't, the host can respond in one of two ways: silently drop the data or to reject the data. Rejecting the data is generally considered more "friendly" and makes things like debugging easiers as a notice that the traffic is rejected is sent back to the source of the traffic using ICMP. This is good when traffic is accidentally sent to the wrong host or port and can cause the unwanted traffic to stop (if the sending host/application recognizes the traffic is unwanted).
So, we have a process. Now, in that process, most of the above can be done in hardware if the network adapter (and the driver, OS, etc) support it. What isn't done in hardware is done in software by running on the CPU.
Where can the use of the CPU come from? Largely from the following four possibilities:
- Processing the received traffic (Ethernet -> IP -> UDP), including any firewall rules
- Checking for applications listening on the UDP port
- Application processing data received on a listening port
- Generating return traffic (ICMP error messages)
Why a specific host becomes sluggish would be the result of it performing one or more of the above in software (i.e. CPU).
If a host processes the traffic (including firewall rules) and drops unwanted traffic (or processes the reject) all in hardware, there should be no impact on the CPU as a result of a UDP flood to UDP ports to which it has no application listening.
How a specific application is affected by receiving unwanted traffic to a port it is listening on would be entirely up to the application.