North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
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 - - - - - - - - - - - - - - - - -