...

...

access-list 175 permit icmp any any int bleh/bleh rate-limit input access-group 175 128000 8000 8000 conform-action transmit exceed-action drop rate-limit output access-group 175 128000 8000 8000 conform-action transmit exceed-action drop

I agree, the above isn't all that hard.

However, I'd argue that the above is in some sense wrong. There's no need to put all ICMP traffic in the same basket; some ICMP traffic is required for e.g. path MTU discovery to work. So, instead I'd use

access-list 175 permit icmp any any echo-reply

With all the smurf amplifiers available, it is of course easier to generate several Mbps of ICMP Echo Reply than it is to generate large amounts of other ICMP traffic.

However, if your network is exposed to several Mbps of inbound ICMP *other* than Echo Reply, it may be equally bad for your network. So I prefer to leave it as 'icmp any any'.

I'll claim that the only real problem that is reasonable to CAR is ICMP Echo Reply traffic. That (and UDP echo, possibly to a lesser extent) are the only types of traffic where the attacker can abuse remote amplifier networks, which contributes to the "popularity" of these attacks. However, just rate-limiting all ICMP traffic will cause a Smurf attack of the current variety to have a larger impact than what it would otherwise have: o it will make network reachability testing via traceroute difficult at best, since the ICMP TTL Exceeded messages will also be rate-limited. o it will cause "ICMP unreachable, fragmentation required but DF set" messages as used by PMTU to be dropped, causing lousy performance or "strange" connectivity problems for those systems which depend on that type of feedback from the network. (Assuming you have some capacity left after the Smurfing, of course, which also goes for the above point...) o it will also cause all other types of ICMP messages to be dropped, some of which are important for proper operation under normal circumstances. If, however, the attack you're under is injected directly from other well-connected hosts under the attackers control without the assistance of amplifier networks, the attacker is free to choose any type of traffic to inject, be it ICMP, UDP, TCP SYN or any other IP protocol, and as far as I know there's no reasonable way to use rate-limiting to counter that sort of traffic (?). - Håvard