ARTEMIS — neutralizing BGP hijacking within a minute

BGP prefix hijacking is a persistent threat against Internet organizations, attributed to a lack of authorization and authentication mechanisms in the inter-domain routing system.

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 into ways to protect networks from BGP hijacking (detection, reactive mitigation, proactive defences) over the last 20 years, 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 post, we present ARTEMIS (Automatic and Real-Time dEtection and MItigation System), a defence 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 neutralize them within a minute; orders of magnitude faster than with current practices.

---

Key Points:

• ARTEMIS is a defence system against BGP prefix hijacking, comprising of monitoring, detection and mitigation services, and is operated in-house.
• It reduces hijack detection and mitigation times from hours/days to a few seconds or minutes.
• The system can be configured for manual and automatic mitigation.

---

ARTEMIS overview

ARTEMIS is based on comprehensive, accurate and fast detection operated by the AS itself, and enables flexible and fast mitigation of hijacking events. It is used by an 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.

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 of the attacks covered by ARTEMIS, as well as its comparison with other related approaches, check out our paper [PDF 459 KB].

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 point of difference from existing detection systems (see Figure 3).

Figure 3 — ARTEMIS detection delay (boxplots; y-axis); letters (x-axis) denote different PoPs used as victim and hijacker (source [PDF 459 KB]).

Mitigation

Capitalizing 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 that other (collaborating) networks 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).

As 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 [PDF 459 KB]).

State of the art

Network operators currently deal with BGP prefix hijacking using two main defence 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 [PDF 147 KB]).

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 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 [PDF 147 KB]).

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 [459 KB], and check out the results of the related survey [PDF 254 KB], and our demo [PDF 146 KB].

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 from the RIPE 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).

Contributors: Pavlos Sermpezis, Lefteris Manassakis, George Nomikos, Xenofontas Dimitropoulos, Alberto Dainotti.

Vasileios Kotronis is a postdoctoral researcher at the Foundation for Research and Technology – Hellas (FORTH) and is a member of the INSPIRE group at the Institute of Computer Science (FORTH-ICS).

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.