NAP/ISP Saturation WAS: Re: Exchanges that matter...

Fri Dec 20 21:29:45 UTC 1996

   If Cisco don't implement ICMP response in some sort
   of kernel layer below "application" layers handling other such functions
   the obvious question is "why not?". It must be possible to do this - just
   take your Netstar and downgrade the processor to a 386SX and see if it
   still works (fast external switching engine, slow processor).

It is indeed possible.  However, it will not "solve" the problem.  Note
that the major impact of doing things at process level is pulling the
entire packet across the bus.  Just putting it in the "kernel" (i.e.,
during fast switching, in interrupt context) would be far less interesting
than eliminating the bus copy.  Of course, if you eliminate that, then you
increase buffer occupancy.

   I believe Microsoft's response was (a) to handle ICMP echos further down
   in the kernel or at least without breaking upper layers quite so much and

The upper layers will break regardless.  That's part of life with a real
time control system.  Even if you handle it in the kernel, you're consuming
the system.

   (b) to drop ICMPs if they arrived too often. I did *not* say Cisco should
   answer all ICMP echo requests, just not break (or try and avoid it).
   "Even" Solaris has things to tweak ICMP response. With all respect (as
   you know far more about Cisco inards than I do) this sounds very like
   people at certain OS vendors who said "SYN flood attacks, ah yes, well
   such DoS attacks are inevitably extremely difficult to prevent". Indeed.
   But will it really take someone ICMP streaming with forged source addresses
   at Sprint's core routers for Cisco to fix it?

I think that there's some lack of clarity on the problem here.  Anyone can
stream packets at ANY router and take it down.  If it's not ICMP, you can
simply forge routing protocol packets.  It's a question of simply
supersaturating the system.  To truly deal with DoS attacks, there are
basically three approaches:

1) Throw money at the problem.  Build a big box that has enough processor
to deal with the incoming bandwidth for pessimal packets.  Even then, the
bad guys can simply supersaturate the incoming bandwidth.

2) Deal with it statistically.  For example, most folks for the recent syn
attacks will drop syns if they don't complete reasonably, thereby allowing
some percentage of real traffic to get through.

3) Deal with it legally.  This is what the telco's do.  It implies that we
would need real mechanisms for tracking down offenders.

Now, if you truly believe that you want solution 1, you should show up at
your favorite router vendor with a large box o' cash.  Probably 10X what
you're currently paying.  Solution 2 is fine for a bit, but is less certain
because it implies that you can quickly and easily differentiate beneficial
traffic from detrimental traffic.  Solution 3 is by far the easiest and
cheapest, but it requires cooperation.

As to what cisco will do, you should probably ask cisco.

Tony