A Light-Weight Distributed Scheme for Detecting IP Prefix Hijacks in Real-Time Lusheng Ji†, Joint work with Changxi Zheng‡, Dan Pei†, Jia Wang†, Paul Francis‡ † AT&T Labs - Research ‡ Cornell University

Outline Background Algorithms and Justifications Evaluation Conclusion This is the outline of this presentation. I will try to focus more on conveying how the ideas were developed, not the detailed numbers, those are what the published paper is for. for which if there are questions, you are welcome to stop me in the hall way if you can find me. Or just shoot us emails.

Prefix Hijacking Exploits BGP Authentication Weakness Distributed Scheme for Detecting IP Prefix Hijacking Background ╛ Prefix Hijacking Exploits BGP Authentication Weakness BGP - the de facto inter-domain routing protocol Path vector protocol Lacking “authenticity” checking capability Prefix hijacking: routers falsely advertise routes We are so graceful that our talk is the second in the session because the previous presenter has done a superb job describing what IP prefix hijacking is and convincing us that it is a real thread. We can pretty much just skip these background topics. The root cause, BGP lacks authentication.

Types of Prefix Hijacking Distributed Scheme for Detecting IP Prefix Hijacking Background ╛ Types of Prefix Hijacking Blackholing Hijacker drops packets Imposture Hijacker pretends to be the victim Interception Hijacker forwards packets to victim We categorize prefix hijackings into three types.

Current Approaches to Prefix Hijacking Prevention and Detection Distributed Scheme for Detecting IP Prefix Hijacking Background ╛ Current Approaches to Prefix Hijacking Prevention and Detection Prevention Software/configuration changes Public Key Infrastructure or other authentication mechanisms Deployment hurdles Detection BGP update message and routing table inspection and anomaly/signature detection Limited vantage point locations Difficult to be “real-time” Often requiring privileged access High false positive rates In current approaches, for prevention, there have been many proposals adding various security functions to BGP. But they require software and/or configuration changes, maybe also requiring PKI, which add deployment hurdles. For detection, most approaches inspect BGP updates for anomalies or signatures. But there are several issues here. First it is not easy to get real time BGP feeds. There are very few public accessible taps for receiving BGP information. They only provide the view of Internet from they view points. The BGP information provided generally is not so real time either. It is possible for major network operators to have better access to BGP information when they want to and from where they want to. But not normal researcher. Finally, the published approaches generally have false positive ratios higher than what network operators want to deal with.

New Approach: Data Plane Monitoring Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ New Approach: Data Plane Monitoring Benefits Can have multiple strategically placed vantage points Gotta have multiple At good locations Distributed work load Distributed traffic load Potential of extending to overlay detection architecture Robustness Scalability Easily deployable, and anybody can do it. We started from saying hmm, maybe this can be done with a different approach, data plane monitoring. Ultimately, the hijacker wants to manipulate data paths. We should be able to find odd situations that are results of hijacking. At the same time, the advantages are very appealing. Firstly we can have multiple vantage points much easier. Gotta have multiple of them. Why? If an attack affects half of the Internet and your vantage point is on the other half, good luck detecting that. These vantage points should be placed at good locations too, diversified. And both work load and monitoring traffic can be distributed. Potentially this approach may lead to overlay detection architecture which is better in robustness and scalability. Mostly, this approach no longer depends on real-time BGP route updates. If this works, which I hope you will be convinced so by the end of this talk, this approach really opens this problem domain up to a much wider researcher community. Oh and one piece of advice. If you do decide to take on this subject, that is great. If you want to have a debate with you colleague on this subject, in public, do not do not do it on an airplane or in an airport. We … well lets just say that we learned it the hard way.

Monitoring Prefix Network Location Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Monitoring Prefix Network Location The First observation If a prefix is hijacked, the paths observed from certain vantage points to the prefix would likely exhibit significant changes. Let’s start from monitoring the vantage point-to- target prefix paths What to measure The first observation, or more like intuition, is that networks do not usually move physically (well lets forget about the NEMO group of IETF for a moment). Subsequently, neither do IP prefixes. The opposite, if we discover that a prefix has moved topologically, chances are something odd has happened, and possibly it is due to hijacking. This is our start point. Then the next question is, what to measure, what “odd situation” to look for? Fortunately or unfortunately, there are not that many options. Delay, distance, either AS path length or hop count, and traceroute results. We decide to stay away from full path monitoring as much as possible. Why? Overhead. Probing overhead is in the order of n^2 with n being path length.

End-to-end Network Distance Measurement Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ End-to-end Network Distance Measurement End-to-end measurements Easy to obtain Low overhead Take one: end-to-end delay Information rich Not a good measurement target Take two: hop count Relatively stable Seems promising

Measurement Setup Monitors (measurement sources) Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Measurement Setup Monitors (measurement sources) 43 Planetlab nodes (25 ASes) Target prefixes (measurement destinations) Identified from RouteView and RIPE BGP tables 242 MOASes 125 SOASes 1 full month of data One hop count measurement for each path every 12 minutes So we did some experiments verifying that hop count is a good measurement candidate. The prefixes are chosen from routeView data base. Multi-origin ASes, oh these are juicy all kinds of problems, get as many as possible. Then Single Origin ASes, as many as we can handle, picked 125 of them.

Hop Count Stability and Change Detection Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Hop Count Stability and Change Detection Time Series Analysis Short-term moving average differs significantly from long-term moving average About 90% of the paths have hop count standard deviations within 20% of their averages. If we widen the window a little, about 98% of the paths have a hop count standard deviation within 20% of the average. A little worse than we originally expected but still not too bad. To detect changes, a very simple time series analysis technique can be used. Hop count relative variance

Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ … But … Detection only based on hop count change may result in large false-positive ratios Hop count is not that stable How to quantify “significant” Other reasons for “significant” hop count changes MOAS changing entry/exit point Traffic engineering Natural/human disasters causing large Internet topology changes Mis-configurations However, we felt not very satisfied. Why? We may end up with too many false positives, beyond what the operators wishes, no, I mean can, process. Here are the reasons. First hop count is not that stable. Then the subsequent question is how do we quantify a change being “dramatic” or “significant”? Also our time series analysis is really a very simple method, shall we keep pounding on the statistics? But any statistical change detection methods assume that there exist some underlying patterns, only then they work to detect any departures from these patterns. What if the patterns change over time too? This becomes really like what happens when you go to those financial advisors. They will always tell you their models are great, show you huge returns, then after you hand in your fee payment, they would tell you “past performance is no guarantee for future returns”. Why? Patterns change. Their models are built based on past data and work for past patterns. When the underlying pattern changes, such models often fail. Or is there something deeper? Are all “dramatic” changes really caused by hijacking? Hmm .. Lets see, that Taiwan straight earthquake couple of years ago changed global Internet topology quite a bit. Also when you think about it, hijacking or not, sometimes it really depends on who you are and who it is done to. The same BGP operation may sometimes be called hijacking, sometimes mis-configuration, or sometimes even “policy”….. How to distinguish hijacking from these “legitimate” changes?

Inspiration: Stuck in Traffic Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Inspiration: Stuck in Traffic ! Then one day, inspiration for something totally new came to us. This is a google map, which shows where my home is, where my workplace is, and every day how I drive to work. There is also a restaurant, err, okay okay it is a bar, that is very close to my work place. So as reasonable as I am, I would drive the same route to this bar as to work. Very normal, right? One day, there was a big accident on my usual route and I had to be detoured. Then when I was about at …here… something hit me: you know, this accident affects my route the same way no matter I go to work or go to that bar. This is because one I am a rational driver doing mostly shortest distance driving not policy based driving… well at least not when my wife is not sitting in the passenger seat, two these two places are close to each other, and three the accident is not personal to either my work place or that bar. That was our ah ha moment. Thank you Mr. Adams. That is, Mr. Samuel Adams of Boston…..

Path Disagreement Reference point Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Path Disagreement You see, this would be the equivalent on the Internet. We pick a reference point that is very close to the victim prefix. Normally my path to the prefix should be pretty much the same as the path to this reference point. If somewhere along the paths on the Internet something bad has happened, fine, both paths will zigzag pretty much the same way again. However, if a hijacker attacks the prefix, this is targeted, personal. Then only the path to victim prefix is changed, not the path to that reference point. Reference point As close to the target prefix as possible but outside of the target prefix AS

Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Are path to a network and path to the reference point of the network similar? Experiments on Planet-lab L1: longer path (i.e. path to a destination network). L2: shorter path (i.e. path to the reference point). Compute the “similarity” between L1 and L2: L1’: the sub-path of L1 that starts from the same origin (source), but with length of |L2|. HD: Hamming Distance. S: path similarity. Now lets see if the path to prefix and path to its reference point are really similar, or agree. Here we define the “similarity of two paths are the following.

Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Measurement Setup Use the same set of monitors and target prefixes as before One reference point for each monitor-to-target prefix path Run a pair of traceroute probes every 12 minutes Traceroute from monitor to target prefix Traceroute from monitor to the reference point of the target prefix One week of data Convert hop by hop paths to AS paths “Holes” in traceroute results IP to AS mapping

Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ AS Path Similarity For about 80% of the prefixes, the similarity between path to the prefix and path to their reference points are more than 80% similar. Another 80/20 rule? I think so… Well, that discovery aside. We now have two detection algorithms, reasonably verified. Now lets see if we put them together and what results we may get.

Hijacking Detection Scheme in a Nutshell Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Hijacking Detection Scheme in a Nutshell Select a set of monitors for each target prefix Each monitor periodically measures the network distance to each target prefix and detects significant changes in network distance measurements If a significant distance change is detected, the monitor measures the similarity between the path to the target prefix and the path to the reference point of the target prefix

Evaluation Methods We are about data plane and “real-time” Distributed Scheme for Detecting IP Prefix Hijacking Evaluation ╛ Evaluation Methods We are about data plane and “real-time” Difficult to evaluate using historical data Catching real hijacking attacks red handedly But…… Build simulation Construct simulation scenarios based on real Internet topology

Simulating Prefix Hijacking Attacks Distributed Scheme for Detecting IP Prefix Hijacking Evaluation ╛ Simulating Prefix Hijacking Attacks Imposture attacks One Planetlab node as the monitor s One target prefix as the victim t Another Planetlab node or target prefix as the hijacker h If s is closer to h than t, imposture attack affects monitor, then p(s,t) = p(s,h). Repeat for all possible selections of s, h, and t Total of 34K imposture scenarios hijacker h p(s,h) monitor s p(s,t) victim t

Simulating Prefix Hijacking Attacks Distributed Scheme for Detecting IP Prefix Hijacking Evaluation ╛ Simulating Prefix Hijacking Attacks Interception attacks Planetlab node as the monitor s Target prefix as the victim t Another Planetlab node as the hijacker h If s is closer to h than t, interception attack affects monitor s, p(s,t) ≈ cat(p(s,h), p(h,t)) Repeat for all possible selections of s, h, and t Total of 25K interception scenarios hijacker h p(s,h) p(h,t) monitor s p(s,t) victim t

Hop Count Changes Due to Hijacking Distributed Scheme for Detecting IP Prefix Hijacking Evaluation ╛ Hop Count Changes Due to Hijacking

AS Path Similarity After Hijacking Distributed Scheme for Detecting IP Prefix Hijacking Evaluation ╛ AS Path Similarity After Hijacking Path similarity decreases after hijacking.

Hijacking Detection Accuracy Distributed Scheme for Detecting IP Prefix Hijacking Evaluation ╛ Hijacking Detection Accuracy

Discussion and Future Work Distributed Scheme for Detecting IP Prefix Hijacking Conclusion ╛ Discussion and Future Work Multiple monitors Location and confidence level Granularity of detection Subnet hijacking Counter measures Deployment

Distributed Scheme for Detecting IP Prefix Hijacking Conclusion ╛ Conclusion A light-weight distributed scheme for detecting IP prefix hijacks by conducting measurements in the data plane Hop count stability AS path similarity Advantages Highly accurate low false positive rate and low false negative rate Real-time Easy deployment Highly robust on monitor failure and attacker evasion

Thank You Distributed Scheme for Detecting IP Prefix Hijacking Conclusion ╛ Thank You

Stability of Hop Counts Distributed Scheme for Detecting IP Prefix Hijacking Algorithms and Justifications ╛ Stability of Hop Counts This diagram shows how hop count changes over time, period of 30 days. Change ratio over time Change ratio: ratio of hop count of a later bin to that of an earlier bin

Hijacking Detection Latency Distributed Scheme for Detecting IP Prefix Hijacking Evaluation ╛ Hijacking Detection Latency