CAR Design Considerations
One of the first tasks in successfully configuring CAR is determining what normal traffic loads are. One c the easiest ways to do this is to start your CAR policy by setting your conform action to transmit and yo exceed action to transmit. This command for the previous ICMP example looks like this:
Router(config-if)#rate-limit output access-group 102 100000 8000 8000 conform-action transmit exceed-action transmit
In this way, no traffic is dropped, but the CAR process is still running. You can then check to see what amount of your traffic is conforming and what is exceeding with the show interface int rate-limit command. The following is an example of the output of this command:
Router#sho interface fa0/0 rate-limit
FastEthernet0/0 Output matches: access-group 102 params: 96000 bps, 8000 limit, 8000 extended limit conformed 393 packets, 566706 bytes; action: transmit exceeded 4224 packets, 6091008 bytes; action: drop last packet: 0ms ago, current burst: 7072 bytes last cleared 00:03:51 ago, conformed 19000 bps, exceeded 210000 bps matches: access-group 103 params: 48000 bps, 4000 limit, 4000 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop last packet: 79586392ms ago, current burst: 0 bytes last cleared 00:03:20 ago, conformed 0 bps, exceeded 0 bps matches: access-group 104 params: 48000 bps, 5000 limit, 5000 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop last packet: 79586392ms ago, current burst: 0 bytes last cleared 00:02:42 ago, conformed 0 bps, exceeded 0 bps
From the output, you can see that the router is currently rate limiting a small ICMP flood. You can see the number of packets that exceeded the rate, as well as a number of other interesting statistics.
CAR is powerful because if the attack can be classified properly, the network under attack is unaffected and can continue to service legitimate requests. In the previous ICMP example, a 100 Mbps flood of ICM traffic would be reduced to a 100 Kbps stream, certainly not enough to adversely affect the network. Th main problem with CAR is that it cannot effectively identify certain types of flooding attacks. UDP floods and ICMP floods are easy, but what if you are flooded with TCP 80 traffic with the acknowledgment (ACI bit set in the TCP header? This is exactly the sort of traffic you should be permitting into the network, s( distinguishing the attack by using CAR is impossible.
Also keep in mind that some types of CAR filtering require quite a bit of care in deploying. The TCP SYN option is the most sensitive. Assume that your normal TCP SYN rate is 100 Kbps, and you occasionally spike to 300 Kbps. You implement CAR for TCP SYN and provide a committed rate of 500 Kbps. A TCP SYN flood attack is launched against your network, sending 100 Mbps of TCP SYN trafficenough to fill up your T3 without CAR. By using CAR, you see only 500 Kbps of the attack, but now any new TCP session won't establish because TCP SYN traffic is being rate limited so extensively. Existing TCP traffic will still pass, but if most are short-lived HTTP connections, the user's web session will quickly stop functioning.
At this point, sessions to that IP address are being dropped, but at least the rest of your network is still functioning. Other systems, routing protocols and so on, continue to work. For this reason, most users choose not to implement TCP SYN flood protection, or any CAR, all the time. Rather, they wait until the attack begins and then work with their ISP to implement the feature. Design Techniques to Mitigate DDoS
As a security architect, there are two primary techniques you can use to reduce the chances of a successful DDoS attack in the first place: e-commerce-specific filtering and content delivery networks.
Continue reading here: SYN Cookies
Was this article helpful?