by Hitesh Ballani, Paul Francis, Xinyang Zhang Slides by Benson Luk for CS 217B
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
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
AS Y’s traffic to prefix p can (✓), cannot (✗) or can partly (–) be hijacked depending on its existing route and the invalid route.
Hijack traffic for a prefix, then forward it to the real destination
Man in the middle attack
Transparent to victim
Requirement: None of the ASes along the route to the actual destination used by the hijacking AS should choose the invalid route advertised
X’s original path to C3:X-W-Q-C1-C2-C3
1. X sends false advertisement to Z
2. Z propagates path to W
3. W changes its path to C3: W-Z-X-?
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 linksIn 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.
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
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
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?
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
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
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
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
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