Smurf tone down

In a previous e-mail, alex@nac.net said:

My question is, why don't larger upstream providers use CEF-CAR (assuming
that most use this) do the same to limit the effect of smurf attacks on
thier (and subsequently, thier customers') networks?

  There are several issues with doing this, any one of which might
prevent a provider from using it.

1) Can't run CEF. There are some situations under which CEF causes
   problems. The good news is these are getting to be fewer and fewer
   every day, but as recently as 6 months ago it would regularly crash
   routers with some line cards under heavy loads. I expect this reason
   to disappear completely within another 6 months.

   Also, in the can't run catagory there are some (usually smaller)
   providers still using 7000's, 4000's, and other (dare I say even
   2501's?) for customer attach.

2) Can't spare the CPU. Sometimes this has to do with the load of CAR,
   although generally I expect this is due to other things. If you have
   150-200 T1 customers on a 7513 (easy to get with CT3 cards) and you
   run BGP to even just 25% of them, and you still have RSP2's then
   you probably don't have CPU to even think about giving to CAR, no
   matter how little it uses.

3) Can't manage it. Providers are understaffed with clueful people.
   That's a universal truth. If you have 1000 customers, that's 1000
   CAR entries to make, 1000 people who may ask why packets get dropped
   when they do some ICMP thing, 1000 people who might bug you to change
   to access list parameters.

   When you have a lot of customers it's probably best to make an
   all or nothing decision, one off's in large networks tend to make
   junior engineers make mistakes when they don't understand what's
   really going on.

4) Don't care. I don't mean this in shallow "screw the customer" way.
   Rather, if you're a large provider and you provide service to a
   small provider who's being smurfed you might assume the small
   provider did something to prevoke the attack, and as such the
   burden should be on them to track down the sources and report
   them so they can be perminantly shut off. If it doesn't saturate
   your links and your routers it's not your problem.

5) It's none of their business. This one works people up. The logic
   goes like this. If my provider CAR's ICMP automatically, why don't
   they also CAR porn automatically, so it's only a little traffic.
   Oh, and SPAM, that should be CAR'ed to help reduce it. All e-mail
   to and from a competitor, that should be CAR'ed really low....

   It's a dangerous road to go down.

  My $0.02 is I would be very upset if my provider automatically
put any sort of "filter" (including CAR) on my links. I do think it
is reasonable for them to make whatever effort they can to help me
if I get smurfed though. The effort may be CAR, it may be simple
filtering, it may be a legitimate "our routers can't take it".

1) Can't run CEF. There are some situations under which CEF causes
   problems. The good news is these are getting to be fewer and fewer
   every day, but as recently as 6 months ago it would regularly crash
   routers with some line cards under heavy loads. I expect this reason
   to disappear completely within another 6 months.

Good arguement. But it seems that no one is doing it.

   Also, in the can't run catagory there are some (usually smaller)
   providers still using 7000's, 4000's, and other (dare I say even
   2501's?) for customer attach.

Au contrair, monfrair (sp?!); CEF & CAR is available on many platforms
now; we've got it running on 3600's, 4700's, and 7200's. My understanding
is that is will also work on 2500's (I was told anything but PowerPC based
systems).

2) Can't spare the CPU. Sometimes this has to do with the load of CAR,
   although generally I expect this is due to other things. If you have
   150-200 T1 customers on a 7513 (easy to get with CT3 cards) and you
   run BGP to even just 25% of them, and you still have RSP2's then
   you probably don't have CPU to even think about giving to CAR, no
   matter how little it uses.

As said before, the demonstrable increase in load using CAR is abot 0-2%.

3) Can't manage it. Providers are understaffed with clueful people.

Is this really that hard?

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

4) Don't care. I don't mean this in shallow "screw the customer" way.
   them so they can be perminantly shut off. If it doesn't saturate
   your links and your routers it's not your problem.

But it could/might. I've seen repeatedly when other downstreams off the
same upstream router as us be attacked, the upstreams router usually is
unhappy.

5) It's none of their business. This one works people up. The logic
   goes like this. If my provider CAR's ICMP automatically, why don't
   they also CAR porn automatically, so it's only a little traffic.
   Oh, and SPAM, that should be CAR'ed to help reduce it. All e-mail
   to and from a competitor, that should be CAR'ed really low....

   It's a dangerous road to go down.

I don't subscribe to this. Your talking about two different levels of the
ISO model :slight_smile:

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
     Atheism is a non-prophet organization. I route, therefore I am.
       Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member
               Father of the Network and Head Bottle-Washer
     Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834
Don't choose a spineless ISP; we have more backbone! http://www.nac.net
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

> Also, in the can't run catagory there are some (usually smaller)
> providers still using 7000's, 4000's, and other (dare I say even
> 2501's?) for customer attach.

Au contrair, monfrair (sp?!); CEF & CAR is available on many platforms
now; we've got it running on 3600's, 4700's, and 7200's. My understanding
is that is will also work on 2500's (I was told anything but PowerPC based
systems).

According to Cisco's documentation

CAR is supported on these platforms:

* Cisco 2600 series

* Cisco 3600 series

* Cisco 4500 series

* Cisco 4700 series

* Cisco 7200 series

This is the listing in the IOS 12.0 documentation. I am not sure if CAR
is even supported in previous versions of their IOS.

It is unlikely, but it is also possible the upstream provider is running
non CISCO hardware which doesn't support CAR...

=== Tim

This is the listing in the IOS 12.0 documentation. I am not sure if CAR
is even supported in previous versions of their IOS.

It's also avail in 11.1.2x(CC) for the 7xxx's.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
     Atheism is a non-prophet organization. I route, therefore I am.
       Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member
               Father of the Network and Head Bottle-Washer
     Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834
Don't choose a spineless ISP; we have more backbone! http://www.nac.net
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

> 3) Can't manage it. Providers are understaffed with clueful people.

Is this really that hard?

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

But you all knew that already, right? :wink:

- H�vard

> 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'.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

> > 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