ARTEMIS: Neutralizing BGP Hijacking within a Minute

1 INTRODUCTION

• ARTEMIS combines self-operated detection and mitigation, using public BGP monitoring and local information to address weaknesses in existing reactive defenses.The approach draws on the increased availability of live public monitoring and shifts detection from third parties to the affected AS.Source: §1 · pp. 1–2
• Existing detection approaches do not cover all attack configurations, allowing sophisticated attackers to evade them; ARTEMIS aims to cover all configurations under a common threat model.The paper introduces a modular attack taxonomy to analyze detection comprehensiveness.Source: §1 · p. 1
• Third-party detection can mistake legitimate routing-policy changes for suspicious events, while less strict policies risk false negatives; ARTEMIS uses operator-held information for high accuracy.It reports 0% false positives and false negatives for most scenarios, with a configurable trade-off otherwise.Source: §1 · p. 1
• Within a minute, ARTEMIS neutralized real hijacking attacks in Internet experiments, detecting them within seconds.The paper reports this as orders of magnitude faster than current practices.Source: §1 · p. 2
• Operators may resist external detection or mitigation because of privacy, cost, and control concerns; ARTEMIS supports private detection and configurable mitigation choices per prefix and attack class.Mitigation can be self-operated or third-party-assisted.Source: §1 · p. 2

2 THREAT MODEL AND ATTACK TAXONOMY

• The threat model gives a hijacker control of one AS and its routers, but not of BGP messages or traffic exchanged between other ASes.Attacks are represented across three dimensions: affected prefix, AS-PATH manipulation, and treatment of hijacked data-plane traffic.Source: §2 · p. 2

2.1 Classification by Announced AS-Path

• Origin-AS hijacks announce an unauthorized prefix as the hijacker’s own, while Type-N hijacks forge an AS-PATH containing the victim and hijacker with at least one fake link.For Type-N attacks, the rightmost fake link determines the type; Type-U leaves the legitimate AS-PATH unaltered.Source: §2.1 · p. 2

2.2 Classification by Affected Prefix

• Exact-prefix hijacks affect routes selected near the hijacker, sub-prefix hijacks can redirect the entire Internet for the more-specific prefix, and squatting announces an owned but inactive prefix.The paper distinguishes these cases by the affected prefix and its specificity or announcement status.Source: §2.2 · p. 2

2.3 Classification by Data-Plane Traffic Manipulation

• Hijacked traffic may be dropped, intercepted and forwarded, or used to impersonate the victim; attempts without prefix or path manipulation are outside the paper’s hijacking scope.Interception and impersonation may be invisible to the victim AS or other involved ASes.Source: §2.3 · pp. 2–3

2.4 Example Hijack Scenarios & Motivations

• Examples span accidental misconfiguration, widespread blackholing, and targeted stealth interception; the paper notes that no single attack type is always best.Type-N attacks may evade simple detection or delay investigation, whereas sub-prefix Type-U attacks may be blocked by upstream providers.Source: §2.4 · p. 3

3.1 Control-Plane Monitoring

• The study draws on public BGP monitoring services, using live BGPmon and RIPE RIS feeds in its prototype and broader RIPE RIS and RouteViews monitor data in further analyses.Some monitoring data are available live, while other feeds are accessed through BGPStream with delays.Source: §3.1 · p. 3

3.2 Simulation Methodology

• Simulations use a CAIDA AS-relationship topology, inferred routing policies, and simulated BGP exchanges; only consistently reporting full-feed monitors from March 2017 are included.Routing policies follow Gao-Rexford conditions to model globally convergent, stable BGP routing.Source: §3.2 · pp. 3–4

4.1 Impact of Hijacks on the Control Plane

• For Type-3 and Type-4 hijacks, impact was very limited or negligible in more than 50% of cases, at 4% and 1%, respectively.Impact generally falls as the hijacker appears farther along the announced path.Source: §4.1 · p. 4, Figure 1 · p. 4
• Even Type-4 hijacks can pollute more than 80% of ASes in some simulations, so connectivity metrics alone cannot identify every impactful attacker.Impact depends on the victim and hijacker’s locations in the AS graph and their relationships with neighbors.Source: §4.1 · p. 4

4.2 Visibility of Hijacks on the Control Plane

• More than 20% of Type-3 hijacks were invisible to any service, while almost all Type-0 hijacks were visible; combining services always increased visibility.Smaller hijack types were visible with higher probability and to more monitors on average.Source: §4.2 · p. 5, Figure 2 · p. 5, Table 3 · p. 5
• Hijacks polluting more than 2% of the Internet were always visible in simulations, while invisible events had mean impact below 0.2% and median impact of 0.1%.Streaming services alone had full visibility only for events with impact greater than 30%.Source: §4.2 · p. 5, Figure 3 · p. 5

5.1 Overview

• By default, ARTEMIS introduces no false negatives except for events invisible to monitoring, and potential false positives occur at a very low rate only for Type-N exact-prefix hijacks.Operators can trade detection speed for accuracy, or accept some negligible-visible-impact false negatives for fewer false positives.Source: §5.1 · p. 6

5.2 Detecting Sub-prefix Hijacks & Squatting

• For sub-prefix hijacks, ARTEMIS detects an observed prefix absent from the operator’s announced-prefix list, returning zero false positives and zero false negatives; it also detects BGP squatting.The stated zero-error result applies to all sub-prefix hijack types; the squatting check uses prefixes owned but not actually announced.Source: §5.2 · p. 6

5.3 Detecting Type-0/1 Exact Prefix Hijacks

• ARTEMIS detects all monitor-visible Type-0/1 hijacks and returns zero false positives by checking updates against the local prefix, origin-ASN, and neighbor-ASN lists.An update that does not match those lists indicates an illegitimate announcement, according to the authors.Source: §5.3 · p. 6

5.4.1 Stage 1

• For Type-N exact-prefix events, Stage 1 flags new AS-links and filters them using link direction and shared upstream ASes in paths containing the reverse link.A new link without an observed reverse direction is suspicious; when the reverse exists, an intersection of upstream ASes distinguishes suspicious from legitimate events.Source: §5.4 · p. 6, §5.4.1 · p. 7
• Stage 1 has zero false negatives for monitor-visible illegitimate announcements containing a fake link, whether or not the hijacker ASN is at its ends.This guarantee is within the paper’s threat model and depends on announcements being visible.Source: §5.4.1 · p. 7

Stage 1 dramatically reduces the number of suspicious

• 72% of origin ASes saw fewer than two new links per day, and after Stage 1 filtering, 73% saw fewer than one suspicious event every three days.These rates come from analysis of real BGP updates; Fig. 4 plots the new-link and post-filter distributions.Source: §5.4.1 · p. 8, Stage 1 dramatically reduces the… · p. 8, Figure 4 · p. 8

5.4.2 Stage 2 (optional)

• Stage 2 waits a configurable interval to refine filtering and estimate impact; public monitors alone reduced suspicious events by around 1%, while local-router data filtered 1–2 orders of magnitude more Type-2/3 events.The local-router comparison is against using only monitor AS-links; its observed reverse-link rates were around 25% for second-hop and 30% for third-hop cases.Source: §5.4.2 · p. 8
• Stage 2 can nearly eliminate false positives by thresholding monitor counts, at the cost of a few false negatives with negligible control-plane impact.Ignoring events seen by fewer than four monitors left at most one alert for 94% of origin ASes and zero alerts for 81% in the reported experiment.Source: §5.4.2 · p. 8

6.1 ARTEMIS Mitigation Approach

• Operators can map detection outputs—including event type, impact, involved ASes, and confidence—to preconfigured actions that ARTEMIS executes without manual intervention.Operators can also choose manual handling for limited-impact events or unconditional mitigation for sensitive prefixes.Source: §6.1 · p. 9
• In the survey, 61.3% outsourced hijack detection and 17.3% expected notification from colleagues or mailing lists; operators also valued fast mitigation and self-managed systems.The survey reports that self-operated approaches may suit at least two thirds of networks without a local detection system.Source: Figure 5 · p. 9, §6.1 · p. 9

6.2 Mitigation Techniques

• The victim AS can deaggregate a hijacked prefix itself or outsource mitigation by having another organization announce the prefix on its behalf.For outsourced announcements, the organization attracts traffic and tunnels it back to the legitimate AS.Source: §6.2 · p. 9, §6.2.2 · p. 10

6.2.1 Self-operated mitigation with prefix deaggregation

• Deaggregation advertises more-specific routes that BGP prefers, but is effective for hijacked /23 or less-specific prefixes because most routers filter /25 and more-specific routes.The network can trigger deaggregation immediately after detection without added cost.Source: §6.2.1 · pp. 9–10

Outsourcing BGP announcements outperforms current

• With 3 top ISPs, outsourcing leaves less than 5% of ASes polluted for Type-0 hijacks, while even dozens of filtering ASes barely help.Outsourcing BGP announcements is more effective than filtering in the reported comparisons.Source: Figure 6 · p. 10, §6.2.2 · p. 10, Outsourcing BGP announcements… · p. 10
• Akamai announcements reduce polluted ASes to 2.4% from 50% for Type-0 hijacks, and to 0.3% or less for other hijack types.The study simulated announcements from five organizations providing DDoS protection services.Source: Table 5 · p. 11, Outsourcing BGP announcements… · p. 11

7.1 Experimental Setup

• The prototype monitored owned prefixes through BGPmon and RIPE RIS streams and used PEERING to announce real prefixes from three network sites.BGPStream, whose feeds had delays of several minutes, was used for post-experiment analysis alongside the real-time services.Source: §7 · p. 11, §7.1 · p. 11, §4 · p. 11

7.2 Experimental Results

• Detection delay had a median of at most 5s, was almost always less than 10s, and reached a worst case of 13s.In some experiments, detection took 1s; the authors attribute delay primarily to propagation of BGP updates to monitors.Source: Figure 7 · p. 12, §7.2 · p. 12
• More than 5 monitors observed hijacked routes within 5s in every scenario, and almost half of eventual observing monitors saw them within 10s.ARTEMIS can detect from one hijacked route, while additional observations increase robustness against monitor failures.Source: §7.2 · p. 12
• Half of affected ASes recovered in less than 30s and the vast majority within a minute, with some outliers reaching 2min.Recovery delay is measured from pollution by a hijacked route until the AS or monitor receives a legitimate route again.Source: Mitigation · pp. 12–13, Figure 8 · p. 13

8.1 Real-world Problems with BGP Hijacking

• Around 7% of prefixes were covered by ROAs in October 2017, and limited ROV deployment left the vast majority of networks unprotected.Prefix filtering was used by few ISPs and protected only against some hijackers and origin-AS events; RPKI adoption faced security-benefit, trust, dependency, cost, and complexity concerns.Source: §8.1 · p. 13
• More than 57% of surveyed hijacking events lasted over an hour, while third-party alerts often required manual verification before mitigation.The survey found 25% lasted more than a day; more than 60% relied on third parties for alerts, while 17% expected notifications from colleagues or mailing lists and 25% would only contact other operators to mitigate.Source: §8.1 · pp. 13–14

8.2.1 Detection of BGP Hijacking

• Control-plane systems are lightweight and detect Type-0/1 events, but can miss advanced Type-N attacks; data-plane monitoring can miss sub-prefix hijacks and raise false positives.Data-plane approaches also require many active measurements; the cited control-plane systems must reconcile observations with operators’ ground truth to limit false positives.Source: §8.2.1 · p. 14
• Hybrid systems cover multiple attack classes, but HEAP misses man-in-the-middle attacks, Argus considers only blackholing, and other systems have stated coverage gaps.HEAP is limited to sub-prefix blackholing or imposture; the cited system misses man-in-the-middle attacks, while LOCK may miss sub-prefix and stealthy Type-U hijacks.Source: §8.2.1 · p. 14
• ARTEMIS is presented as the first approach combining self-operated, ground-truth-based, lightweight detection with zero false positives for most classes, virtually zero false negatives, and comprehensive attack coverage.The authors note there is no consistent ground truth or dataset for comparing all claimed false-positive and false-negative rates of existing approaches.Source: §8.2.1 · p. 14

8.2.2 Mitigation of BGP Hijacking

• Outsourcing BGP announcements can achieve under 5% attacker success with a handful of top ISPs, whereas ROV requires two orders of magnitude more top ISPs to coordinate.The authors propose reactive self-operated prefix deaggregation or outsourcing announcements without large-scale coordination; a cited alternative requires an order of magnitude more mitigator ASes for similar benefits and complex coordination.Source: §8.2.2 · p. 14

• BGP hijacking remains a threat because existing defenses have gaps in detection comprehensiveness, alert accuracy, mitigation speed, privacy, and operator flexibility.Source: §9 · pp. 14–15
• ARTEMIS uses local information and real-time public BGP feeds for self-operated detection, supporting configurable and timely mitigation.The paper also reports that public monitoring infrastructure has substantial detection capability and that more pervasive real-time streaming can bring benefits.Source: §9 · p. 15
• Real-world experiments show ARTEMIS can neutralize hijacking impact within a minute, a radical improvement over defenses used in practice.Source: §9 · p. 15