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 floor...
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? Alex Bligh Xara Networks