Huh. The solution is to not handle icmp type 3 or "hire official anti-ddos services"? I assume there's a way to maintain ICMP type 3 functionality while still mitigating this attack...?
Given that there's a list of products unaffected by this attack, I assume it can be fixed without impacting functionality. It seems like a widespread implementation problem, rather than an inherent design flaw.
Blocking ICMP type 3 breaks path MTU discovery. When the path MTU is less than the server's MTU, the client will typically send a request which is smaller than the path MTU and then the server's response isn't so it's the server that gets the ICMP message.
Blocking type 3/3 can also make some other denial of service attacks easier because it takes longer for the server to figure out that the device at that IP doesn't want the packets the server is sending when the request is from a spoofed IP address.
But what about TCP only? AFAIK, TCP RST is usually used when a packet is received with no connection. The only place I'm aware of that uses ICMP 3/3 is the REJECT iptables target when the defaults are used.
