intrusion monitoring of link-state routing protocols

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

Upload: merritt-shields

Post on 04-Jan-2016

41 views

Category:

Documents


0 download

DESCRIPTION

Intrusion Monitoring of Link-State Routing Protocols. Akshay Aggarwal Poornima Balasubramanyam Karl Levitt Computer Security Laboratory Department of Computer Science UCDavis. Outline Part 1. Application to OSPF routing protocol Augmented OSPF Betweenness centrality computation - PowerPoint PPT Presentation

TRANSCRIPT

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 200215

Topology 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 200217

Topology 2

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 200220

Topology 3

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

[email protected]

• Poornima Balasubramanyam

[email protected]