At 09:43 PM 12/3/98 -0500, Mark R. Lindsey wrote:

: ==>Could traffic shaping, or similar QoS configurations, be used to solve : ==>such issues in a more general way? : [...] : It has information on using Cisco's Committed Access Rate (CAR) feature : to rate-limit traffic such as ICMP echo/echo-reply and TCP SYNs.

Thanks, everyone, for your responses. It seems that lots of us agree that CAR sounds like a wonderful mechanism for taming smurf-like attacks. (Thanks, Cisco and others who have provided it.)

So isn't this the solution(**) to smurfing that we should be lobbying for? Consider: Using CAR to limit ICMP to a statistically normal range on all links has these features: * It can be implemented from the core out * It must be implemented by clueful network operators (because they run the core) * It must be implemented on a relatively small handful of rigorously-maintained routers

Implementing it on the core has some limitations. CAR works on a per protocol basis - not on a per flow basis. This means that someone with an OC-3 to some NAP might want to limit ICMP to 500kb/sec or some other reasonable number. What you want is not only an upper limit but a 8kb/sec limit on per flow or some other reasonable number. You also want a guarantee on certain IP addresses to get through and not be limited by CAR. When the Smurf is happening, you don't want your NOC pings and traceroutes dropped because of some CAR limit being exceeded. So you need to create a careful policy as to what gets bypassed by CAR limits and what gets shaped by CAR limits. -Hank

Compare this to the drive for limitations on directed broadcasts: * It must be implemented at the edges * It must be implemented by widely-varying clue levels * It must be implemented on hundreds of thousands of routers that no one ever touches

In short, the core grows slower, and is run by people with more experience. If the problem can be addressed there, then it seems like we *must* address it there.

Comments, please.

(**) You could well argue that limiting ICMP traffic on core/distribution links doesn't actually solve the problem -- lots of trash traffic can be generated on networks whose routers allow directed broadcasts. But that's if we define the problem to be trash ICMP because hosts reply to pings (or fraggle, or whatever); in such a case, traffic limitations are simply a kludge.

However, if you define the problem to be packet floods, then I think CAR provides a viable and real solution. After all, directed broadcast is a useful tool; in such a definition, disabling it on a network is a kludge. My limited studies seem to show that there are enough smurf amplifiers on the Internet to easily saturate OC-48s. Perhaps the real problem *is* flooding -- not directed broadcast.