DDoS: CAR vs TCP-Intercept vs NetFlow
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 ? Rubens Kuhl Jr.
On Mon, Feb 28, 2000 at 10:53:41PM -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 ?
TCP Intercept uses much more, but the concept of TCP Intercept is to enable the server to continue accepting new connections, while CAR against SYNs will most likely impact that ability significantly. TCP Intercept would not have been effective against these attacks (or any other attack large enough to be a DDoS) due to the sheer number of packets/sec involved. In reality TCP Intercept is like putting a SYN flood tuned TCP/IP stack in front of an entire network, its useful for protecting hosts which for whatever reason cannot handle any serious syn flood. Many people do not understand that there is a large factor in a SYN flood called magnitude. The earliest generation SYN floods (PANIX fame) filled simple connection queues and denied new connections with very low bandwidth required by the attacker (dialup speeds). The high speed / DDoS syn floods of today are on the order of tens or hundreds of thousands of packets/sec, and aim to completely disable the target they are attacking by using all available CPU in the kernel processing SYNs instead of doing other things. Modern PC CPUs are of a much higher power (for the price) then router CPUs, and you will probably fair much better with a p3 500 on a good FastEthernet connection and a decent OS doing intelligent dropping.
For better performance of CAR or TCP-Intercept, NetFlow switching (ip route-cache flow) should also be used, besides CEF ?
NetFlow improves performance of long access lists, it will not help CAR (which is queue based) or TCP Intercept. CEF is your best bet. -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) MFN / AboveNet Communications Inc - Network Architect, Vienna VA
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
Other stuff: NetFlow and CEF Fun stuff. Netflow: Don't think of NetFlow in any other capacity other than for trace-back capabilities:
Thanks for the long answer, but this question was actually on how the router performance impact of CAR or TCP-Intercept changes between using CEF switching (ip route-cache cef, default) and CEF-Flow switching (ip route-cache cef + ip-route cache flow). Although NetFlow impacts router performance a little, running CEF-Flow makes large access-list processing faster than just running CEF; I think some other features (IPSec ?) also have performance gains. I was wondering whether CAR and/or TCP-Intercept would have better performance with CEF-Flow. Rubens Kuhl Jr.
At 12:06 AM 02/29/2000 -0300, Rubens Kuhl Jr. wrote:
Thanks for the long answer, but this question was actually on how the router performance impact of CAR or TCP-Intercept changes between using CEF switching (ip route-cache cef, default) and CEF-Flow switching (ip route-cache cef + ip-route cache flow). Although NetFlow impacts router performance a little, running CEF-Flow makes large access-list processing faster than just running CEF; I think some other features (IPSec ?) also have performance gains. I was wondering whether CAR and/or TCP-Intercept would have better performance with CEF-Flow.
Again, forget about flow-switching in any context except for tracing back attackers. If you want the functionality to lower the threshold of DoS pain, CEF is your baby. This is an operational forum, yes? Where is the input from the (current) operators? - paul ps. And they can both be used in conjunction with one another to reach an end goal...
On Mon, 28 Feb 2000, Paul Ferguson wrote:
Again, forget about flow-switching in any context except for tracing back attackers.
Correct.
If you want the functionality to lower the threshold of DoS pain, CEF is your baby.
When it is working, yes.
This is an operational forum, yes? Where is the input from the (current) operators?
We're still waiting on the hidden commands to be documented as mentioned below. http://www.zdnet.com/intweek/stories/news/0,4164,2435950,00.html {quote} Routers from Cisco and other vendors have the ability to detect the signature patterns of a denial-of-service attack, and the routers can filter out that traffic, Farnsworth said. \end{quote} /vijay
On Tue, Feb 29, 2000 at 12:06:02AM -0300, Rubens Kuhl Jr. wrote:
Other stuff: NetFlow and CEF Fun stuff. Netflow: Don't think of NetFlow in any other capacity other than for trace-back capabilities:
Thanks for the long answer, but this question was actually on how the router performance impact of CAR or TCP-Intercept changes between using CEF switching (ip route-cache cef, default) and CEF-Flow switching (ip route-cache cef + ip-route cache flow). Although NetFlow impacts router performance a little, running CEF-Flow makes large access-list processing faster than just running CEF; I think some other features (IPSec ?) also have performance gains. I was wondering whether CAR and/or TCP-Intercept would have better performance with CEF-Flow.
The answer to the specific question is, NetFlow has absolutily no impact on CAR or TCP Intercept. Committed Access Rates are based on probability dropping of packets in a queue and has nothing to do with flows. TCP Intercept tracks flows on its own, to my knowledge there is nothing it can use from NetFlow. Generally speaking, CEF will give you the best performance when dealing with high-volume packet DoS. Flow is useful for gaining information, but apart from access-list considerations it has another layer of information used in switching, therefore it will be a bit slower (l3 src/dst + l4 protocol and ports as opposed to just l3 dst) for other purposes. Be careful with flow when dealing with random src or random dst (for example, an attack which elicits a victim system to send replies to random destinations) attacks, or it may not help you much (as the flow cache gets max'd). -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) MFN / AboveNet Communications Inc - Network Architect, Vienna VA
At 11:15 PM 02/28/2000 -0500, Richard Steenbergen wrote:
Be careful with flow when dealing with random src or random dst (for example, an attack which elicits a victim system to send replies to random destinations) attacks, or it may not help you much (as the flow cache gets max'd).
Just like they say about vitamin fortified cereals, "it's in there". The flow-switching creature features have enough functionality to trace an attacker back to its source. Yes, its painful. Yes, it has to be done in real-time. Yes, actually, it has been done before. No, there is no other real way to do it. People: Start source filtering so we can get beyond these inane discussions. - paul
participants (4)
-
Paul Ferguson -
Richard Steenbergen -
Rubens Kuhl Jr. -
Vijay Gill