Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
Prefix hijacking is a common phenomenon in the Internet that often causes routing problems and economic losses [13]. ARTEMIS [1,10] is a tool that enables 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 is based on the real-time monitoring of BGP data in the Internet and can completely mitigate a prefix hijacking within a few minutes (e.g., 2-5 minutes in the initial experiments with the PEERING testbed [2]) after it has been launched. 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 the ARTEMIS system 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 test the system 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 it's best path selection algorithm is required in order to fully grasp the idea behind ARTEMIS. However, the demo can be followed/tested without this knowledge.
ARTEMIS operation is achieved by following a number of relatively simple steps, which are presented and thoroughly explained.
ARTEMIS: System Description
...
prefixes:List consisting of prefixes with their AS-PATH information and legitimate MOAS ASes.
prefix: a CIDR representation of the prefix to monitorthat is monitored/protected.
paths: a list of dictionaries that contain an the ASN of the origin of the prefix and 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 AS has origin ASN of 65004 and a neighbor with ASN 65002 who also has a neighbor with ASN 65001 (65004 - 65002 - 65001).moas: *in-progress*
frequency:Polling interval in milliseconds for the detection mechanism to check the memory-stored BGP Update update messages. In the demo configuration, it is set to check every 3 seconds (3000 milliseconds).
monitors: List of the route collectors that the application ARTEMIS is using for monitoring. Right now it supports RIPE and ExaBGP route collectors through socket-io, and is extendable to include more monitoring services.
RIPE Route Collectors have specific identifiers ("rrc17", "rrc18", "rrc19", "rrc20"). You can use configure them like following this example: "ripe" : ["rrc17", "rrc19"]
exabgpAn ExaBGP route collector is implemented inside the tutorial folder and you . You can deploy it by running an exabgp an ExaBGP instance with the exabgp.conf and server.py files provided (will need changes require modifications in directory paths). In the demo topology we have an ExaBGP speaker running on 192.168.1.2:5000.
Note: The demo configuration also includes configuration for the SDN-IP and the Reactive-Routing application. It specifies where the BGP Speaker speaker is located and which are our local prefixes.
...
The picture that follows shows the topology that is setup via the topo.py file inside the tutorial folder. The BGP Speakers 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.
...
AS65001
Intermediate AS that consists of a BGP Speaker speaker (R1), a L2 switch, a host (H1) and an ExaBGP Route Collector (RC).R1: Announces 10.0.0.0/8 and is a neighbor of AS65003 and AS65002. Also, it has the exaBGP RC as an iBGP neighbor and propagates BGP Update update messages to it.
ExaBGP RC: RC connected to R1 but also to the ONOS Controller controller on the protected AS (in real world this connection is done through the underlaying underlying network; the only limitation is that the IP endpoint of ONOS should have a non-hijacked IP address so that the monitor can reach ONOS during the hijack).
H1 / 10.0.0.100: Host which is going to be communicating with the host inside the protected AS. It is going used to provide us a visualization of the data-plane behavior when the BGP Hijack hijack occurs.
AS65002
Intermediate AS that consists of a BGP Speaker speaker that announces 20.0.0.0/8 and its purpose is to add an additional hop to the AS-PATH so that the protected AS is hijackable (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 preferences in AS65001)path attribute of the BGP best path selection algorithm, is able to steal the traffic.AS65003
Hijacker AS that consists of a BGP Speaker speaker (R3).R3:Announcing from this BGP Speaker By announcing the prefix of the protected AS (40.0.0.0/8) will cause from this BGP speaker, we trigger a BGP hijack, and all trafic traffic generated from AS65001 and directed towards AS65004, will be redirected to the network of AS65003.
AS65004
Protected AS that is running employing ONOS. It consists of a BGP Speakerspeaker, an OVS switch, a Host host and the ONOS instance.R4: Bgp Speaker BGP speaker announcing 40.0.0.0/8. It is connected with his neighbor through the OVS switch which is configured by the sdnthe SDN-ip IP application to talk with the BGP speaker of AS65002.
OVS: Talks with ONOS on a management interface in via 192.168.0.0/24 subnet.
ONOS: ONOS is connected with the BGP speaker to retrieve the BGP routing table. Also, it receives the BGP Update update messages from the ExaBGP router and . Also, it has a link with the OVS switch in order to send the flow rules and receive the packet insinteract 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.
...