In 2017 alone, thousands of routing incidents caused costly outages and interception of information, while the exact extent of the problem is unknown. Despite numerous research efforts over the last 20 years, on protecting networks from BGP hijacking (detection, reactive mitigation, proactive defenses), the majority of the proposed solutions have not found their way to industry, with the exception of RPKI; though its deployment is still very limited. As such, networks are still vulnerable to hijacking events, which frequently require hours (or even days) to be resolved.

In this article, we present ARTEMIS, a system that can be used by operators to protect their own network from BGP prefix hijacking events. Using real experiments, we’ve shown that ARTEMIS can detect prefix hijacking events within seconds and neutralise them within a minute; orders of magnitude faster than with current practices.

ARTEMIS Overview

ARTEMIS is used by an Autonomous System (AS) to protect its own prefixes, and is operated in-house, as software running on a VM/container in the Network Operations Center (NOC). The operator only needs to configure ARTEMIS, providing information about the announced prefixes of the network as well as its neighbours (configuration file; its generation can be automated using information from IRRs, RPKI DBs, and local routers).

The system is composed of three main modules/services:

1. Monitoring, receiving information from public monitors (for example, RIPE RIS and RouteViews) and local routers.
2. Detection, identifying hijacking events by comparing the monitoring information with the configuration file (‘ground truth’).
3. Mitigation, reacting automatically or manually to a detected hijacking event via custom in-house (or optionally outsourced) mechanisms.

An overview of ARTEMIS is provided in Figure 1.

Figure 1: Overview of the ARTEMIS system

ARTEMIS can detect both simple hijacks (for example, involving a fake origin or upstream AS of the protected network), and advanced hijacks (for example, sub-prefix, man-in-the-middle, or path manipulation attacks).

Figure 2 depicts an example of how ARTEMIS operates in the latter case (path manipulation using a fake link).

Figure 2: ARTEMIS operation example: Path manipulation via fake link + sub-prefix

For a comprehensive analysis on the attacks covered by ARTEMIS, as well as its comparison with other related approaches, we refer the reader to our paper.

Monitoring

ARTEMIS continuously monitors the Internet control plane by leveraging pervasive publicly available BGP monitoring services, such as RIPE RIS and RouteViews (and their recently acquired real-time streaming capabilities).

Specifically, it receives real-time BGP updates from:

• RIPE RIS monitors, using a socket.io interface
• RouteViews and RIPE RIS monitors, using the BGPStream API; and
• Local BGP routers via exaBGP and iBGP

In our work, we show that the existing public monitoring infrastructure can enable live detection of all impactful hijacking events. In fact, while a hijacker can employ several means to achieve a stealthy — that is, invisible to BGP monitors — hijack, this can be achieved only at the cost of limited impact (less than 1-2% of AS-level pollution).

Transitioning more monitors to live streaming will further increase global visibility and reduce detection times.

Detection

Detection operates by cross-checking the BGP updates received by the monitoring module/service, against the local configuration files (for example, origin/neighbour ASNs and announced prefixes) and a knowledge base (containing, for example, observed AS-level links and related metadata) created automatically by ARTEMIS and stored locally.

The ARTEMIS detection approach is:

• Comprehensive - detecting all possible attack types that are visible on the control plane.
• Accurate - generating zero False Positives (FP) / Negatives (FN) for basic hijack types (for example, fake origin/upstream announcements, or sub-prefix hijacks of any type), and a very low -tunable- FP-FN trade-off for others (for example, path manipulation attacks).
• Fast - specifically based on real-world experiments using the PEERING testbed, we’ve shown that the stages of real-time monitoring and detection take only a few seconds, which is a demarcation point from existing detection systems (see Figure 3).

Figure 3: ARTEMIS detection delay (boxplots; y-axis) in real-world experiments on PEERING testbed; letters (x-axis) denote different PoPs used as victim and hijacker (source)

Mitigation

Capitalising on reliable detection information, ARTEMIS enables automated mitigation of a hijacking event.

Mitigation can be triggered immediately upon detection; manual mitigation (for example, pending approval by the operator) is also possible if desired. Moreover, mitigation can be flexible, for example, configurable per prefix, hijack type, observed impact, and so on.

Currently, ARTEMIS offers two primary mitigation methods.

1. The first one is based on a ‘do-it-yourself’ approach, where the network reacts by prefix de-aggregation in order to attract traffic back to its own routers. This technique is effective for all unfiltered prefixes, less specific than /24.
2. For attacks on /24 prefixes, ARTEMIS can enable a mitigation solution similar to the DDoS protection as-a-service offered today. In particular, the affected AS can request from other (collaborating) networks to announce the hijacked prefix from their own premises (Multiple Origin AS), and then tunnel the traffic they attract back to the victim (for example, via the victim’s upstream providers).

Αs we show in Figure 4 based on our PEERING experiments, the monitoring-detection-mitigation cycles for a hijack require at maximum 1 minute. Therefore, departing from the current approaches of manual intervention, bringing the focus to the network itself, drastically reduces reaction times of defensive countermeasures.

Figure 4: Real-world experiments on PEERING testbed; detection and mitigation cycles (source).

State of the Art

Network operators currently deal with BGP prefix hijacking using two main defense types: proactive, such as RPKI, and reactive, such as third-party detection services raising alerts that operators then need to manually verify and resolve (for example, via prefix de-aggregation or contacting other networks for filtering).

On the one hand, technologies such as RPKI and BGPsec are fully effective only when globally deployed (and still may not prevent all potential attacks); in practice, operators are reluctant to deploy them (currently less than 10% of prefixes are covered by ROAs) due to associated technical and financial costs/risks, and the cyclic dependency between limited adoption and deployment (see Figure 5).

Figure 5: Reasons for not using RPKI (source)

On the other hand, current, third-party services suffer from multiple issues, such as: 

1. Limited comprehensiveness, since they detect only simple attacks.
2. Limited accuracy, both in terms of FP and FN.
3. Delayed resolution of hijacks.
4. Compromises with respect to privacy and the need to share private information (such as the routing policies of the network).

Therefore, under this regime, prefix hijacks still affect networks for critical periods of time, up to multiple days (see Figure 6), with dire consequences in terms of costs and reputation for the victim networks.

ARTEMIS reduces these times from hours/days to a few minutes, aiming to become a practical and useful tool for the network community.

Figure 6: How much time an operational network was affected by a hijack (source)

What’s next?

ARTEMIS is currently under development; recent updates were presented during the RIPE 76 Routing WG. Operators are welcome to answer our related questionnaire, while we encourage everyone to visit our website, where you can also find our contact information, read the ARTEMIS paper, and check out the results of the related survey and our demo.

Moreover, we would welcome advice on integrating ARTEMIS in operational environments for testing purposes (for example, real-world configurations and setups), as well as feedback for further improvement or inclusion of new services.

Acknowledgements

ARTEMIS is a joint research effort led by INSPIRE group and CAIDA. The software development stage has received funding by the RIPE NCC Community Projects Fund 2017.

This work was also supported by the European Research Council (grant agreement no. 338402), the National Science Foundation (grant CNS-1423659), and the Department of Homeland Security (DHS) Science and Technology Directorate, Cyber Security Division (DHS S&T/CSD) (via contract number HHSP233201600012C).