170 likes | 324 Views
A Study of Prefix Hijacking and Interception on the Internet. by Hitesh Ballani, Paul Francis, Xinyang Zhang Slides by Benson Luk for CS 217B. Prefix Hijacking. An AS advertises a false route for an IP prefix, stealing traffic that is heading for those IPs
E N D
A Study of Prefix Hijacking and Interception on the Internet by Hitesh Ballani, Paul Francis, Xinyang Zhang Slides by Benson Luk for CS 217B
Prefix Hijacking • An AS advertises a false route for an IP prefix, stealing traffic that is heading for those IPs • May be configuration error or malicious • Can DOS actual destination • Can redirect to phishing servers • Has occurred multiple times in the past
Hijacking and Topology • When will Y choose X’s invalid path over the original, correct path? • Depends on: • 1. Provider-peer-customer relationship • 2. Advertised AS-hop distance to destination • 3. Y’s internal routing
Hijacking and Topology AS Y’s traffic to prefix p can (✓), cannot (✗) or can partly (–) be hijacked depending on its existing route and the invalid route.
Interception • Hijack traffic for a prefix, then forward it to the real destination • Man in the middle attack • Transparent to victim
Interception • X’s original path to C3: • X-W-Q-C1-C2-C3 • X sends false advertisement to Z • Z propagates path to W • W changes its path to C3: W-Z-X-? • Requirement: None of the ASes along the route to the actual destination used by the hijacking AS should choose the invalid route advertised
Interception Requirements • Assuming “valley-free” property (majority of Internet): • All route paths and route advertisement propagation paths consist of: • 0 or more customer-provider links, followed by • 0 or 1 peer link, followed by • 0 or more provider-customer links In exactly that order • 3 cases: • X’s existing route is a customer route • X can safely advertise hijack path to all neighbors. The advertisement will never loop back to X’s real path • X’s existing route is a peer route • X can safely advertise hijack path to all neighbors • X’s existing route is a provider route • X can safely advertise hijack path to customers and peers. Advertising to providers may cause a loop.
Estimates – Tier 1 ASes • Advertise to neighbors that its distance to a target prefix is 1 hop • Hijacks all traffic for that prefix from peers with existing provider routes to the prefix • Hijacks all traffic for that prefix from peers with existing peer routes with length > 1 to the prefix • Hijacks some traffic for peers with existing peer routes of length 1 to the prefix • We’ll have an upper and lower bound of hijacked traffic based on this • Tier 1 ASes only have peers and customers • Can always intercept if it hijacks
Estimates – Tier 1 ASes • Collected routing tables from University of Oregon’s Route-Views repository for 7 Tier 1 ASes • For each AS, determine the prefixes in the Internet routing table whose traffic can be hijacked from the other 6 ASes
Estimates – All ASes • Used all 34 ASes in Route-Views repository • 7 tier 1, 19 tier 2, 8 tier 3+ • Used Cooperative Association for Internet Data Analysis (CAIDA)’s AS relationship data to determine provider-peer-customer topology • For each AS: Can it hijack traffic for prefix p (in one of the 33 other ASes)? If yes, can it route the traffic to p’s owner?
Verifying against known events • Actual hijacking % is the percentage of ASes in the Route-View set that chose the invalid route • Real-world results are within estimated range for 11 of 16 events
Proof of Concept – Traffic Interception • Deployed hosts at 5 different sites. • 1 host would be a target • Other 4 emulate an ISP and try to intercept target’s traffic • Stub AS with only provider links to the rest of internet, so manually configured which routers advertise invalid paths and which don’t in order to not create loops • Used 23k recursive nameservers in 7.5k different ASes to generate traffic aimed at target host
Interception Detection • Traffic interception can cause next-hop anomalies • Used the Route-Views repository to determine the sets of next-hop ASes • For date-plane information, used traceroutes collected in IPlane project • Traceroutes to ~100,000 prefixes from ~200 nodes daily • Mapped IPs to ASes and compared with next-hop data for four different days
Interception Detection • Majority of anomalies detected were due to incorrect IP-to-AS mapping data • Many cases in which an AS uses IPs which appear to belong to another AS’s address space • Many anomalies due to traffic engineering: propagating specific paths only to specific peers, etc. • The vast majority of detected anomalies are explained away with these reasons. • Unable to conclusively classify any anomalies as traffic interception • Does not rule out existing traffic interception • These anomalies occur only for certain specific cases of traffic interception. Other cases of traffic interception may not create this anomaly
Conclusions • ASes higher up in the routing hierarchy can hijack and intercept prefixes from the majority of ASes on the Internet • Even small ASes can hijack and intercept prefixes from a significant number of ASes • Proof of concept suggests that it is simple for ASes to intercept traffic within the existing routing setup • Attempt to detect interception shows some of the many challenges in accurately detecting interception
My Thoughts • Made a lot of assumptions and simplifications on how ASes decide to route • Sample size for estimated numbers seems low • Used 34 ASes, currently there are over 49k assigned ASNs • Does it really matter?