1. 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

2. 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 s.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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

9. 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.

10. 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

11. 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?

12. 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…..

13. 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

14. 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.

15. 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

16. 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.

17. 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

18. 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

19. 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

20. 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

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

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

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

24. 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

25. 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

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

27. 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

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