North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

[long] Re: DDoS: CAR vs TCP-Intercept vs NetFlow

  • From: Paul Ferguson
  • Date: Mon Feb 28 21:39:44 2000

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/secur_c/scprt3/scdenial.htm#xtocid254810


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