"Clifton D. McKinney" <clift@alltel.net> wrote:
Is this something that the "no ip directed-broadcast" command would prevent?
Nope (unfortunately)... I think I should clarify what the problem is again, since I've had a few private emails that suggest that what I originally wrote was confusing. The route-cache (fast-switching) speeds up switching by building a simple lookup table of IP-prefix/output-interface pairs by doing a routing table lookup (process-switching) for the first packet it sees that is addressed to any destination prefix. The problem is that to implement ICMP redirects, Ciscos have to do process-switching to figure out that the source and destination addresses are both out of the same interface and can therefore talk to each other directly (i.e. without pointlessly bouncing traffic off the router and causing the same traffic to go over the same network twice, wasting bandwidth). This would be fine and dandy if when they sent a redirect, the host that received it listened to it, and stopped bouncing traffic off the router, but if it doesn't (either stupidly or maliciously) then all traffic that is being bounced off the router has to carry on being process-switching, burning CPU cycles like it's going out of fashion. If you turn on 'ip route-cache same-interface' the router will still send a redirect for the first packet addressed to a particular prefix that it sees because it has to process-switch it to figure out what to put in the route- cache, but after that it will use the cache, and not look at the source addresses of packets to that destination at all (try turning on 'debug ip icmp' to see this behaviour). Whether you use the command or not is a trade-off based on whether you want redirects to work properly (stopping traffic being bounced off the router unnecessarily if other hosts listen to them), or if you would rather not burn CPU when other hosts don't listen to them and you have to switch the traffic back out of the same interface anyway. M.
The real problem is much more serious than it's used to think; I believe the only reason why we did not seen a lot of chain network failures caused by the different DOS attacks is just the same why _no one can catch the John - because no one want to do it_. Seriously, 90% of this attacks was caused by those who'd like to drop off their virtual enemies from the IRC or the CHAT server, or want to compromise some WWW server, or want to fraud some information in the network. No one of this tasks could be solved by the DOS against the routers. But if someone decide to break down the network attacking the routers, it more than possible. I think all of us know about some exploits used SYSLOG failure in the CISCO routers; it's many ways to slow router down by the data stream caused the router to use the processor switching (may be CEF can help here, I do not know). Moreover, I had a few very strange accidents here in Russia, when one dark night a chain of Cisco-7206 routers failed and appeared to be without the NVRAM config due to some uninvestigated scanning. And more complex the router's OS became, the more volurentable this routers became... Of course, routers usually have well designed IP stack and are not affected by the simple TEARDROP and so on programs; on the other hand, a lot of TCP and UDP services just as (for example) GRF tunnelling etc could be used to break the routers... No, there is a little chance to get access to the network, but the chance to slow network down or to torture it to the (virtual) death is very high. Of course, some new features are doing this attacks less effective. CEF switching, reverse-path address control, etc etc... But the danger of such attacks really exists, and is not limited by the ICMP attacks only. Alex Roudnev. On Tue, 9 Nov 1999, Martin Cooper wrote:
Date: Tue, 09 Nov 1999 15:03:52 +0000 From: Martin Cooper <mjc@cooper.org.uk> To: Clifton D. McKinney <clift@alltel.net> Cc: nanog@merit.edu Subject: Re: Possible DoS attack (?)
"Clifton D. McKinney" <clift@alltel.net> wrote:
Is this something that the "no ip directed-broadcast" command would prevent?
Nope (unfortunately)...
I think I should clarify what the problem is again, since I've had a few private emails that suggest that what I originally wrote was confusing.
The route-cache (fast-switching) speeds up switching by building a simple lookup table of IP-prefix/output-interface pairs by doing a routing table lookup (process-switching) for the first packet it sees that is addressed to any destination prefix.
The problem is that to implement ICMP redirects, Ciscos have to do process-switching to figure out that the source and destination addresses are both out of the same interface and can therefore talk to each other directly (i.e. without pointlessly bouncing traffic off the router and causing the same traffic to go over the same network twice, wasting bandwidth).
This would be fine and dandy if when they sent a redirect, the host that received it listened to it, and stopped bouncing traffic off the router, but if it doesn't (either stupidly or maliciously) then all traffic that is being bounced off the router has to carry on being process-switching, burning CPU cycles like it's going out of fashion.
If you turn on 'ip route-cache same-interface' the router will still send a redirect for the first packet addressed to a particular prefix that it sees because it has to process-switch it to figure out what to put in the route- cache, but after that it will use the cache, and not look at the source addresses of packets to that destination at all (try turning on 'debug ip icmp' to see this behaviour).
Whether you use the command or not is a trade-off based on whether you want redirects to work properly (stopping traffic being bounced off the router unnecessarily if other hosts listen to them), or if you would rather not burn CPU when other hosts don't listen to them and you have to switch the traffic back out of the same interface anyway.
M.
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
participants (2)
-
Alex P. Rudnev -
Martin Cooper