...

The name of the application (ARTEMIS), is inspired from the initials Automatic and Real-Time dEtection and MItigation System. Moreover, it is the name of the Greek goddess Artemis, who according to ancient Greek mythology, is the goddess of hunting.

...

Basic knowledge of the BGP protocol and its best path selection algorithm is required in order to fully grasp the concept concepts behind ARTEMIS. However, everyone with basic ONOS and mininet skills can follow the demo without this prior knowledge.

...

2) The detection service combines the information from these sources; the minimum delay of the detection service is the delay for the first suspicious BGP update to arrive (from any source). ARTEMIS can be parameterized (e.g., selecting BGP monitors based on location and/or connectivity) to achieve tradeoffs trade-offs between monitoring overhead and detection efficiency/speed.

3) When a prefix hijacking is detected, ARTEMIS automatically launches its mitigation service. Since in Internet routing the most specific prefix is always preferred, ARTEMIS modifies the BGP configuration of the routers so that they announce deaggregated sub-prefixes of the hijacked prefix (that are most preferred from any AS). After BGP converges, the hijacking attack is mitigated and traffic flows normally back to the ARTEMIS-protected AS (the one that runs ARTEMIS). Therefore, ARTEMIS assumes write permissions to the routers of the network, in order to be able to modify their BGP configuration and mitigate the attack. This can be effectively accomplished by running ARTEMIS as an a set of application-level modulemodules, over a network controller that supports BGP, like ONOS [9].

...

 Figure 2 depicts the topology that is setup via the topo.py file inside the tutorial folder (/onos/tools/tutorials/artemis/topo.py). The BGP speakers are Quagga routers and the route collector is an ExaBGP router running a custom script to replicate the behavior of a RIPE RIS route collector.

 

...

• R1: Announces via BGP the 10.0.0.0/8 prefix to it's neighbors, AS65003 and AS65002. Also, it has an iBGP session established with the exaBGP RC so that it propagates BGP update messages to it, in order for exaBGP to act as a BGP monitoring service.

• ExaBGP RC: RC connected to R1 via iBGP but also to the ONOS controller on the protected AS (in the real world this the latter connection can be established through the existing network (, e.g., via a tunnel)); the only limitation is that the network interface of ONOS that interconnects with the RC must have a non-hijacked IP address assigned, so that it can be reached by the monitoring service during the hijack).

• H1 / 10.0.0.100: Host which communicates with the host inside the protected AS. It is used to provide us a visualization of the data-plane behavior when the BGP hijack occurs.

•  AS65002
  Intermediate AS that consists of a BGP speaker (R2) that announces via BGP the prefix 20.0.0.0/8 to it's neighbors (R1, R4), and its purpose is to add an additional hop to the AS-PATH so that the protected AS can be hijacked. Although in the demo the attacker announces the exact prefix that belongs to the protected AS and not a more specific one, due to the shortest path attribute of the BGP best path selection algorithm, the hijacker is able to steal the traffic stemming from AS65001 towards IP addresses of the the hijacked prefix.

• AS65003
  Hijacker AS that consists of a BGP speaker (R3).

• R3: By announcing the prefix of the protected AS (40.0.0.0/8) from this BGP speaker, we trigger a BGP hijack, and all traffic generated from AS65001 and directed towards AS65004, will be redirected to the network of AS65003.
  

• AS65004
  Protected AS that is employing ONOS. It consists of a BGP speaker (R4), an OVS switch, a host (H4) and the ONOS instance.

• R4: BGP speaker announcing 40.0.0.0/8. It is connected with his neighbor (R2) through the OVS switch via the SDN-IP application.

• OVS: Communicates with ONOS on a management interface via 192.168.0.0/24.

• ONOS: Is connected with R4 to retrieve the BGP routing table. Also, it receives the BGP update messages from the ExaBGP RC, when routing changes occur. Finally, it is connected with the OVS switch in order to interact with the data plane.

• H4 / 40.0.0.100: Host that receives traffic with the help of the reactive-routing application from the host in AS65001 (H1).

...

Note: The demo configuration also includes entries for the SDN-IP and the Reactive-Routing application (separate step, preconfigured pre-configured and not presented in this demo for simplicity). It specifies where the BGP speaker is located and which are the local prefixes.

...

Download ONOS from GitHub and configure the corresponding bash profile:

$ git clone https://github.com/opennetworkinglab/onos.git
$ echo '. ~/onos/tools/dev/bash_profile' >> ~/.bashrc
$ source ~/.bashrc

...

You must put the absolute path at the run command, e.g., /home/user/onos/tools/tutorials/artemis/server.py.

...

Install curl and run ONOS (the first run will require more some time):

$ sudo apt-get install curl
$ cd onos
$ buck run onos-local -- clean

...

Check if bgp-routes are visible by ONOS, indicating that BGP has converged (must include the 10.0.0.0/8, 20.0.0.0/8, 30.0.0.0/8 and 40.0.0.0/8 prefixes; if not, you should restart the mininet topology). It requires time (~1-2 minutes) for the BGP protocol to converge, so this step requires patience!:

ONOS> bgp-routes

...

mininet> xterm R3 (opens a new terminal on R3)
mininet> pingall (to make the hosts visible)
mininet> h1 ping h4 (to see the data plane interactions)

2. On the new terminal of R3, announce the prefix:

...

Now the hijacker (AS65003) will attract all the traffic away from AS65001 (destined to 40.0.0.0/8) away from AS65004; at the same time, the ExaBGP speaker in AS65001 will send the BGP update of the hijack (among other updates seen by AS65004) to the ONOS instance (running ARTEMIS) and the hijack will be detected. Observing the ONOS logs, you will see that the attack is actually detected and the deaggregation mechanism has successfully mitigated the attack (by announcing the more specific prefixes 40.0.0.0/9 and 40.128.0.0/9 from the BGP speaker of the protected AS). After BGP converges and the control and data planes are consistent, the traffic of AS65001, destined to 40.0.0.0/8, returns to the protected AS, as shown in Figure 5:

...

As future work, another extension of ARTEMIS , is the support of multiple vendor routers, beyond Quagga, by employing protocols such as NETCONF and YANG. You can learn more about our future plans by watching the TST presentation video that follows after the demo video.

Demo video using GNS3 as emulation platform

...

[14] “Internet Security Privacy and Intelligence Research Group”, http://www.inspire.edu.gr/