NAP/ISP Saturation WAS: Re: Exchanges that matter...
amb at xara.net
Fri Dec 20 10:28:32 UTC 1996
> The fact remains that a ping packet stream a Linux 386SX would barely
> notice maxes out a 7010 (far more powerful CPU)
> Bzzzt. That's a 30Mhz 68040 you're talking about. You're 386SX is on par
> if not ahead.
Well I'd have said 68030~=386SX but anyway...
> And you might recall that it's handled at process level,
> whereas Linux does it at kernel level (or at least other Unixen do).
Well this is the real point isn't it. Though Cisco has obviously paid
an awful lot of attention to switching packets fast its host IP stack
seems to be particularly bad compared to something built with a decent
TCP/IP stack. 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).
> Rather and obvious DoS attack, and one which even MS were red faced
> enough to fix in their NT s/w pretty sharpish.
> You can DoS attack anything with echos. Trying to make echo handling "fast
> enough" is an untenable problem. So you should simply drop them on the
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
(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?
More information about the NANOG