The problem pointed out by this announcement is that firewalls can spend significant resources on processing these relatively common ICMP error messages. Type 3 error messages are used for various "Unreachable" messages. For example, Type 3 Code 3 is used for port unreachable. For a complete list, see the official IANA list [2] .

The announcement doesn't make any statements as to why these packets take up so much CPU time. In my opinion, this is likely due to the firewall attempting to perform stateful analysis of these packets. ICMP unreachable packets include as payload the first few bytes of the packet that caused the error. A firewall can use this payload to determine if the error is caused by a legit packet that left the network in the past. This analysis can take significant resources.

According to the description of the attack, firewalls will suffer performance issues if hit by a few 10s of MBits of ICMP traffic, even for firewalls that are supposed to be able to dell with Gigabit networks. The "fix" is to block or rate limit the traffic.

It is not recommended to block all Type 3 ICMP messages. In particular Type 3 Code 4 (Fragmentation Needed and Don't Fragment was Set) messages are requied for path MTU discovery, which many modern operating systems use. Port unreachable messages (Type 3 Code 3), which were used in most of the tests performed by the group releasing this vulnerability, can usually be blocked but you may see some performance issue if for example a DNS resolver is attempting to connect to a non-existing DNS server, and then delays trying a secondary server because it never receives the port unreachable message.

So what should you do?

Don't panic. This is not a big deal. Test your firewall if you can, or check if is on the vulnerable list

You are vulnerable if you use a smaller Cisco ASA firewall. Newer/Larger multi-core versions appear to be fine. SonicWall and "some" Palo Alto firewalls appear to be vulnerable too.

iptables based firewalls are not affected

Monitor incoming ICMP unreachables. The advisory includes some snort rules to do so, but anything monitoring ICMP should work (netflow?) as no payload inspection is necessary

Monitor incoming ICMP unreachables? I'm getting a few host, port and protocol unreachables every hour. All unsolicited, all from hosts that were never contacted in the first place. Lots of repeat offenders. This has been going on for as far as I can remember.

This attack requires 100s or 1000s of packets per second. A few unsolicited ICMP packets per hour is perfectly normal backscatter. As far as monitoring goes, this is more about looking for excessive amounts on a scale required for the DDoS attack.

> In my opinion, this is likely due to the firewall attempting to perform stateful analysis of these packets.

In the case of ASA, the CPU spike seems to be related to two factors
1. Packet processing (like you mentioned)
2. Logging sub-system (seems to be default on ASA's to log this in "error" facility)

in that order. If you disable logging and tweak a few icmp unrechable parameters you can get some performance like Danish TDC company has pointed out. However overall the CPU spike shows some struggle the firewall is having in parsing/verifying the ICMP unreachable payload which contains IP headers and payload from the purported unreachable session.

The attack is interesting as it provides another asymmetric way to exhaust resources on firewalls. The only right mitigation seems to be upstream throttling or dropping (before the firewall) of ICMP unreachables code 3. Not all codes under ICMP unreachable (type 3) are as effective in CPU.