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.
...
ARTEMIS Architecture and Functionality
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.
...
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). Fig. 1: The ARTEMIS architecture.
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.
...