by Hitesh Ballani, Paul Francis, Xinyang ZhangSlides 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

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?