1 Intrusion Monitoring of Link-State Routing Protocols Akshay Aggarwal Poornima Balasubramanyam Karl Levitt Computer Security Laboratory Department of Computer Science UCDavis

2 UCDavis SecLab MURI October 2002 Outline Part 1 Application to OSPF routing protocol Augmented OSPF Betweenness centrality computation Sample Topology Ongoing work

3 UCDavis SecLab MURI October 2002 Application to OSPF Routing OSPF NOW –At each router participating in OSPF Link-State Routing, the router employs the Dijkstra SPF Alg. and determines the shortest path tree originating at that router –Every link update received by router results in SPF algorithm execution –Employing a Fibonacci heap sort, algorithm executes in O(e+nlog(n)) time for e edges and n nodes

4 UCDavis SecLab MURI October 2002 OSPF AUGMENTED –Modified Definition of Betweenness Centrality: Centrality of a node is determined with respect to root router of SPF tree –Advantages Each router independently computes betweenness centrality indices of other routers in its routing network Each router can adopt independent response decisions based on this metric

5 UCDavis SecLab MURI October 2002 Betweenness Centrality Computation –Piggyback betweenness centrality computation within Dijkstra SPF algorithm at each router executing OSPF, for all routers in the routing network –Order of computational time requirements for determining this index remain UNCHANGED from existing Dijkstra computation, i.e., O(e+nlogn) at each router

6 UCDavis SecLab MURI October 2002 Augmented Dijkstra’s SPF Algorithm Given a graph with n nodes, find a shortest path tree from source node S S = Source node E = set of evaluated nodes for which shortest paths are known R = set of remaining nodes, Vi O = ordered list of paths C_B(V_i), i = 1,.., n /* Centrality index of all nodes, V_i, with respect to source node, S */ Step 1 C_B(V_i) = 0 E = {S} R = {V_1, V_2, …, V_(n-1)} O = {set of 1-edge paths starting from S} = {P_1, P_2, …, P_i} /* Each path has a cost corresponding to the link metric, and the paths are sorted by increasing metrics */ Step 2 if O = Ø or if metric(P_1) = ∞ /* All paths have been considered, or the first path has infinite metric */ mark all remaining nodes in R as unreachable Terminate algorithm contd

7 UCDavis SecLab MURI October 2002 Augmented Dijkstra’s SPF Algorithm – contd. Step 3 Let V = last node in P_1 If V Є E, go to Step 2 else P_1 is the shortest path to V Move V from R to E Increment C_B(V_i) for all V_i Є path P_1, where V_i ≠ S or V /* Centrality index is incremented for all nodes in the path between S and V */ Step 4 Build new set of paths by concatenating P_1 with each of the new edges from V Cost of the new paths = cost of P + link metric of new edge Insert new links in O, while sorting O Go to Step 2

8 UCDavis SecLab MURI October 2002 D E F G 2 A B C D E F G 2 A B C D E F G 2 A B C Initial Network Topology Topology after Link FE fails Topology after Link GF fails

9 UCDavis SecLab MURI October 2002 BCDEFG G E C B A D F 1. Initial SPF tree F G E C B A D 3. Link GF Failure F E G C B A D 2. Link FE Failure Nodes Initial Betweeness Centrality C_B of Node C_B after link FE failure C_B after link GF failure Change in C_B after 2 link updates Initial Degree Centrality C_D of Node Change in C_D after 2 link updates000-2 Node B has more control of the network Node F is more isolated

10 UCDavis SecLab MURI October 2002 Ongoing Work –Augmented current link-state algorithm (rtProtoLS) implemented in network simulator, ns-2, to incorporate centrality computations and perform comparative performance analysis on this augmented algorithm – Running simulations on ns-2 for realistic network scenarios to test validity of centrality indices for various cases of spatial and temporal as well as random and correlated link failures

11 UCDavis SecLab MURI October 2002 Outline Part 2 : Simulation Results Requirements of betweenness centrality calculation Simulator choice and reasons Test topologies and derived results Issues with simulation Conclusion

12 UCDavis SecLab MURI October 2002 Requirements of betweeness centrality calculation Need to maintain state of all the shortest paths from a given node. All hops along the path need to be maintained to calculate their betweenness An efficient method of calculation of the centrality piggybacking of calculation on shortest path calculation

13 UCDavis SecLab MURI October 2002 NS Reasons used –In-house expertise –An implementation of linkstate available – A popular simulator among networking researchers –Proof of concept prototype development Open to use of any suitable simulator for future work

14 UCDavis SecLab MURI October 2002 Topology 1 23 nodes All links are duplex Cost of links between node 0 – node 1 : 10 node 4 – node 5 : 10 node 2 – node 3 : variable All other links cost : 1

15 UCDavis SecLab MURI October 2002 Topology 1

16 UCDavis SecLab MURI October 2002 Results Topology 1

17 UCDavis SecLab MURI October 2002 Topology 2

18 UCDavis SecLab MURI October 2002 Results Topology 2

19 UCDavis SecLab MURI October 2002 Topolgy 3 24 nodes All links duplex Cost of links between node pairs (2,3) (3,5) (2,4) (4,5) (0,2) (13,16): 2 (9,19) : 6 (0,1) : variable All other links cost : 1

20 UCDavis SecLab MURI October 2002 Topology 3

21 UCDavis SecLab MURI October 2002 Results Topology 3

22 UCDavis SecLab MURI October 2002 Issues With NS Linkstate documentation non-existent Extensive use of STL makes linkstate inefficient State for the paths not maintained

23 UCDavis SecLab MURI October 2002 Other Issues Stable view of OSPF centrality is difficult to obtain : heuristic needed to determine the stability of the centrality Method of dealing with multiple equal shortest paths needed

24 UCDavis SecLab MURI October 2002 Conclusion Demonstrated that the betweenness centrality index is an important metric for security and traffic flow. Can be calculated by piggybacking onto the calculation of the OSPF shortest path.

25 UCDavis SecLab MURI October 2002 Contact Information Akshay Aggarwal Poornima Balasubramanyam