This article is nice and it shows clearly what kind of problems servers for TCP-based infrastructure on the internet have to face. The issue I have with it: It

This article is nice and it shows clearly what kind of problems servers for TCP-based infrastructure on the internet have to face. The issue I have with it: It's showing how the problem can be solved for systems that you are in control of, but not for systems (clients) that you aren't in control of. The reason why servers on the web are so easily DDoS-able is because of long-lived connection defaults among most higher-level protocol implementations...and because ISPs all over the globe intentionally throttle initial connections by up to 30-60 seconds for the initial SYN/SYN-ACK when their "flatrates" run out on mobile networks. Server administrators then face the decision to either drop the mobile world completely or be faced with a situation where a couple malicious actors can take down their infrastructure with simple methods like even a slowloris or a SYN flood attack. This is also not discussing the problem that ISPs allow (relayed) amplification attacks because they don't think it's their responsibility to track where traffic comes from and where traffic is supposed to go; whereas I would disagree on that. If I would have influence like cloudflare in the IETF/IANA/Internet Society, I'd try to push initiatives like this: - Disallow ISPs from spreading network traffic that they can easily detect as amplification attacks. If UDP origin in the request packet != UDP target in the response packet, simply drop it. - Force ISPs to block SYN floods. This isn't hard to do on their end, but it gets harder to do inside your own little infrastructure. If an ASN doesn't block SYN floods regularly, punish them with blocked traffic. - Force lower network protocol timeouts. If a socket's network timeout is 60 seconds, it's total overkill for this small planet and only serves to allow this shitty behaviour of ISPs and nothing more. Even in the world of 56k modems, this doesn't serve a purpose anymore. - (like Google) Try to push UDP-based networking stacks that (with above exception) try to solve this connection timeout problem by allowing to dynamically multiplex / multi-pipeline traffic through the framing protocol of the same UDP socket.