Intrusion Monitoring of Link-State Routing Protocols

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

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

3. Application to OSPF Routing • OSPF NOW • At each router participating in OSPF Link-State Routing, the routeremploys the Dijkstra SPF Alg. and determines the shortest path treeoriginating 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 edgesand n nodes UCDavis SecLab MURI October 2002

4. 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 UCDavis SecLab MURI October 2002

5. 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 UCDavis SecLab MURI October 2002

6. 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 UCDavis SecLab MURI October 2002

7. 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 UCDavis SecLab MURI October 2002

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

9. 1. Initial SPF tree A B G C A 3. Link GF Failure B G A B C F D G C F D E E 2. Link FE Failure F D E Node B has more control of the network Node F is more isolated UCDavis SecLab MURI October 2002

10. 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 UCDavis SecLab MURI October 2002

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

12. 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 centralitypiggybacking of calculation on shortest path calculation UCDavis SecLab MURI October 2002

13. 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 UCDavis SecLab MURI October 2002

14. 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 UCDavis SecLab MURI October 2002

15. Topology 1 UCDavis SecLab MURI October 2002

16. Results Topology 1 UCDavis SecLab MURI October 2002

17. Topology 2 UCDavis SecLab MURI October 2002

18. Results Topology 2 UCDavis SecLab MURI October 2002

19. 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 UCDavis SecLab MURI October 2002

20. Topology 3 UCDavis SecLab MURI October 2002

21. Results Topology 3 UCDavis SecLab MURI October 2002

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

23. 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 UCDavis SecLab MURI October 2002

24. 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. UCDavis SecLab MURI October 2002

25. Contact Information • Akshay Aggarwal aggarwal@cs.ucdavis.edu • Poornima Balasubramanyam poornima@cs.ucdavis.edu UCDavis SecLab MURI October 2002