1 Intrusion Monitoring of Link-State Routing Protocols Akshay Aggarwal Poornima Balasubramanyam Karl...
-
date post
21-Dec-2015 -
Category
Documents
-
view
213 -
download
0
Transcript of 1 Intrusion Monitoring of Link-State Routing Protocols Akshay Aggarwal Poornima Balasubramanyam Karl...
1
Intrusion Monitoring of Link-StateRouting Protocols
Akshay Aggarwal
Poornima Balasubramanyam
Karl Levitt
Computer Security Laboratory
Department of Computer Science
UCDavis
UCDavis SecLab MURI October 20022
Outline Part 1
• Application to OSPF routing protocol• Augmented OSPF• Betweenness centrality computation• Sample Topology• Ongoing work
UCDavis SecLab MURI October 20023
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
UCDavis SecLab MURI October 20024
• 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 20025
• 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 20026
Augmented Dijkstra’s SPF Algorithm
Given a graph with n nodes, find a shortest path tree from source node SS = Source nodeE = set of evaluated nodes for which shortest paths are knownR = set of remaining nodes, ViO = ordered list of pathsC_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 20027
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 20028
D
EFG 2
A B C2 43
2
2
1 3 6
D
EFG 2
A B C2 43
2
2
1 3 6
D
EFG 2
A B C2 43
2
2
1 3 6
Initial Network Topology
Topology after Link FE fails
Topology after Link GF fails
UCDavis SecLab MURI October 20029
B C D E F G
1 0 0 1 2 3
3 2 1 0 0 1
4 2 1 0 0 0
+3 +2 +1 -1 -2 -3
G
EC
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 3 3 2 3 3 2
Change in C_D after 2 link updates 0 0 0 -1 -2 -1
Node B has more control of the network Node F is more isolated
UCDavis SecLab MURI October 200210
• 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 200211
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 200212
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 200213
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 200214
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 200216
Results Topology 1
View of Centrality from node 11
0
2
4
6
8
10
12
14
1 2 3 4 5 6 7 8 9 10 11 12
Cost of Link b/w node 3 and node 2
Cen
tra
lity
Node 1Node 3
UCDavis SecLab MURI October 200218
Results Topology 2
Centrality of Node 3
0
2
4
6
8
10
12
14
1 2 3 4 5 6 7 8 9 10
cost of links from node 3
cent
ralit
y
node 11
UCDavis SecLab MURI October 200219
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 200221
Results Topology 3
Centrality of Node 7 from Node 14 and 17 when link 0-1 changes cost
0
2
4
6
8
1 2 3 4 5 6 7 8 9
cost of link between nodes 0-1
cent
ralit
y no
de 7
Node 14Node 17
UCDavis SecLab MURI October 200222
Issues With NS
• Linkstate documentation non-existent• Extensive use of STL makes linkstate
inefficient• State for the paths not maintained
UCDavis SecLab MURI October 200223
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 200224
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 200225
Contact Information
• Akshay Aggarwal
• Poornima Balasubramanyam