> you will be exploited for amplification attacks! Is that the gripe? Am I missing something? Your bellybutton is not subject to these amplification attacks,

> you will be exploited for amplification attacks! Is that the gripe? Am I missing something? Your bellybutton is not subject to these amplification attacks, it is strangers on the internet and this is an altruistic appeal: you will be exploited for amplification attacks directed at others. What is the root cause of this vulnerability? The root cause is that anonymous[0] packets on the internet contain a destination address the packet is to be delivered to, and a source address to which responses should be directed. That might be a different construction than the average programmer internalizes. In the absence of countermeasures either address can be rewritten and this is commonly done in firewalls with e.g. NAT. The attack is to specify a source address "on behalf of" some other party, causing replies to be delivered there. Are there other ways to validate or render packets as not anonymous? Yes, to varying degrees. One is to establish a dialogue with the source address before sending payloads; in fact that's pretty much the good which abnegates perfection. There has been a BCP for many years that ASNs should validate that source addresses are valid.[1] Amplification is possible both in velocity and volume. Volume is when a reply packet is larger than the source packet. Velocity occurs when mulitple replies are sent. Even when no amplification occurs, attacks are mounted with e.g. ICMP. UDP amplification typically occurs when the reply packet is larger than the initiating packet. TCP amplification occurs when a SYN can elicit multiple SYN/ACKS.[3] (Both TCP and UDP are capable of eliciting ICMP backscatter.) The simple way to avoid amplification with UDP is not to send a reply. This is done a lot. For instance streaming data over UDP with a TCP pipe for control information. A bonus for this approach is that UDP is conducive to multicast[4], for which specific address ranges are reserved. Changing tuning parameters is an effective way to mitigate the TCP SYN/ACK problem, barring the appearance of flying monkeys.[5] DNS may be illustrative in a number of ways. First off clients aggressively retry queries due to "happy eyeballs", so the servers constantly face an identify friend or foe operating environment. DNS only ever sends one response to a particular query. A common server (if not protocol) extension is the implementation of response rate limiting, which drops a certain portion of UDP replies and returns the rest with TC=1.[6] Congratulations on reading this far. Now go get yourself a job as a cybersecurity analyst.[7] [0] If you trust the source in some other fashion and mark or validate packets in some way based on that, they're not anonymous. [1] https://www.rfc-editor.org/bcp/bcp38.txt https://www.rfc-editor.org/bcp/bcp38.txt I've worked with Ferg[2] [2] and Merike. [3] Which is pretty much all the time, because the default tuning everywhere is to send multiple SYN/ACKs. [4] Sending the same packet for delivery to multiple recipients. [5] /proc/sys/net/ipv4/tcp_synack_retries [6] Next time we'll talk about the fractured history of frags and the DNS. [7] Feel free to hire me!