DRate LimiterMagic NumberIP Destination addressInput interfaceOutput interfaceTimestampPacket sizeReasonVarious header fieldsRLS-IDMaximum depthDepth of Requesting NodeBandwidth LimitExpiration TimeCongestion SignaturePushback MechanismSubmitted bySuma Iyli & Kanthi RekhaPushback Mechanism1.0 Introduction1.1 Overview of Pushback2.0 ArchitectureMatch N PYUpdateCongestion Adjust DACC2.1 Aggregate Detection2.2 Rate Limiting2.3 Pushback3.0 Implementation4.0 Conclusion5.0 References:Pushback MechanismA Router-Based Defense Against DDoS AttacksSubmitted bySuma Iyli & Kanthi RekhaPushback MechanismA Router-Based Defense Against DDoS Attacks1.0 IntroductionDistributed Denial of Service (DDoS) attacks have become an increasingly frequent disturbance of the global Internet. They are very hard to defend against because they do not target specific vulnerabilities of systems, but rather the very fact that the target is connected to the network. The Distributed Denial of Service (DDoS) attacks are slightly different from the Denial of Service (DoS) attacks. DoS attacks come from one or more hosts directed at some resource of the network such as a link or a web server whereas in the Distributed Denial of Service (DDoS) attacks the attacking traffic comes from large number of disparate sites. DDoS may be caused by flash crowds or malicious hosts. Flash crowds occur when large numbers of users try to access the same server simultaneously. The site www.olympics.com triggered such an event during Olympics-2000. DDoS caused due to malicious hosts take advantage of the large number of unsecured hosts on the Internet; the perpetrators break into such hosts, install slave programs, and at the right time instruct thousands of these slave programs to attack a particular destination. The attack does not have to exploit a security hole at the target to causea problem. So, there is almost nothing the victim can do to protect itself.While the intent and triggering mechanisms for the DDoS due to flashcrowds and the DDoS due to malicious hosts are quite different, from the networks perspective these two events are quite similar. The persistent congestion is neither due to single well-defined flow, nor due to an undifferentiated overall increase in traffic. Instead the congestion is caused by aggregates (defined as a subset of the traffic with an identifiable property) that cannot be controlled by the conventional flow based protection mechanisms (TCP/IP flow control). This paper describes a network-based solution, called Pushback, to address the question of whether anything can be done inside the network to defend against DDoS attacks1.1 Overview of PushbackIf the router can detect all the bad packets and just drop those then the problem would be simple. But the routers cannot be 100% sure whether the packet belongs tobad traffic or good traffic. The goal of the pushback is to find the bad packets as far as possible and drop those without interfering with the good ones. To fulfill this mission Pushback uses Aggregate Congestion Control (ACC). The challenge here is to identify aggregates responsible for congestion and drop them at routers. "Packets to a particular host/server”, “TCP SYN packets”, or even “IP packets with a bad checksum” are all few examples of aggregates. Pushback can be explained with the help of the figure below.1Figure 1. A DDoS attack in progress.Consider the network in Figure 1. The server D is under attack and all the traffic to D is coming from routers R1 to R8. The red lines show links with bad or attack traffic and the green lines show links with no bad or non-attack traffic. In the absence of any special measures, hardly any non-attack traffic would be reaching thedestination. Even though the links R2-R5, R3-R6 R5-R8, R6-R8, and R8- D are red there may be some non-attack traffic flowing through them but most of it is dropped due to congestion in R8-D. The term's bad traffic, poor traffic, good traffic are referred frequently in this paper. Bad traffic contains bad packets sent by the attackers. Bad traffic is characterized by an attack signature or congestion signature (defined as a set of properties of the aggregate identified as causing problems), which we strive to identify. Poor traffic consists of packets that match the congestion signature, but are not really part of an attack. They are just the unlucky ones, which have the same properties (for ex: the IP destination address) as the Bad packets, which put them into the black list. Good traffic does not match the congestion signature, but shares links with the bad traffic and may thus suffer.In the figure above there is both good and bad traffic are entering routers R2, R3, R4 whereas only bad traffic is entering R1. Links R2-R5, R3-R6 might consist of both good and bad traffic but the good traffic will suffer depending on how congestedthe links are. Some of the good traffic entering R7 from R4 goes to R8 and some of it exits through the right link. Since the link R8-D is already congested even though the filters of R8 work properly the good traffic coming from R7 cannot enter R8.When the Pushback mechanism is used R8 sends a message to R5 and R6 telling them to rate limit traffic for D even though the links downstream from R5 and R6 are not congested. This is because the router R8 is going to drop packets destinedfor D anyway so it is better not to waste the bandwidth of the upstream links for these packets. In turn the routers R5 and R6 propagate the request up to R1, R2, and R3, telling them to rate-limit the bad traffic, allowing some of the ‘poor’ traffic, and more of the good traffic, to flow through.R7R6R4R5R3R2R1R8D22.0 ArchitectureFigure 2 shows the architecture of the router. The input queues shown here are the various input links to the router. First the packet is checked whether it matches the congestion signature or not. If the congestion signature is not matched then the packet is sent to the output queue, otherwise it is sent to the rate limiter. The rate limiter decides whether the packet is to be dropped or forwarded. The dropped packets are sent to the Pushback daemon, pushbackd. The daemon, in turn, periodically updates the parameters of the rate limiter, and also informs the upstream daemons to update theirs. Pushback daemon may not reside on the router itself, but rather on an external ancillary piece of equipment. Input queues
View Full Document
Unlocking...