iSPY: Detecting IP Prefix Hijacking on My Own
IP prefix hijacking remains a major threat to the security of the Internet routing system due to a lack of authoritative prefix ownership information. Despite many efforts in designing IP prefix hijack detection schemes, no existing design can satisfy all the critical requirements of a truly effective system: real-time, accurate, light-weight, easily and incrementally deployable, as well as robust in victim notification. In this paper, we present a novel approach that fulfills all these goals by monitoring network reachability from key external transit networks to one's own network through lightweight prefix-owner-based active probing. Using the prefix-owner's view of reachability, our detection system, ISPY, can differentiate between IP prefix hijacking and network failures based on the observation that hijacking is likely to result in topologically more diverse polluted networks and unreachability. Through detailed simulations of Internet routing, 25-day deployment in 88 ASes (108 prefixes), and experiments with hijacking events of our own prefix from multiple locations, we demonstrate that ISPY is accurate with false negative ratio below 0.45% and false positive ratio below 0.17%. Furthermore, ISPY is truly real-time; it can detect hijacking events within a few minutes.
| Attachment | Size |
|---|---|
| p327-zhangA.pdf | 380.54 KB |
Applicability of techniques?
I enjoyed reading your paper and think there are a number of clever research ideas. I also think that prefix hijacking is an important problem that more people should look at and try to address. However, I was wondering if you could comment a little more on how and when a real world administrator would use a tool which leverages the techniques described in your paper. Specifically, I have some questions and concerns about when iSPY is better suited to solve a task than routeviews.
Given the availability of routeviews, in what cases would I want to use iSPY? It seems that even after iSPY notifies me that something is wrong, I'll need something like routeviews to figure out who is responsible. Is the premise of the paper that iSPY would be useful if routeviews went away?
As I understand the work, iSPY assumes the administrator has previously run iSPY in their network and gathered a prior topology. Do you anticipate administrators will download and run a prefix hijacking detection tool when they don't think they are hijacked or do you think they will wait until they believe there might be a problem to use one?
I'm not sure I understand the "robust in victim notification" argument in the paper. From what I understand, iSPY is meant to be run to detect issues with the local network (and so notification is simply telling the admin using the tool that they have an issue with their network). The way I understand the argument you're making is you're saying "if the detection mechanism is run by someone other than the victim, the victim must be notified". From what I see, you're claiming that iSPY is better since it fails to detect prefix hijacks for other networks, because then we might not know how to contact the administrators!
The primary benefit I see from your technique (given the existence of routeviews) is that the routeview data may be up to 15 minutes stale and so it may take slightly longer to detect a new hijacking attack (assuming I am constantly running iSPY and have previously bootstrapped it with data). However, I need the routeviews data to figure out who to contact to get the problem fixed anyways, so I'm not convinced that the ~6-7 minutes this saves me on average is worth it.
I'm sure I'm missing some important aspects of your work and would appreciate any clarification you can provide.
Thanks,
Justin Cappos