Re: The problem is the internet protocols - Explain!
There are many network protocols, and they exist in a hierarchy (I'm referring to the OSI model here; other models exist).
OSI layer 3, the Network layer, is "IP" or "Internet Protocol." Its job is to facilitate moving packets of data from one host to another, locally or across routers. While it is responsible for moving data between hosts, it cannot deliver it to the applications or services that need it-- that is done by OSI layer 4.
OSI layer 4, the Transport layer, is responsible for the end-to-end delivery of data for applications and services. There are two main Transport layer protocols for use with IP: "Transmission Control Protocol" or "TCP"; and "User Datagram Protocol" or "UDP."
You might recognize TCP from "TCP/IP," which commonly-- and improperly-- is used as shorthand for any Internet data communication. TCP is a "session oriented" protocol. That is, communication using TCP requires that the client and server establish a session before communication commences, which requires the client ask the server to start a new session, receive an acknowledgement from the server, and then negotiate the session details.
Setting up the session is, relatively, expensive: it take a bit of time, because multiple non-data exchanges need to occur first, and it requires a little more RAM to maintain information about the session. TCP has its benefits, however, because it guarantees the delivery of data by ensuring each packet is received and re-sending those that go missing. It also requires that the client address in the IP header be valid, because two-way communication is necessary to complete session setup. Most protocols make use of TCP: HTTP, SMTP, POP3, IMAP, SSH, TELNET, FTP, LDAP, SQL (Microsoft, MySQL, Postgress, Oracle, etc), and so on.
The other Transport layer protocol, UDP, is "the" problem. UDP is a "connection-less" protocol, which does not require any session setup. A client simply sends a UDP packet to a server and the server-- if it is listening-- sends a response. Because there is no session information, there is no built-in retransmission of lost packets, but that's usually okay because you rarely use UDP for anything sensitive to data loss: audio and video transmission are the most popular uses of UDP, along with DNS and NTP. It also doesn't perform any validation of the client address in the IP header.
The lack of session setup makes UDP ripe for abuse. A malicious user can create a UDP packet to a server with the "from" address field set to the target system the user wants to DDoS, "spoofing" the address. The server, upon receiving it, will then reply-- completely unaware that it is sending to a third-party.
UDP attacks are made worse by a process called "amplification." Take DNS, for example: the spoofed DNS request doesn't have to be very large-- maybe 120 bytes, maybe less-- requesting a particular domain name lookup, but the lookup could be for a domain name with lots of records, causing the reply to be ten or more times larger. This amplifies the attacker's power, allowing him to generate ten or more times as much traffic as he has directly available through his Internet connection.
Taking over an IoT device is even worse, as the attacker now has the potential to load custom scripts or firmware and generate attack traffic directly, without relying on amplification and with minimal Command and Control traffic. And because the traffic is sent using UDP, there's no session setup to prevent or mitigate the flood: it just goes and goes and goes.
It should be noted that TCP is not without its faults with regard to DoS attacks. One of the early DoS attacks involved sending bad session setup requests that were never completed but still caused the server to allocate resources while waiting for the session setup to complete, which ultimately lead to resource exhaustion and the denial of service. This has been at least partly mitigated, and tends to affect a small number of servers, so it is no longer a common attack method.
UDP attacks, on the other hand, are kind of like saturation bombardment: the target server is knocked out, and service is degraded or denied for anyone else using the same Internet connection as the target.