At 10:53 PM 02/28/2000 -0300, Rubens Kuhl Jr. wrote:
Have anyone performed an evalution of rate-limiting SYN packets (CAR) versus using TCP-Intercept ? What responds better to a DDoS attack (assume SYN-flooding only) ? What uses more router resources ?
For better performance of CAR or TCP-Intercept, NetFlow switching (ip route-cache flow) should also be used, besides CEF ?
These are very tough questions, and questionable for the NANOG list (probably better suited for the cisco-nsp list), but since you ask, I can attempt an answer. "Router resources" is somehwat of an ambiguous term, so let's try to put this in perspective. Denial of Service (DoS) attacks eat up resources. Period. Fact of life. The point here is how intelligently defend against them, and lower the threshold of pain, Unfortunately, there is no magic bullet. How much resources get eaten up depends on lots of extraneous issues, to include whether the attack is focused on hosts which lie beyond a particular router, or targeted at the router itself. Having said that, it is important to take a quick review of what feature/functioanilty issues you are asking about: TCP Intercept: The TCP intercept feature implements software to protect TCP servers from TCP SYN-flooding attacks, which are a type of denial-of-service attack. In the case of illegitimate (a barrage of half-open TCP connections) requests, the software's aggressive timeouts on half-open connections and its thresholds on TCP connection requests protect destination servers while still allowing valid requests. When establishing your security policy using TCP intercept, you can choose to intercept all requests or only those coming from specific networks or destined for specific servers. You can also configure the connection rate and threshold of outstanding connections. You can choose to operate TCP intercept in watch mode, as opposed to intercept mode. In watch mode, the software passively watches the connection requests flowing through the router. If a connection fails to get established in a configurable interval, the software intervenes and terminates the connection attempt. TCP options that are negotiated on handshake (such as RFC 1323 on window scaling, for example) will not be negotiated because the TCP intercept software does not know what the server can do or will negotiate. Check here for how to configure TCP Intercept to defend against TCP SYN attacks: http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/s... Also, given that this feature is restricted to a particular software release train, it may not support specific higher-speed interfaces, and alternatively, may cause adverse packet-per-second performance impact (relative to line rates) which are not known at this time. I think this is a fair statement. Okay. What was next? CAR rate-limiting. One clever use of CAR is to set "rate-limiters" so that certain types of traffic (e.g. ICMP) is rate-limited to a ceiling, instead of diabled completely (rendering certain trouble-shooting tools inoperable). For an example of how CAR might be used in this capacity, see "Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks," especially the section on "Prevention." http://www.cisco.com/warp/public/707/newsflash.html Other stuff: NetFlow and CEF Fun stuff. Netflow: Don't think of NetFlow in any other capacity other than for trace-back capabilities: Characterizing and Tracing Packet Floods Using Cisco Routers http://www.cisco.com/warp/public/707/22.html CEF: You need this. For Unicast RPF. Otherwise, use RFC2267-style filtering. See also: http://www.denialinfo.com/ - paul