Security-Aware Beacon Based Network Monitoring

Transcription

1 Security-Aware Beacon Based Network Monitoring Masahiro Sasaki, Liang Zhao, Hiroshi Nagamochi Graduate School of Informatics, Kyoto University, Kyoto, Japan {sasaki, liang, Abstract The active beacon based network monitoring tries to estimate the transfer delay of a link e by the difference of round-trip times from a beacon host to the two endpoints of e. For efficiency, we consider the problem of placing a minimum set of beacons to monitor all links of a given TCP/IP network e.g., the Internet. We propose an idea called L-beacon, i.e., a beacon can monitor only links within L hops. We show it generalizes previous studies for the so-called simple beacon (Kumar and Kaur 06) with L = 0 and the locally flexible beacon with L = 1 (Horton and Lopez-Ortiz 03). We observe that a larger L results in a smaller number of beacons but has higher security risk. Thus finding an L of good trade-off is important. For this, we studied a number of networks including real ISP networks (the Rocketfuel data) and smallworld scale-free networks, and found that, surprisingly enough, a small L = seems a good choice. Efficient algorithms for this NP-hard problem are also provided. I. INTRODUCTION Monitoring the status of a link is an important task in network management. Among many proposals, active beacon based monitoring is interesting due to its simplicity, in which a beacon (i.e. a host or a router equipped with the beacon function) checks the status of a link e by sending probe packets to the two endpoints of e and estimates the transfer delay of e by the difference of the two round-trip times. Denoting the round-trip time from some host (beacon) A to another H by rtt(a, H), it is natural to estimate the transfer time of a link e = (B, C) (using a beacon A) by 1 rrt(a, C) rrt(a, B). (1) 2 (It is if B or C or both are not reachable from A.) See an illustration in Fig. 1. rtt(a, B) TCP/IP network beacon A B C rtt(a, C) delay link e Fig. 1. Estimating the transfer delay of a link (B, C) from a beacon A. Notice that round-trip times can be obtained by the standard ICMP protocol (e.g., by the ping software), thus the above estimation is easy to implement. But clearly (1) is appropriate only if the two probes from A to B and C share the same A B or A C route. If the two probes did not share such a route, however, then in general (1) may be meaningless. For example, consider links in Fig. 2. For (B, C), two ping probes from the beacon A to B and to C may be routed in different ways, and in that case, estimation by (1) has little meaning. In fact, in Fig. 2, there is no way for A to know if link (B, C) is functional or not, i.e., A cannot monitor (B, C) correctly. beacon A ping C ping B C? Fig. 2. An illustration of the relationship between routing and Estimation (1). We see link (B, C) cannot be correctly estimated by beacon A. Thus given a beacon, there may exist links not suitable for it to monitor (by suitable we mean the estimation by (1) is appropriate for any routing). Therefore, given a network (e.g., the Internet), it is interesting to know how many beacons are necessary and where to place them in order to monitor all links. Of course this depends on how many links (how far) a beacon can monitor. The problem of finding a smallest set of beacons for a given network and a given type of beacons is called the beacon placement problem in the literature. Previously there were a few studies. Kumar and Kaur [7] studied the so-called simple beacon, which can monitor only adjacent links and bridge links, where a bridge is a link whose removal disconnects the network (notice bridges can be monitored by any one of beacons). Simple beacon is the easiest to implement ping is enough. On the other hand, Horton and Lopez-Ortiz [6] studied the so-called locally flexible beacon, which can further specify the first hop on the path to the target host. Clearly locally flexible beacon can monitor more links than simple beacon, but it is more complicated. The beacon placement problems for both these beacons are known to be NP-hard ([6], [7]). We generalize their ideas. Given an L 0, we propose the L-beacon whose monitorable area is limited to links within L hops, i.e., an L-beacon can specify the first at most L hops on the path to the target host. Therefore a simple beacon is (basically) a 0-beacon, and a locally flexible beacon is (basically) a 1-beacon. Moreover, we consider to limit to a B

2 small number of L is important for network security. Speaking more clearly, an L-beacon works in a way similar (but not equal, see the next Section) to the source routing protocols, which are considered unsafe for the Internet because (as there is no limitation on the hops) a cracker can investigate the topology of an internal network. However, if we (the routers) can limit the maximum number of hops to, e.g., L =, then a cracker can hardly do anything, because the limitation restricts his/her reachable area to hosts within L hops. The rest of this paper is organized as follows. We formulate the problem and show the NP-hardness in Section II. Then we give an exact and an approximate algorithms for this problem in Section III. The experimental results are discussed in Section IV, and finally we conclude in Section V. Related works. We note there is a related approach which, supposing at any time routes follow the shortest paths, requires much smaller number of beacons, see [1], [2], [8]. However, it is known that this assumption is too strong that it is not available on the Internet. Furthermore, this approach has to re-calculate the beacon set if the routing tree changes, which is said to happen every 20 minutes on the Internet. Therefore it is mainly of theoretical interest and its application is limited to small networks only. On the other hand, passive monitoring is another interesting approach, which does not send probe packets but collects data passing the beacon, see, e.g., [9] for example. This approach minimizes the affect to the network traffic, but obviously links with no beacon placed cannot be monitored. II. THE BEACON PLACEMENT PROBLEM FORMULATION In this section, we give a formulation of the problem and show it is NP-hard in general. We model networks as connected undirected graphs but directed or unconnected graphs are easy too. We assume the next packet forwarding rules. 1. A beacon-probe packet with the first k (k L) hops specified is routed exactly following the specification for k hops. It is discarded if there is no (direct) link between two successive hops. 2. A packet to an adjacent node is forwarded directly if there is no hop specification. 3. Otherwise it is forwarded following the default route. Notice the first rule is similar but not equal to source routing. It differs from the loose source routing as loose source routing is not required to follow specified hops exactly. On the other hand, the strict source routing follows the specification but it discards the packet after k hops. We consider that, by choosing an appropriate L, this novel routing can reduce the difficulty of network monitoring while avoiding similar security problems shared by the source routing protocols. In order to find an appropriate L, we must solve the problem of finding a smallest set of beacons that can monitor all links for a given network and an L. Let x i = 1 denote a node i is a beacon (otherwise x i = 0), and let B L (v) V denote the set of nodes reachable from a node v by at most L hops. Then we can formulate the problem as the next Integer Programming problem, where V and E denote the set of nodes (hosts, routers, etc) and the set of links, respectively. L-beacon placement problem: minimize subject to i V x i i B L (u) B L (v) x i 1, x i {0, 1}, i V. (u, v) E As shown in [7] and [6], this problem is NP-hard for L = 0 and L = 1. Similarly to [6], we can show the NP-hardness for any L 2 by reduction from the set cover problem (see []) which, given a base set U = {a 1, a 2,..., a n } and subsets S 1, S 2,..., S m U, asks to find a minimum T {S 1, S 2,..., S m } satisfying Si T S i = U. The reduction is as follows (see Fig. 3 for an illustration). For each S j, define a node n j. For each a i, define nodes u i0,..., u il 1, v i0,..., v il 1, link e i = (u i0, v i0 ) and links (u ik, u ik+1 ), (v ik, v ik+1 ), 0 k L 2. Connect n j to u il 1 and v il 1 if a i S j. Add 2L+1 nodes n 0, n m+1,..., n m+2l and 2L+1 links (n 0, n m+1 ), (n 0, n m+2l ), (n m+k, n m+k+1 ), 1 k 2L 1. Finally join n 0 to all n j with 1 j m. u u 11 u 1L 1 e 1 v v 11 v 1L 1 u 20 u 21 u 2L 1 e 2 v 20 v 21 v 2L 1 u n0 u n1 u nl 1 e n v n0 v n1 v nl 1 n 1 n 2 n 0 n m+1 n m+l n m n m+2l n m+l+1 Fig. 3. An illustration of the NP-hardness proof for L-beacon placement problem by reduction from the set cover problem. It is obvious that, to monitor all links belong to the simple cycle n 0 n m+1 n m+2l n 0, we must place (at least) one beacon at some node on the cycle. Without loss of generality, assume it is n 0. Then all links are monitorable except for (u i0, v i0 ), 1 i n. To monitor links (u i0, v i0 ) (corresponding to a i ), we must choose (at least) one node in some cycle u i0 u il 1 n j v il 1 v i0 u i0. Again, we may assume without loss of generality that it is n j (corresponding to S j ). Then it is easy to see that a feasible beacon set constructed in this way corresponds to a set cover, and vice versa. Thus the L-beacon placement problem is NP-hard for all L 0.

3 III. ALGORITHMS FOR THE L-BEACON PLACEMENT PROBLEM To solve the problem, we propose an exact and an approximate algorithm. First, let us show the exact algorithm, which is effective for small instances. In the previous section, we have formulated the problem as an Integer Programming problem, thus we can use the CPLEX software ( to solve this problem. Generally this is not a polynomial time algorithm but we can still use it to treat small networks. Moreover, we can use it to roughly estimate the next approximate algorithm. We need to calculate B L (v) for all v V. This can be done by a Breadth-First Search starting from v and stops by depth L. Before doing that, however, recall that bridge links can be monitored by any beacon, thus we can first determine and omit them to reduce the computation time (this preprocessing is used by the approximate algorithm too). Notice that there may exist two kinds of bridge links: the leaf bridges and nonleaf bridges. The removal of a leaf bridge results in an isolated node, whereas a non-leaf bridge does not (see Fig. 4 for an illustration). Clearly we can safely remove leaf bridges (and the isolated nodes), but not non-leaf bridges since otherwise the monitorable area of beacons may be broken. Both kinds of bridge links can be easily determined by a Depth-First Search Fig. 4. An illustration of two kinds of bridges. Links (8, 14) and (11, 1) are leaf bridges, whereas (1, 2), (1, 3) and (2, 4) are non-leaf bridges. So far we have shown the exact algorithm. On the other hand, since the beacon placement problem is NP-hard, we cannot expect any exact algorithm can treat large networks. Hence we also propose the following approximate algorithm, which greedily finds nodes that can monitor as many links as possible until all links are covered. Let A(u) denote the set of links adjoin node v. Algorithm Greedy Input: a connected undirected graph G = (V, E) with no leaf bridges, a non-leaf bridge set E 1, an L 0. Output: a set B of beacons. begin B = E = E E 1 Calculate B L (v) for all v V while E do Find a v V B maximizing E ( ) u B L (v) A(u) E = E u B L (v) A(u) 12 B = B {v} end end Finally we remark the lower bound on the optimal value, which is used to evaluate the solutions of the approximate algorithm. We use the Linear Programming relaxation of the problem, which relaxes the condition x i {0, 1} by x i [0, 1]. The optimal value of this relaxation is a lower bound of the optimal value of the original problem, and it can be found much faster using CPLEX. IV. EXPERIMENTAL RESULTS To evaluate the proposed algorithms and find a good L, we studied a number of networks including real ISP networks of the Rocketfuel data ( research/networking/rocketfuel/) and small-world scale-free networks generated by GTgraph-rmat ( edu/ kamesh/gtgraph/, see also [3]). All were tested on a PC with Intel Xeon 2.33GHz CPU, 2GB RAM and 64bit Linux CentOS. For CPLEX, we used the.2 version. The timeout for calculation was set to 1200 seconds, i.e., 20 minutes. First, let us see the data of Rocketfuel. We list the instances with their numbers of nodes in the next table. We note that not all of them are connected. TABLE I DETAILS OF THE ROCKETFUEL INSTANCES ANS Name #nodes Telstra (Australia) Sprintlink (US) EBONE (Europe) Verio (US) Tiscali (Europe) Level 3 (US) Exodus (US) VSNL (India) Abovenet (US) AT&T (US) Even for the largest instance, our algorithms solved it within a few seconds. Thus the running time is omitted here. The experimental results are listed in Table II, Table III and Fig.. TABLE II RESULTS FOR THE ROCKETFUEL INSTANCES, WHERE L = 0 ANS #nodes Optimal #beacons #beacons by Greedy Table II compares the obtained values of the numbers of beacons by the exact algorithm and the greedy algorithm. We

4 note that the previous study [7] used the same data but they could give only a greedy approximate algorithm. Thus we have obtained the optimal solutions for the first time. Notice our greedy algorithm performs fairly good. Since the numbers of nodes are different among the Rocketfuel instances, we use the percentages of #beacons/#nodes to evaluate the effectiveness of L-beacons. First, Table III shows the maximum (max), the minimum (min) and the average (avg) of the ratios in %. Percentage of beacons (0 * #beacons / #nodes) TABLE III #BEACONS/#NODES RATIOS (IN %) FOR THE ROCKETFUEL DATA L max min avg Fig. shows the detailed ratios for all L and all instances ANS 1221 ANS 1239 ANS 17 ANS 2914 ANS 327 ANS 336 ANS 3967 ANS 47 ANS 6461 ANS L Fig.. All #beacons/#nodes ratios for the Rocketfuel data. From these results for the Rocketfuel data, we can see that L 2 are not suitable for the link monitoring task. They are easier to implement and more secure, but they require a lot of beacons, e.g., L = 2 asks an average of 1.3% hosts to act as beacons. On the other hand, it is easy to see that L = seems a good choice. This can further be confirmed by the next experiment. That is, since the Rocketfuel data contain only small or medium size networks, we tried huge, connected, small-world and scale-free instances generated by GTgraph, which are considered as good models for the Internet. First we tested our exact algorithm. This time it can solve instances with at most 00 nodes, see the next table (we remark that, for the networks of Rocketfuel data, the unconnectedness of them greatly reduced the computation complexity. For GTgraph data, however, 00 nodes seems a barrier for the exact algorithm.). Notice the values for L are omitted because an optimal solution has been found for L = 4. Again, we can see the greedy algorithm works well. TABLE IV RESULTS FOR A 00-NODE GTGRAPH-GENERATED NETWORK Exact algorithm Greedy algorithm L optimal #beacons time (s) #beacons time (s) Since the exact algorithm cannot solve larger instances but we still want to estimate our greedy algorithm, we compare it with the lower bound (see the previous section for the method) of the optimal value. This time we can solve networks with about 000 nodes, see the next table. Again, the values for L 7 are omitted and we can see our greedy algorithm is fast and is quite accurate. TABLE V RESULTS FOR A 000-NODE GTGRAPH-GENERATED NETWORK L Lower bound of #beacons time (s) Greedy time (s) Finally we studied huge instances with 4,, 6 and 7 nodes. For these instances, the lower bound calculation algorithm did not work (timeout), hence we show only the results of the greedy algorithm. The next figure shows the results calculated within 20 minutes. We also calculated the result for 6 nodes and L = 4, (with longer running time). The average ratios of #beacons/#nodes are 27.8%, 6.7% and 1.64% for L = 0, 1, 2 respectively, whereas it is 0.0% for L =. Again, we can see that L 2 result in a lot of beacons, whereas L = can get a good trade-off. Percentage of beacons (0 * #beacons / #nodes) nodes 0000 nodes 1e+06 nodes 1e+07 nodes L Fig. 6. Results for instances with 000 and more nodes.

5 V. CONCLUSION In this paper, we proposed the idea of L-beacon to monitor links with consideration of network security. This generalizes previous studies on L = 0, 1. We gave an exact and an approximate algorithms to solve the NP-hard L-beacon placement problem, and experimental results on real ISP networks and small-world, scale-free networks show they work well. We note that a larger L can reduce the number of necessary beacons but with higher security risk. From our experiments, we found L = could efficiently reduce the number of beacons while keeping the network secure. ACKNOWLEDGMENT This work is partially supported by the Ministry of Education, Culture, Sports, Science and Technology of Japan. REFERENCES [1] Y. Bejerano, R. Rastogi. Robust Monitoring of Link Delays and Faults in IP Networks, IEEE/ACM Trans. on Networking, vol. 14, no. (2006), [2] Y. Breitbart, F. Dragan, H. Gobjuka. Effective Network Monitoring, in Proc. ICCCN 04 (2004). [3] D. Chakrabarti, Y. Zhan, C. Faloutsos. R-MAT: A Recursive Model for Graph Mining, in Proc. SIAM Intl. Conf. on Data Mining, [4] CPLEX, [] M. R. Garey, D. S. Johnson. Computers and Intractability: A guide to the theory of NP-completeness. W. H. Freeman, San Francisco (1999). [6] J. D. Horton, A. Lopez-Ortiz. On the number of distributed measurement points for network tomography, in Proc. ACM ICM 03 (2003), [7] R. Kumar, J. Kaur. Practical Beacon Placement for Link Monitoring Using Network Tomography, in Proc. IEEE JSAC - SAMPLING 2006 (2006). [8] J. Moulierac, M. Molnar. Active Monitoring of Link Delays in Case of Asymmetric Routes, in Proc. IEEE ICNICONSMCL 06 (2006), 1 6. [9] K. Suha, Y. Guob, J. Kurosea, D. Towsley. Locating network monitors: Complexity, heuristics, and coverage, Computer Communications 29 (2006),