Team

Overview

...

& 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 for network administrators, that allows them to detect in real-time and automatically mitigate prefix hijacking incidents against prefixes under their administrative control, by 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 attack within a few seconds, and (b) completely mitigate the hijack within a few minutes (e.g., 2-5 minutes in the initial experiments on the real Internet 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.

...

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

...

Architecture

...

& functionality

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

...

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).

Demo

...

topology

 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.

...

• 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).

JSON

...

configuration file

The JSON configuration file (network-cfg.json) 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

• prefixes:List consisting of prefixes with their AS-PATH information and (optionally) legitimate MOAS ASes.

• prefix: a CIDR representation of the prefix that is monitored/protected.

• paths: a list of dictionaries that contain the ASN of the protected AS (origin), along with a list of dictionaries for the neighbors.

• neighbor: list of dictionaries that contain each neighbor's ASN and a list of ASNs for the neighbor's neighbor.
  For example, in the demo topology the protected (origin) AS65004 sees the AS65002 as a first-hop neighbor, and AS65001 as a second-hop neighbor (resulting in the legitimate announced path AS65004 - AS65002 - AS65001).
  Note: While the operator can supply the origin and first-hop neighbor ASNs as ground-truth in the configuration, the N-hop (N > 1) neighbor information is planned to be generated automatically by ARTEMIS in future versions of the tool, based on the received BGP updates.
  

• moas: *in-progress*

...

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

Running the

...

demo

As a first step, start from a clean setup of an Ubuntu 16.04 virtual machine, with at least 12 GB HD space, 2 processors, 3 GB of RAM and a single NATted interface.

...

Fig. 6: Current configuration of R4.

 Future plans

...

& extensions

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 video using GNS3 as emulation platform

Fig. 7: The fully emulated GNS3 demo topology.

...

ONOS

...

technical steering team presentation

...

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

...