Re: Effects of traffic shaping ICMP (&c.)

[Hank Nussbacher <hank () ibm net il>]

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.