University of California, San Diego Fatih : Detecting and Isolating Malicious Routers Alper T Mizrak, Yu-Chung Cheng, Prof. Keith Marzullo, Prof. Stefan Savage

Alper Mizrak, DSN05 2 Introduction Routers occupy a key role in modern packet switched data networks Packets need to be forwarded hop-by-hop between routers Routers can be compromised through [Ao03,Houle01,Labovitz01] One network operator found 5000 compromised routers[Thomas03] If a router is compromised, an adversary can Disrupt the forwarding process Deny service Implement ongoing network surveillance Provide a man-in-the-middle attack

Alper Mizrak, DSN05 3 Introduction Two threats posed by a compromised router: Control plane: By means of the routing protocol E.g. announce false route updates Has received the lions share of the attention [Perlman88,Subramanian04,Kent00,Hu02,Smith96,Cheung97, Goodrich01] Data plane: By means of the forwarding decisions based on the routing tables E.g. alter, misroute, drop, reorder, delay or fabricate data packets Has received comparatively little attention Our focus is entirely on this problem

Alper Mizrak, DSN05 4 Goal Fault tolerant forwarding in the face of malicious routers Routers normally make predictable decisions … so this problem is a candidate for anomaly-based intrusion detection Practical defenses against compromised routers on data plane Detecting anomalous forwarding behaviors of compromised routers can be identified by correct routers when it deviates from exhibiting expected forwarding behavior Bypassing the suspicious entities

Alper Mizrak, DSN05 5 Hi Mom, I need MONEY. Love, Alper Basic Idea Mail communication between me and my mom SENT 3 Keep Alive 1 Money Request RECEIVED 2 Keep Alive 2 Money Check RECEIVED 3 Keep Alive 1 Money Request SENT 2 Keep Alive 2 Money Check

Alper Mizrak, DSN05 6 Basic Idea Later on… SENT 2 Keep Alive 2 Money Request RECEIVED 1 Keep Alive 1 Money Check RECEIVED 1 Keep Alive 1 Money Request SENT 2 Keep Alive 2 Money Check

Alper Mizrak, DSN05 7 Overview System Model Network Model Threat Model Protocol Current Status Conclusion

Alper Mizrak, DSN05 8 Network Model Assumptions The routing protocol provides each node with a global view of the topology: Distributed link-state routing protocol: OSPF or IS-IS Synchronous system: Link-state protocols operate by periodically Key distribution between pairs of nearby routers This overall model is consistent with the typical construction Large enterprise IP networks The internal structure of single ISP backbone networks

Alper Mizrak, DSN05 9 Definitions Path: a finite sequence of adjacent routers: X-path segment: a sequence of x routers that is a subsequence of a path : 3-path segment A router is faulty If it introduces discrepancy into the traffic If it does not participate in the proposed protocol

Alper Mizrak, DSN05 10 Threat Model Cant depend on faulty routers to detect faulty routers bad(k): Impose an upper bound on the number of adjacent faulty routers in any path bad(2): there can be no more than 2 adjacent faulty routers in any path st bad(2), s source, t sink

Alper Mizrak, DSN05 11 Threat Model Very few end hosts have multiple paths to their network infrastructure The fate of individual hosts and of the terminal router are directly intertwined The routers at the source and sink of a flow are not faulty with respect to that flow's path st bad(2), s source, t sink.

Alper Mizrak, DSN05 12 Overview System Model Protocol Traffic validation Distributed detection Specification An Example Protocol: k+2 Response Current Status Conclusion

Alper Mizrak, DSN05 13 Traffic Validation Way to tell whether traffic is disrupted en route Represent TV as a predicate TV(, info ri,, info rj, ) is a path segment whose traffic is to be validated between r i and r j both r i and r j are in

Alper Mizrak, DSN05 14 Traffic Validation Way to tell whether traffic is disrupted en route Represent TV as a predicate TV(, info ri,, info rj, ) info r, is some abstract description of the traffic router r forwarded to be routed along over some time interval

Alper Mizrak, DSN05 15 Traffic Validation Way to tell whether traffic is disrupted en route Represent TV as a predicate TV(, info ri,, info rj, ) If routers r i and r j are not faulty, then TV(, info ri,, info rj, ) evaluates to FALSE iff contains a router that was faulty in during

Alper Mizrak, DSN05 16 Traffic Summary Information How to represent info r, concisely? The most precise description of traffic An exact copy of that traffic Many characteristics of the traffic can be summarized far more concisely: Conservation of flow a b info a, 600 info b, packets are lost Threat model: Drop, misroute

Alper Mizrak, DSN05 17 Traffic Summary Information How to represent info r, concisely? The most precise description of traffic An exact copy of that traffic Many characteristics of the traffic can be summarized far more concisely: Conservation of content a b info a, {f 1, f 2, f 3, f 4 } info b, {f 1, f 3, f 4 } f 2 is lost Threat model: Drop, misroute + Modify, fabricate

Alper Mizrak, DSN05 18 Initial Problem Specification A perfect failure detector (FD) would implement the following two properties: Accuracy: An FD is Accurate if, whenever a correct router suspects (r, ) then r was faulty during Completeness: An FD is Complete if, whenever a router r is faulty at some time t then all correct routers eventually suspect (r, ) for some containing t

Alper Mizrak, DSN05 19 Challenge Implement the FD via Traffic Validation: By collecting traffic information from different points in the network Consider Any other router than b and c Can not distinguish between the case of b being faulty and of c being faulty Can only infer that at least one of b and c is faulty sab d c info, : ?

Alper Mizrak, DSN05 20 Weaken the Specification Detect suspicious path segments, not individual routers An FD returns a pair (, ) where is a path segment: α -Accuracy: An FD is α -Accurate if, whenever a correct router suspects (, ) then | | α and some router r was faulty in during α -Completeness: An FD is α -Complete if, whenever a router r is faulty at some time t then all correct routers eventually suspect (, ) for some path segment : | | α such that r was faulty in at t, and for some interval containing t

Alper Mizrak, DSN05 21 An Example Protocol: k+2 A router r has a set of path segments P r that it monitors. P r contains all the path segments have r at one end whose length is at most k+2 k is the maximum number of adjacent faulty routers along a path for each path segment in P r : while (true) { synchronize with router r' at other end of ; collect info r, about for an agreed-upon interval ; exchange [info r, ] r and [info r, ] r with r through ; if TV(, info r,, info r, ) = FALSE then suspect ; reliable broadcast (, ); }

Alper Mizrak, DSN05 22 Properties of Protocol k+2 k+2 is (k 2)-Accurate k+2 is (k 2)-Complete If r is faulty at some time t, then a path segment : r r introduce discrepancy into the traffic through during containing t Only and -the first and last routers of - are correct 3 | | k 2 and monitor and apply the k+2 for : Compute TV (, info,, info, ) to be false Suspect, disseminate this information to the all other correct routers

Alper Mizrak, DSN05 23 Overhead of Protocol k+2 This algorithm has reasonable overhead For each forwarded packet compute a fingerprint Each router r must synchronize and authenticate with the other end of each in P r The size of P r dominates the overhead For Sprintlink network [Rocketfuel] of 315 routers and 972 links: bad(1): a router monitors 35 path segments on average bad(2): a router monitors 110 path segments on average Dissemination of the suspected path segments can be integrated into the link state flooding mechanism

Alper Mizrak, DSN05 24 Response What happens as a result of a detection? Need some countermeasure protocol Inform the administrator Immediate action: Bypass the suspicious entities Ideally would be part of the link state protocol We have a version of Dijkstra's SPF that can exclude suspected x path segments ab c d is suspected

Alper Mizrak, DSN05 25 Overview System Model Protocol Current Status Prototype: Fatih Experience Current Work Conclusion

Alper Mizrak, DSN05 26 Prototype: Fatih We have implemented a prototype system, called Fatih. Runs in user-level on Linux 2.4-based router platform Cooperating with Zebra OSPF implementation.

Alper Mizrak, DSN05 27 Experiences The behavior of Fatih using an emulated network environment Topology based on the Abilene network Represent each PoP as a single router Each router is in turn emulated by a User-Mode Linux Host system: 2.6Ghz Pentium4 server with 1GB memory

Alper Mizrak, DSN05 28 Experiences

Alper Mizrak, DSN05 29 Current work: Traffic Validation Accuracy vs. performance In an idealized network, TV checks info ri, = info rj, False positives Real networks occasionally Lose packets due to congestion Corrupt packets due to interface errors False negatives Subtle attacker Preventing TCP handshake Degrading TCP performance

Alper Mizrak, DSN05 30 Conclusion Main contribution Formal specification Distributed detection algorithm Counterpart issues Traffic validation Routing the traffic around suspicious path segments It is possible To secure networks against attacks on data plane in a practical manner To provide fault tolerant forwarding in the face of malicious routers

Alper Mizrak, DSN05 31 The end Thank you…