Page under construction

Team

NameOrganizationRoleEmail
Dimitris MavrommatisON.Lab /
Foundation for Research and Technology - Hellas (FORTH),
Institute of Computer Science, INSPIRE group
Lead Developerdimitris@onlab.us
Lefteris ManassakisFoundation for Research and Technology - Hellas (FORTH),
Institute of Computer Science, INSPIRE group

Engineering Supervisor /
Secondary Developer

leftman@ics.forth.gr

Vasileios KotronisFoundation for Research and Technology - Hellas (FORTH),
Institute of Computer Science, INSPIRE group

Research Supervisor /
Secondary Developer

vkotronis@ics.forth.gr

Overview and Goals

Prefix hijacking is a common phenomenon in the Internet that often causes routing problems and economic losses [13]. ARTEMIS [1,10] is a tool, usable by network administrators, to detect in real-time and automatically mitigate prefix hijacking incidents against their own prefixes, employing self-monitoring on the AS level. ARTEMIS employs real-time monitoring of BGP data (e.g., BGP updates exported by route collectors) and can: (a) detect a prefix hijacking within a few seconds from its launch, and (b) completely mitigate the hijack within a few minutes (e.g., 2-5 minutes in the initial experiments with the PEERING testbed [2]). This fast response time enables legitimate ASes to quickly counter the hijack based on data they observe themselves on the control plane.

The goal of this project is to implement ARTEMIS as a multi-module application running on top of ONOS [9], using the prior work and code-base of the SDN-IP project [3,8], as well as testing the application over a real BGP testbed such as PEERING [2]. The final objective is to have an open-source implementation of ARTEMIS running on top of a popular production-grade Network Operating System. This implementation will then enable researchers and operators to test miscellaneous BGP prefix mitigation strategies over real-world testbeds and production networks, and extract results that are relevant to today’s ISP operations; such results would be otherwise not possible to produce.

Prerequisites

Basic knowledge of the BGP protocol and its best path selection algorithm is required in order to fully understand the concepts of ARTEMIS. However, every user can try the demo without this prior knowledge.

ARTEMIS Architecture and Functionality

System Architecture
Fig. 1: The ARTEMIS architecture.

ARTEMIS consists of three components: a monitoring (1), a detection (2) and a mitigation (3) service as shown in Fig. 1.

1) The monitoring service runs continuously and provides control plane information from the AS itself, the streaming services of RIPE RIS [4] and BGPstream [6] (from RIPE RIS and RouteViews), as well as BGPmon [5] and Periscope [7], which return almost real-time BGP updates for a given list of prefixes and ASNs.

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 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 application-level module, over a network controller that supports BGP, like ONOS [9].

Note: Prefix deaggregation is effective for hijacks of IP prefixes less specific than /24, but it might not work for /24 prefixes or more specifics. This is because BGP advertisements of more specific than /24 prefixes are typically filtered by many ISPs, since it is considered as best practice to avoid the exponential increase of the size of the BGP routing table. We plan to address this problem through future extensions of ARTEMIS (e.g., collaborative mitigation).

Future plans: Despite the fact that ARTEMIS was first tested in a non-SDN environment with the basic mitigation strategy of automatic prefix deaggregation in mind, it can support several extensions related to its monitoring, detection and mitigation mechanisms due to its modular design. These extensions, e.g., employing MOAS (Multi-Origin AS Announcements) and tunneling in order to steer the hijacked traffic back to its legitimate owner during the mitigation phase, will also be researched as extra modules built over the ONOS platform. In parallel to the mitigation, an additional monitoring service is envisioned to provide real-time information about the mitigation process. This service can also use data from Periscope, RIPE RIS, BGPstream and BGPmon to monitor/visualize the mitigation.

 

Demo Topology

 

Figures 2 and 3 show the topology that is setup via the topo.py file inside the tutorial folder (TODO: set exact location). 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 route collector.

 


 

Screen Shot 2017-07-13 at 2.12.25 PM.png 

 

                                                    Fig. 2: The conceptual demo topology.                                                                                                                           Fig. 3: The full emulated demo topology.                                      

 

JSON Configuration File

The JSON Configuration File is the file that contains the required configuration entries to monitor prefixes and check the validity of neighbors and paths. The following code block shows an example of the JSON configuration format for ARTEMIS which is used in the Demo Topology.

"org.onosproject.artemis" : {
	"artemis" : {
    	"prefixes" : [ 
        	{
            	"prefix" : "40.0.0.0/8",
                "paths" : [ 
                	{
                    	"origin" : 65004,
                        "neighbor" : [
                        	{
                            	"asn" : 65002,
                                "neighbor": [ 65001 ]
                            }
                        ]
                    }
                ],
                "moas" : [ ]
            }
        ],
        "frequency" : 3000,
        "monitors" : {
        	"ripe" : [ ],
        	"exabgp": [ "192.168.1.2:5000" ]
        }
    }
}

Explanation of Fields

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

Running the Demo

Install the ExaBGP Python library by doing these steps: 

$ cd ~
$ git clone https://github.com/Exa-Networks/exabgp
$ cd exabgp; git checkout 3.4
$ echo 'export PATH=$PATH:~/exabgp/sbin' >> ~/.bashrc
$ source ~/.bashrc

Install the Quagga software routing suite through apt-get:

$ sudo apt-get install quagga -y

Download and install the mininet emulation platform:

$ cd ~
$ git clone https://github.com/mininet/mininet
$ cd mininet; git checkout 2.2.2
$ ./util/install.sh -fnv

Install java 8 (needed by ONOS in the next steps):

$ sudo apt-get install software-properties-common -y && \
sudo add-apt-repository ppa:webupd8team/java -y && \
sudo apt-get update && \
echo "oracle-java8-installer shared/accepted-oracle-license-v1-1 select true" | sudo debconf-set-selections && \
sudo apt-get install oracle-java8-installer oracle-java8-set-default -y

Download ONOS from GitHub and add the bash profile:

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

Install pip3, Python packages and set the configuration used by ExaBGP: 

$ sudo apt-get install python3-pip -y
$ sudo pip3 install -r ~/onos/tools/tutorials/artemis/requirements.txt
$ nano ~/onos/tools/tutorials/artemis/configs/exabgp.conf (you must put the absolute path at run command, e.g., /home/onos/onos/tools/tutorials/artemis/server.py)

Run ONOS (first time will take some time):

$ buck run onos-local -- clean

When ONOS is loaded run the mininet topology:

$ cd /onos/tools/tutorials/artemis
$ sudo ./topo.py

Note: If you are using a GUI version of Ubuntu, you should disable networking by un-checking it in the relevant menu, in order to avoid interfaces swapping IP addresses!
Pass the network configuration with onos-netcfg and login to the onos CLI:

$ onos-netcfg localhost ~/onos/tools/tutorials/artemis/configs/network-cfg.json
$ onos localhost

Run artemis inside the ONOS CLI (requires reactive-routing as a prerequisite application):

onos> app activate org.onosproject.reactive-routing
onos> app activate org.onosproject.artemis

Check if bgp-routes are complete (should include 10.0.0.0/8, 20.0.0.0/8, 30.0.0.0/8 and 40.0.0.0/8; if not you should restart the topology. It takes some time (~1-2min)):

ONOS> bgp-routes

Now that the topology is running, through the mininet CLI you can connect to the hosts to check connectivity and also to the BGP speakers to modify the BGP control plane. To hijack the prefix of the protected AS:

1. Connect to the BGP speaker named R3: 

mininet> xterm R3 (opens a new window on R3 node)
R3> telnet localhost bgpd

2. Announce the prefix:

R3> sdnip (this is the password)
R3> enable
R3# configuration terminal
R3(conf)# router bgp 65003
R3(conf-bgp)# network 40.0.0.0/8

Now the hijacker (AS65003) will attract all the traffic away from AS65001 (destined to 40.0.0.0/8); in parallel the ExaBGP speaker will send the BGP update of the hijack (among other updates seen by AS65004) to the ONOS instance (running artemis) which is going to detect the hijack. Inside the logs you will see that the attack is actually detected and the deaggregation mechanism has successfully mitigated the attack (by announcing the more specific 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.

Demo video

 

ONOS Technical Steering Team Presentation

 

 

Presentation Slides: https://goo.gl/UZREBe

References

[1] G. Chaviaras, P. Gigis, P. Sermpezis, and X. Dimitropoulos, “ARTEMIS: Real-Time Detection and Automatic Mitigation for BGP Prefix Hijacking (demo)”, in ACM SIGCOMM, 2016 (url: http://www.inspire.edu.gr/wp-content/pdfs/PavlosSIGCOMM2016.pdf)

[2] “About PEERING - The BGP Tetsbed”, https://peering.usc.edu/ 

[3] “SDN-IP”, https://wiki.onosproject.org/display/ONOS/SDN-IP

[4] “RIPE RIS - Streaming Service”, https://labs.ripe.net/Members/colin_petrie/updates-to-the-ripe-ncc-routing-information-service 

[5] “BGPmon”,  http://www.bgpmon.io 

[6] “BGPstream”, https://bgpstream.caida.org/  

[7] V. Giotsas, A. Dhamdhere, and K. Claffy, “Periscope: Unifying looking glass querying”, in Proc. PAM, 2016

[8] Lin, Pingping, et al., "Seamless interworking of SDN and IP", in ACM SIGCOMM Computer Communication Review. Vol. 43. No. 4. ACM, 2013.

[9] Berde, Gerola, et al. "ONOS: towards an open, distributed SDN OS", Proceedings of the third workshop on Hot topics in software defined networking, ACM, 2014.

[10] “ARTEMIS demo”, http://inspire.edu.gr/artemis

[11] “Mininet: An Instant Virtual Network on your Laptop (or other PC)“, http://mininet.org/ 

[12] “GNS3: The software that empowers network professionals”, https://www.gns3.com/ 

[13] “Hacker Redirects Traffic From 19 Internet Providers to Steal Bitcoins”, https://www.wired.com/2014/08/isp-bitcoin-theft/ 

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