Intra-domain IP traceback using OSPF - Semantic Scholar

Download PDF
17 downloads 114176 Views 165KB Size Report
Comment
to provide intra-domain IP traceback to deal with this threat. The main ..... placement, i.e. to identify 80% and 100% of the routers from. 0. 10. 20. 30. 40. 50. 60. 70. 80 ... holding the same scale-free characteristics of inter-domain topologies, the ...
Intra-domain IP traceback using OSPF Andr´e Castelucio, Antˆonio Tadeu A. Gomes, Artur Ziviani

Ronaldo M. Salles

National Laboratory for Scientific Computing (LNCC) Av. Get´ulio Vargas, 333 – 25651-075 Petr´opolis - RJ - Brazil {castelucio, atagomes, ziviani}@lncc.br

Military Institute of Engineering (IME) Prac¸a General Tib´urcio, 80 – 22290-270 Rio de Janeiro - RJ - Brazil [email protected]

Abstract—Denial of service (DoS) attacks are a serious threat to the appropriate operation of services within network domains. In this paper, we propose a system that creates an overlay network to provide intra-domain IP traceback to deal with this threat. The main contribution of our proposal with respect to previous work is its ability to provide partial and progressive deployment of the traceback system throughout a monitored network domain. We build the overlay network using the OSPF routing protocol through the creation of an IP Traceback Opaque LSA (Link State Advertisement). We also investigate and evaluate the performance of partial and progressive deployment of the proposed system, showing its suitability even for large network domains.

I. I NTRODUCTION Currently, denial of service (DoS) and distributed denial of service (DDoS) attacks are common in the Internet [1], [2], [3]. Such attacks aim to make a network or a service provided by the network unavailable to requests coming from legitimate users. This typically happens when an attacker sends packets at a rate higher than the victim can process; and modern DDoS attacks occur with multiple distributed attacking sources simultaneously sending packets against a target victim. The defense against (D)DoS attacks comprises three main different steps: (i) the detection of the attack, which is usually performed by intrusion detection and prevention systems [4]; (ii) the identification of the route(s) taken by attacking packets, which can be provided by IP traceback systems [5], [6], [7], [8]; and (iii) the mechanism to block attacking packets at key points along the route(s) taken by them. This paper focuses on the second step above, i.e. on the identification (at least partially) of the route(s) taken by attacking packets. Identifying such route(s) is a challenging task, for several reasons: (i) IP routing is solely based on the destination IP address carried by each packet; (ii) due to scalability restrictions, no information about packet forwarding is normally kept at the intermediate routers; (iii) attackers can be behind a firewall or protected by a private IP address, thus even if the network keeps track of the routes taken by attacking packets, such routes will usually point to network middleboxes as the sources of attacking packets; (iv) IP packets are not authenticated at the moment they are forwarded, allowing spoofed source IP addresses to be used in (D)DoS attacks [9], [10]; and (v) zombie hosts—remotely controlled by an attacker—are used for sending attacking packets and, in this case, their owners are unaware they are taking part in a DDoS attack.

Previous work on IP traceback systems typically requires complete deployment of the system over the network, i.e. the system must operate on all routers in the network to properly traceback an ongoing (D)DoS attack. We believe this constraint limits the possibility of such IP traceback systems to be used in larger networks. Our main contribution in this paper when compared with related work on IP traceback (see Section II for a detailed discussion on related work) is the proposal of an intra-domain IP traceback system that can be partially and progressively deployed on networks taking part of an Autonomous System (AS).1 The main motivation to develop an intra-domain IP traceback system with such characteristics stems from the fact that the decision of its deployment within a domain can be based on a trade-off between the intended system performance and the required investment to be done by the administrative authority depending on the size of the domain. We evaluate this trade-off through simulations, showing the feasibility of deploying this IP traceback system in large domains. We demonstrate that an efficient traceback implementation can be achieved even with a relative small portion of routers in the domain having the system deployed. The remainder of this paper is organized as follows. In Section II, we discuss related work. Our proposed IP traceback system is presented in Section III. In Section IV, we evaluate our approach through simulations. Finally, in Section V we present conclusions and some pointers to future work. II. R ELATED W ORK IP traceback systems can be classified as inter-domain systems and intra-domain systems. The main difference between these approaches is the way they are deployed throughout the network. The former is deployed at AS border routers, whereas the latter is deployed at routers within the same AS. In this section, we review related work on intra- and inter-domain IP traceback systems, and then we point out the particular contributions the work proposed in this paper brings to the field. 1 An Autonomous System is a collection of networks which are under the same administrative authority. Such collection may comprise different routing domains; for simplicity, however, we consider in this paper an AS as comprising a single routing domain, so the terms domain and AS are used interchangeably throughout the remainder of this paper.

A. Intra-domain IP traceback systems Savage et al. [5] proposed an IP traceback system based on Probabilistic Packet Marking (PPM). In this PPM-based system, packets are marked with a given probability when they are forwarded by routers; these marked packets carry information on their IP fragmentation fields about the routes taken by them. After the victim receives a reasonable number of packets, it might reconstruct the attack route. Another PPMbased system is proposed by Bellovin et al. [11]. In this system, for each selected packet, an ICMP message is sent to the same destination of the selected packet. This ICMP message carries information about the selected packet and the router that generated the message, including the next hop, previous hop, time stamp, and time to live (TTL). Such information is then used by the victim to reconstruct the attack route. The SPIE (Source Path Isolation Engine) system, presented by Snoeren et al. [6] is a log-based IP traceback system that stores digests of packets inside Bloom Filters [12] as packets are forwarded by routers. Bloom filters are spaceefficient probabilistic data structures based on hash functions that are typically used to test whether an element is a member of a set. A survey on the applicability of Bloom Filters in computer networks can be found in [13]. Contrary to PPMbased IP traceback systems, this system, based on the use of Bloom filters, can traceback a single IP packet. Laufer et al. [14] proposed another system for IP traceback based on Bloom filters. In this system, when packets cross a router, a mark is inserted into a structure called Generalized Bloom Filter (GBF) [15] which is conveyed in the IP header of each packet. This mark results from a hash of the IP address of the current router egress interface. Therefore, when a packet reaches its destination, the packet carries in the GBF the mark of all traversed routers. The victim initiates the traceback procedure by verifying which of its neighbor routers has its mark in the resulting GBF and then sends a reconstruction packet to such router. This procedure is repeated at each router until the reconstruction packet arrives at the router from where attacking packets are coming. Finally, to finish the traceback procedure, this router sends a message back to the victim with the route from where the attacking packets are coming. Similarly to SPIE, this system can also traceback a single IP packet. B. Inter-domain IP Traceback systems Durresi et al. [7] presented a new AS-level traceback system using a PPM technique. The information carried into the packets is the Autonomous System Number (ASN)—a unique number which identifies an AS—and is inserted by AS border routers. Nevertheless, PPM-based systems may be cheated by an attacker that inserts false positive paths relying on the probability of marking packets, which is directly related to the number of packets needed to reconstruct the path. To deal with this issue, Durresi et al. [7] introduced an authentication scheme based on symmetric key cryptography that should be used by all AS border routers. Korkmaz et

al. [16] presented a new approach called AS-SPT (AS-level Single Packet Traceback), which could operate in a partial deployment scenario. The authors basically defined the system architecture without proposing a new traceback mechanism to be used — they suggest SPIE [6] as a reasonable candidate given its popularity. Although the AS-SPT approach allows partial deployment, it requires previous knowledge of the topology of AS interconnections. In previous work [8] we proposed an IP traceback system which takes advantage of some characteristics of BGP (Border Gateway Protocol) [17] to build an AS-level overlay network for inter-domain IP traceback. In this work, we proposed the creation of a new Community Attribute [18] called IP Traceback Community comprising information about the presence of our traceback system on collaborating ASes. This indicates that these ASes could create and participate on the AS-level overlay network for IP traceback. IP packets carry information about the AS border routers from where packets are coming in a Generalized Bloom Filter (GBF), similar to the system proposed by Laufer et al. [14] for intra-domain IP traceback. In our AS-level overlay network approach, however, only those AS border routers taking part in the overlay network insert marks in the GBF of IP packets; the traceback procedure is performed hop-by-hop in the AS-level overlay network. This feature eliminates the requirement adopted by several previous approaches that the traceback system must be deployed in all routers of the monitored network. Furthermore, the system has a meaningful advantage when compared to other interdomain traceback systems since it does not require previous knowledge of the topology of AS interconnections while allowing traceback of a single IP packet, as well as partial and incremental deployment of the system. Building upon the knowledge obtained in previous works of ours for inter-domain IP traceback, we conceive the intradomain IP traceback system proposed in this paper. C. Contributions The deployment of inter-domain IP traceback systems is based on the fact that the AS border routers are the routers which actually forward packets through networks in the Internet from a “macroscopic” viewpoint. Thus, there is a higher probability of successfully tracebacking a (D)DoS attack (at the Internet level) if the traceback system is deployed on these routers. In fact, it rather suffices to identify some key points in the path through where attacking packets are being forwarded to allow efficient countermeasures to be taken in a distributed way in order to block the ongoing attack. However, the efficient deployment of an inter-domain IP traceback system at the AS level needs some delicate political and administrative decisions. For instance, there is a need for collaborative behavior from at least a reasonable number of Autonomous Systems’ administrators to deploy and use the traceback system. The problem is that the interaction between these administrators is a challenging task, as they commonly have interests that can be in opposition to each other, leading to a situation where they live in a tussle [19].

On the other hand, in an intra-domain IP traceback system we do not need this collaborative behavior from different administrative parties. At the intra-domain level only a few key administrators are involved with the decision of deploying the traceback system and they work sharing a common goal for the same administrative entity. Analyzing the intra-domain IP traceback systems proposed so far, we observe that none of them can effectively be adopted in a large-scale domain, like the ones of large ISPs and telecommunication operators. Some reasons that back up this remark include: (i) the need of purchasing new specialized devices; (ii) limited scalability; (iii) the increase on the network overhead—both on the intermediate routers and on the victim at the moment the traceback process takes place; (iv) requirement of authentication mechanisms; and (v) the need of previous knowledge about network topology. The intra-domain IP traceback system proposed in this paper provides the following characteristics when compared with previous work. First, the proposed intra-domain IP traceback system allows its partial and progressive deployment in the domain; this is based on the creation of a router-level overlay network to mark and traceback the routes taken by attacking packets. To establish and maintain the overlay network, we use the OSPF routing protocol and define a new Opaque LSA (Link State Advertisement) [20]—the IP Traceback Opaque LSA— for the system. This new Opaque LSA is responsible for disseminating the information about the routers that have the proposed traceback system deployed in them. Therefore, our system is capable of working at large scale domains, eliminating the requirement of being deployed in all routers of the monitored domain, a usual requirement in related work. Besides, the system can be partially and progressively deployed over the domain regardless of the topology, which is dynamically provided by OSPF. Second, in spite of the fact that the proposed system can be deployed partially in the domain, the operation of packet marking performed by the routers taking part of the overlay network still allows that just one attacking packet be used for the traceback process. More specifically, our proposed system allows the identification of the complete attacking route as seen by the overlay network; such a route comprises the set of all routers that have the system installed in the domain through which an attacking packet was forwarded to reach the victim. III. I NTRA - DOMAIN OVERLAY NETWORK FOR IP TRACEBACK In this section, we present the architecture of our intradomain IP traceback system and its mechanisms: (i) the use of the OSPF protocol to disseminate information about the proposed system; (ii) the overlay network to traceback attacking packets at the router level; (iii) the packet marking procedure; (iv) the reconstruction of the route(s) taken by attacking packets.

A. System architecture All routers inside an AS that are candidates to take part of the proposed intra-domain traceback system should be associated with the same OSPF domain. An example of an OSPF domain is presented in Figure 1. In this figure, each router represented by a double border box participates in the proposed IP traceback system, thus being capable of marking packets and, as a consequence, taking part of the overlay network built to traceback packets. Each one of these routers has an associated traceback agent (TBA). TBAs are in charge of signaling the process of marking packets— e.g. using management procedures through SNMP (Simple Network Management Protocol) or CLI (Command Line Interface) automation—and of tracebacking the route(s) taken by attacking packets. A TBA also participates in the OSPF message exchange, but in a passive way regarding the propagation of routes within the domain. The main purpose of this structure is to allow TBAs to have knowledge of the complete domain topology, thus allowing the construction of an intradomain overlay network for IP traceback, as we describe in Section III-C. A TBA could be associated to more than one router in the overlay network. In an extreme case, just one TBA could be working in the domain; such a case, however, constitutes a centralized approach causing the system to be more vulnerable to attacks and failures. Therefore, we recommend TBAs to be deployed in a distributed way. To achieve this, TBAs must exchange information concerning their associated routers among each other. This functionality is performed by the OSPF protocol, as described in Section III-B. B. Using OSPF Opaque LSAs OSPF routers periodically exchange information about the domain topology using advertisement messages called LSAs (Link State Advertisements). The proposed intra-domain IP traceback system uses a special type of LSA, called Opaque LSA, to exchange information about the traceback overlay network. Opaque LSAs have the goal to give more flexibility to the OSPF protocol and have been previously used with different purposes in the literature [22], [23], [24]. Opaque LSAs are of three different types and indicate how far the advertisement should be propagated within the domain: (i) type 9, which is not distributed to external routers in a local network; (ii) type 10, which is not distributed to routers outside of an OSPF area; (iii) type 11, which is distributed throughout the whole OSPF domain.2 In our IP traceback system, we propose the creation of a new Type-11 Opaque LSA, called IP Traceback Opaque LSA (IPT-LSA), which is generated only by TBAs. Each TBA advertises an IPT-LSA comprising information about which routers are associated to the TBA. This feature allows that, after the OPSF protocol converges, each TBA knows all other TBAs present in the domain, as well as all their associated 2 One exception is when stub areas are used within the OSPF domain, as discussed in Section V.

Figure 1.

Example of OSPF domain (adapted from Moy [21]).

routers, allowing each TBA to build an overlay network for intra-domain traceback, as detailed in Section III-C. We highlight that the distribution of IP Traceback Opaque LSAs does not rely on a legacy router having knowledge about their purpose, since OSPF routers simply broadcast Opaque LSAs. This feature enables the proposed intra-domain IP traceback system to be seamlessly and transparently deployed in an OSPF domain using the existing infrastructure.

Based on the overlay trees of its associated routers, a TBA builds a so-called overlay table, which indicates the neighbor routers, in the overlay network, of each router associated with the TBA. Using the example in Figures 3(a) and 3(b), the overlay table for router RT1 comprises routers RT3 and RT4, and the overlay table for router RT4 comprises routers RT1, RT3, RT7, and RT10. Figure 4 illustrates the complete overlay network for the example of Figure 1.

C. Overlay network for intra-domain IP traceback

D. Marking packets

After the OSPF protocol converges, each router has global knowledge of the domain network topology. At this moment, the OSPF process in each router runs the Dijkstra algorithm [25] to obtain the SPF (Shortest Path First) tree. The root of this tree is the router that runs the Dijkstra algorithm and each of its sub-trees represents the best path to reach a set of destinations in the domain. In Figures 2(a) and 2(b), we can see partial examples of SPF trees for routers RT1 and RT4 of Figure 1, respectively. Based on its SPF tree, an OSPF router builds the routing table that the router uses for forwarding packets inside the domain. Again, routers represented by a double border box in Figures 2(a) and 2(b) represent those routers which participate in the proposed intra-domain overlay network for IP traceback. To build the overlay network, each TBA in the domain executes the Dijkstra algorithm in order to compute, for each of its associated routers, a corresponding SPF tree. For each computed SPF tree, the TBA extracts a new tree, socalled overlay tree, which indicates the best path between the associated router and the other routers taking part in the overlay network. Based on the example of Figure 1, Figures 3(a) and 3(b) show the overlay tree for routers RT1 and RT4, respectively.

The process of marking packets adopted in the proposed intra-domain IP traceback system is similar to the one proposed in our previous work on the AS level [8]. In that work, packets were marked when they passed through an AS border router taking part in the traceback system. This packet marking is performed by the insertion of information related to the AS into the GBF present in the header of the packet. Basically, in the case of our previous inter-domain traceback system, the information inserted into the GBF is the result of a hash fuction between the Autonomous System Number (ASN) combined with the TTL of the packet at the moment that the packet passed through the router. This procedure was necessary in order to identify the correct sequence of ASes from where the packet passed through until reaching the destination. In the case of the intra-domain IP traceback system proposed in this paper, the information is replaced by the IP address of the egress interface of the router which forwarded the packet. At this point it is important to recall that only routers that take part in the intra-domain overlay network perform the operation of packet marking. Using Figure 1 as an example, if a packet is sent by a source host which is inside network N1 and takes the route composed of RT1, RT4, RT5, and RT7 to reach its destination inside network N6, only

(a) Router RT1. Figure 2.

(b) Router RT4. Example of SPF trees derived from the topology in Figure 1.

routers RT1, RT4, and RT7 will actually perform the packet marking. Concerning the possible deployment of the traceback system, it is important to consider that the operation of packet marking does not demand a high computation effort because it can be performed using only basic logical operations [14]. The size of the GBF filter to be adopted actually depends on a trade-off between the targeted maximum false-positive probability, the number of considered hash functions, and the expected number of elements to be represented in the filter (the interested reader may find the full analysis of this tradeoff in Laufer et al. [14]). For example, following this analysis and considering 16 hash functions (8 to set and 8 to reset bits in the GBF), a filter of 64 bits would have false positive probabilities of 0.09%, 0.5%, and 3%, after inserting 3, 5, and 8 entries in the filter, respectively. E. Traceback process on the overlay network The traceback process is started by a domain administrator or by a detection system installed therein. This traceback process may be seen as a reverse procedure compared with the packet marking process explained in Section III-D. The first step of the traceback process considers routers which are taking part of the overlay network and are closer to the

attacked network—these routers can be identified by checking the SPF trees stored by the TBAs. The process searches in the GBF marks for one of these routers trying to identify from which router the packet was forwarded. Therefore, the router that marked the packet is the first on the traceback route (the reverse route of the packet towards the attacker). The next steps of this process are similar to the first one, but using the overlay network structure stored by the TBAs in order to identify the next router on the traceback route. Using Figures 1 and 4 as an example, and in order to simplify our explanation, we consider: (i) an attacker pointing to a victim inside network N6; (ii) the traceback process using information of a single attacking packet; and (iii) each TBA in our traceback system being associated with just one router which is taking part in the intra-domain overlay network. Supposing that the attacking packet is forwarded by routers RT1, RT4, and RT7, the first step in the traceback process would be to identify router RT7 as the first router on the reverse path taken by the packet, since the GBF inside the attacking packet has a mark for RT7 and does not have a mark for router RT10 (the other router in the overlay network which is close to network N6). In the next step, the TBA of router RT7 searches in the GBF for marks belonging to RT3, RT4, or RT10, i.e. its neighbors in the overlay network (as also

(a) Router RT1. Figure 3.

(b) Router RT4.

Example of overlay trees derived from the topology in Figure 1.

illustrated in Figure 4). In this case, the checking is positive for RT4. Thus, the TBA of router RT7 sends a reconstruction path packet to the TBA associated with router RT4. This packet has the GBF of the attacking packet and a list of routers included in the reverse path taken by the attacking packet in order to prevent traceback loops. Likewise, the TBA associated with router RT4 repeats the process made by the TBA associated with router RT7 looking for marks belonging to routers RT1, RT3, or RT10. The TBA associated with RT4 finds the mark of router RT1. This TBA sends the reconstruction path packet to the TBA associated with router RT1, and so on. The traceback process finishes when a TBA verifies that there is no other mark in the GBF corresponding to its neighbors in the intradomain overlay network which are not already included in the reverse path of the attacking packet. This procedure is similar to the one presented in Castelucio et al. [8] for an inter-domain IP traceback system. IV. S YSTEM EVALUATION In this section, we investigate the accuracy and the performance of the proposed intra-domain IP traceback system using a simulation study. In this study, we consider two different strategies to deploy the system within the network domain: (i) strategic placement, where the most connected routers are chosen first to take part of the overlay network, and consequently to have the traceback system deployed first; (ii) random placement, where the system is deployed randomly through the routers of the network domain.

One of our goals in the performed simulation study is to compare the performance of the inter-domain IP traceback system previously proposed by Castelucio et al. [8] and the intra-domain IP traceback system proposed in this paper. In a topology at the level of Autonomous Systems, i.e. an interdomain topology, there is a clear tendency of new nodes to connect as the network grows to other nodes that are already highly connected—a feature also known as preferential attachment [26], [27]. This tendency helps to explain why in the Internet topology there is typically a few nodes highly connected whereas most nodes have only a few connections. These topologies are also known as scale-free. On the other hand, in an intra-domain topology, the placement of new nodes is determined regardless of the connectivity degree and is variable according to the particular needs of the network domain and its administrators. Another purpose of the simulation is to analyze the performance of partial and progressive deployment of the proposed system. In other words, we intend to evaluate the trade-off between the number of routers taking part in the overlay network on the network domain and the traceback accuracy. To do so, we observe the characteristics of the reverse path discovered by the proposed IP traceback system as we vary its deployment ratio throughout the network domain, considering the two strategies of placement. Simulation results present mean values with 99% confidence intervals with sizes of ±5.2% for the strategic placement and ±6.6% for the random placement strategy around the presented mean average value. A. Simulation setup

Figure 4.

Overlay network for the topology in Figure 1.

In our simulations, we use the topology generator Nem [28] to generate the adopted topologies and NS-2 (Network Simulator 2) [29] as the network simulator. In this paper, we present results for intra-domain topologies containing 50, 150, 250, and 350 routers, sizes that cover a large portion of typical, operational network domains. To get each sample, we simulate three different network topologies with twelve randomly-chosen sets of attacking sources sending attacking traffic towards one victim. The number of attackers corresponds to 10% of the network domain size.

B. Simulation results In Figure 5, we present the percentage of the discovered attacking path depending as a function of the amount of routers taking part in the overlay network on the network domain. Results show that using strategic placement we discover almost 90% of the intra-domain attacking reverse path with the system deployed on approximately 60% of the network routers. On the other hand, to achieve the same results using random placement, a traceback system should be deployed in almost 90% of the network routers. Relaxing the requirement of finding the complete attacking path, strategic placement allows the discovery, for instance of 60%, 70%, and 80% of the reverse attacking path in the network domain when only around 20%, 30%, and 40% of network routers take part of the overlay network, i.e. to have the traceback system deployed, respectively. This means that even if a relatively small number of network domain routers with the system deployed—given that they are strategically placed—it is possible to identify a large portion of the intradomain route(s) taken by the attacking packets. 100

80 70 60 50 40

20 10 0 0

10

20

30

40

50

60

70

80

90 80 70 60 50 40 50 routers (S) 150 routers (S) 250 routers (S) 350 routers (S) 50 routers (R) 150 routers (R) 250 routers (R) 350 routers (R)

30 20 10 0 0

10

20 30 40 50 60 70 80 Routers taking part of the overlay network (%)

90

100

Discovering the router directly connected to attackers.

where attacking packets are forwarded in the first place, around 80% and 100% of the routers in the network domain should take part of the intra-domain overlay network, respectively. In other words, random placement implies a linear relationship between system deployment and efficiency in the traceback. In Figure 7, the inter-domain IP traceback system proposed in Castelucio et al. [8] is compared with the intra-domain system proposed in the paper. We can observe that using strategic placement, in spite of intra-domain topologies not holding the same scale-free characteristics of inter-domain topologies, the performance of the different systems is not so different and just have a little more impact when 20% to 30% of network domain routers take part of the overlay network. In random placement this gap is smaller than in strategic placement, and the performance presented by both traceback systems is the same. The difference in performance shown for the analyzed systems basically derives from the intrinsic characteristics of the topologies they are designed to deal with.

50 routers (S) 150 routers (S) 250 routers (S) 350 routers (S) 50 routers (R) 150 routers (R) 250 routers (R) 350 routers (R)

30

100

Figure 6.

100 90 90

100

Routers taking part of the overlay network (%)

Figure 5. Efficiency in discovering the attacking path with strategic (S) and random (R) placements.

In Figure 6 we can observe that using strategic placement, to discover almost 100% of directly connected routers to attackers, i.e. the first router that forwards the attacking packets, it is necessary to have 70% of the network domain routers taking part of the overlay network. However, even if just 20% of the network domain routers take part of the network overlay, the IP traceback system still can point out around 80% of the routers from where attacking packets are forwarded in the first place. In contrast, to get similar results using random placement, i.e. to identify 80% and 100% of the routers from

Attacking path (% discovered)

Attacking path (% discovered)

90

First router that forward attacking packets (% discovered)

For the results comparing the inter-domain IP traceback system proposed in Castelucio et al. [8] and the intra-domain system presented here, we use the mean values of 300, 600, and 900 autonomous systems for the inter-domain system and the mean values of 50, 150, 250, and 350 routers for the intradomain system presented here.

80 70 60 50 40 30 20

Intra-domain (S) Inter-domain (S) Intra-domain (R) Inter-domain (R)

10 0 0

10

20

30

40

50

60

70

80

90

100

Routers taking part of the overlay network (%)

Figure 7. Inter-domain IP traceback system proposed in Castelucio et al. [8] vs. intra-domain IP traceback system proposed in this paper: Efficiency in discovering the attacking path.

First router that forward attacking packets (% discovered)

Figure 8 shows the comparison between the two IP traceback systems regarding the identification of routers directly connected to attackers. In this comparison, the results for strategic and random placement are pratically the same, without changes in the performance between the inter- and intradomain. 100 90 80 70 60 50 40 30 20

Intra-domain (S) Inter-domain (S) Intra-domain (R) Inter-domain (R)

10 0 0

10

20

30

40

50

60

70

80

90

100

Routers taking part of the overlay network (%)

Figure 8. Inter-domain IP traceback system proposed in Castelucio et al. [8] vs. intra-domain IP traceback system proposed in this paper: Routers directly connected to attackers.

V. C ONCLUSION AND O UTLOOK In this paper we propose an intra-domain IP traceback system that takes advantage of some characteristics of the OSPF protocol to build up an intra-domain overlay network to traceback attacking packets. Our intra-domain IP traceback system can be gradually and partially deployed in a network domain, thus eliminating the need for it to be deployed onto all routers of a network domain, a usual requirement in previous work. It can be deployed regardless of the network domain topology as well. These features guarantee to the system lower deployment costs than other intra-domain IP traceback systems. We evaluated our approach through simulations in order to assess two different placement methods and also to compare the current proposal for intra-domain IP traceback with our previous work [8]—an inter-domain IP traceback system. We intended to verify the behavior and the performance of both systems using topologies which present different characteristics. We also evaluated the trade-off between accuracy and the partial and progressive deployment of the proposed traceback system inside a network domain. Simulation results suggest that using strategic placement we have enough information to filter or block attacking packets in a distributed way and closer to the attacking source. Results show that with around 20% of network domain routers taking part of the intra-domain overlay network, i.e. routers with the traceback system deployed, it is possible to identify almost 80% of routers which make the first forwarding of attacking packets, i.e. routers which are directly connected to attackers.

With a similar rate the proposed system is capable of identify almost 60% of the reverse path taken by attacking packets, allowing distributed countermeasures to be taken against attackers is this path. On the other hand, deploying the proposed IP traceback system randomly inside a network domain does not bring so relevant results. However, typically only a small number of network domain administrators—with the same interests—are in charge of the decision of deploying the intra-domain IP traceback system. Therefore, the choice of which routers will be chosen to have the IP traceback system deployed first and, consequently, take part of the overlay network for IP traceback, relies on the dimension and the arrangement of routers inside the domain. As future work we intend to improve our proposal considering OSPF domains divided in stub areas. Actually, the adoption of type 11 Opaque LSAs by our approach allows the construction of an overlay network for IP traceback even if OSPF areas are used in the domain. The only exception is when the network domain has stub areas, which do not allow internal advertisements of this LSA type. The treatment of this specific case is part of our future work. Another direction for future work is to evaluate the proposed system in a testbed using some computers with the Linux operating system running an open source version of OSPF—named Quagga [30]—in order to achieve more practical and detailed results. We also intend to investigate the feasibility of integrating our intra-domain IP traceback system with the interdomain IP traceback system proposed in Castelucio et al. [8]. Our goal with this integration is to build an hierarchical IP traceback framework, where: firstly, the traceback may discover Autonomous Systems from where packets are sent and, secondly, the traceback may be performed inside these Autonomous System, increasing the chance of getting closer to the attacking sources and thereby performing more efficient filtering or blocking. ACKNOWLEDGEMENT This work is partially supported by MCT, CNPq, and FAPERJ. R EFERENCES [1] J. Mirkovic and P. Reiher, “A taxonomy of DDoS attack and DDoS defense mechanisms,” SIGCOMM Comput. Commun. Rev., vol. 34, no. 2, pp. 39–53, 2004. [2] A. Hussain, J. Heidemann, and C. Papadopoulos, “A framework for classifying denial of service attacks,” in SIGCOMM ’03: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications. New York, NY, USA: ACM Press, 2003, pp. 99–110. [3] D. Moore, C. Shannon, D. J. Brown, G. M. Voelker, and S. Savage, “Inferring internet denial-of-service activity,” ACM Trans. Comput. Syst., vol. 24, no. 2, pp. 115–139, 2006. [4] NIST, “Guide to Intrusion Detection and Prevention Systems (IDPS),” NIST- National Institute of Standards and Technology, Tech. Rep., 2007. [Online]. Available: http://csrc.nist.gov/publications/ nistpubs/800-94/SP800-94.pdf,visitadoemJaneirode2008

[5] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “Practical network support for IP traceback,” in Proceedings of the 2000 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM), Stockholm, Sweden, August 2000, pp. 295–306. [6] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio, B. Schwartz, S. T. Kent, and W. T. Strayer, “Single-packet IP traceback,” IEEE/ACM Trans. Netw., vol. 10, no. 6, pp. 721–734, December 2002. [7] A. Durresi, V. Paruchuri, L. Barolli, R. Kannan, and S. S. Iyengar, “Efficient and secure autonomous system based traceback,” Journal of Interconnection Networks, vol. 5, no. 2, pp. 151–164, 2004. [8] A. O. Castelucio, R. M. Salles, and A. Ziviani, “An AS-level overlay network for IP traceback,” IEEE Network, vol. 23, no. 1, pp. 36–41, January 2009. [9] CERT, “CERT Advisory CA-1996-21 TCP SYN flooding and IP spoofing attacks,” CERT- Computer Emergency Response Team, Tech. Rep., 1996. [Online]. Available: http://www.cert.org/advisories/ CA-1996-21.html,visitadoemMar\c{c}de2007 [10] ISS, “Distributed denial of service attack tools,” ISS- Internet Security Systems, Tech. Rep., 2000. [Online]. Available: http://www.iss.net/ documents/whitepapers/ddos.pdf,visitadoemMar\c{c}ode2007 [11] S. Bellovin, M. Leech, and T. Taylor, ICMP Traceback messages, IETF Internet Draft, February 2003. [12] B. Bloom, “Space/time tradeoffs in hash coding with allowable errors,” Communications of the ACM, vol. 13, no. 7, pp. 422–426, 1970. [13] A. Broder and M. Mitzenmacher, “Network applications of Bloom filters: A survey,” Internet Mathematics, vol. 1, no. 4, pp. 485–509, 2004. [14] R. P. Laufer, P. B. Velloso, D. de O. Cunha, I. M. Moraes, M. D. D. Bicudo, and O. C. M. B. Duarte, “A new IP traceback system against denial-of-service attacks,” in 12th International Conference on Telecommunications - ICT’2005, Capetown, South Africa, May 2005. [15] R. P. Laufer, P. B. Velloso, and O. C. M. B. Duarte, “Generalized bloom filters, gta-05-43,” COPPE/UFRJ, Tech. Rep., September 2005. [Online]. Available: http://www.cs.ucla.edu/∼rlaufer/publications/gbf.pdf [16] T. Korkmaz, C. Gong, K. Sarac, and S. Dykes, “Single packet IP traceback in AS-level partial deployment scenario,” International Journal of Security and Networks, vol. 2, no. 1/2, pp. 95–108, 2007. [17] Y. Rekhter and T. Li, “A border gateway protocol 4 (BGP-4),” RFC 1771, March 1995. [18] R. Chandra, P. Traina, and T. Li, BGP Communities Attribute, RFC 1997 (Proposed Standard), Internet Engineering Task Force. RFC 1997, Aug. 1996. [Online]. Available: http://www.ietf.org/rfc/rfc1997.txt [19] D. D. Clark, J. Wroclawski, K. R. Sollins, and R. Braden, “Tussle in cyberspace: Defining tomorrow’s Internet.” [20] R. Coltun, “The OSPF Opaque LSA Option,” RFC 2370 (Proposed Standard), Jul. 1998, obsoleted by RFC 5250, updated by RFC 3630. [Online]. Available: http://www.ietf.org/rfc/rfc2370.txt [21] J. Moy, OSPF version 2, RFC 2328, Internet Engineering Task Force. RFC 2328, 1998. [Online]. Available: http://www.ietf.org/rfc/rfc2328.txt [22] J. Moy, P. Pillay-Esnault, and A. Lindem, “Graceful OSPF Restart,” RFC 3623, Nov. 2003. [Online]. Available: http://www.ietf.org/rfc/rfc3623.txt [23] D. Katz, K. Kompella, and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2,” RFC 3630 (Proposed Standard), Sep. 2003, updated by RFC 4203. [Online]. Available: http: //www.ietf.org/rfc/rfc3630.txt [24] A. Lindem, N. Shen, J. Vasseur, R. Aggarwal, and S. Shaffer, “Extensions to OSPF for Advertising Optional Router Capabilities,” RFC 4970, Jul. 2007. [Online]. Available: http://www.ietf.org/rfc/ rfc4970.txt [25] E. W. Dijkstra, “A note on two problems in connexion with graphs,” Numerische Mathematik, vol. 1, pp. 269–271, 1959. [Online]. Available: http://jmvidal.cse.sc.edu/library/dijkstra59a.pdf [26] M. Faloutsos, P. Faloutsos, and C. Faloutsos, “On power-law relationships of the internet topology,” in SIGCOMM ’99: Proceedings of the conference on Applications, technologies, architectures, and protocols for computer communication. New York, NY, USA: ACM Press, 1999, pp. 251–262. [27] A. Medina, I. Matta, and J. Byers, “On the origin of power laws in internet topologies,” SIGCOMM Comput. Commun. Rev., vol. 30, no. 2, pp. 18–28, 2000. [28] D. Magoni, “Network manipulator. https://dpt-info.u-strasbg.fr/ magoni/nem,” 2002. [29] Network Simulator 2, “http://www.isi.edu/nsnam/ns,” 1995.

[30] Quagga Routing Suite, “http://www.quagga.net,” 2007.