Page History

...

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

1) The detection monitoring service runs continuously and combines provides control plane information from the AS itself, Periscope [7] (an LG API), the streaming services of RIPE RIS [4] and BGPstream BGPstream [6] (from RIPE RIS and RouteViews) [6], as well as BGPmon [5] and Periscope [7], which return in (near) almost real-time BGP routes/ updates for a given list of prefixes and ASNs. By combining multiple sources, the

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

3) When a prefix hijacking is detected, ARTEMIS automatically launches its mitigation service. Since the "golden rule" of routing is that in Internet routing the most specific prefix is always winspreferred, ARTEMIS modifies the BGP configuration of the routers so that they announce de-aggregated 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 de-aggregation deaggregation is effective for hijacks of IP address prefixes larger less specific than /24, but it might not work for /24 prefixes , as or more specifics. This is because BGP advertisements of prefixes more specific than /24 prefixes are typically filtered by many ISPs, as since it is considered as best practice in order to avoid the exponential increase of the size of the global 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 de-aggregation deaggregation in mind, it can support several extensions related to its monitoring, detection and mitigation modules mechanisms due to its modular design. These extensions, e.g., employing MOAS (Multi-Origin AS Announcements) and /or remote peering tunneling in order to attract 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, a an additional monitoring service is running envisioned to provide real-time information about the mitigation process. This service uses again can also use data from Periscope, RIPE RIS, BGPstream and BGPmon to monitor/visualize the mitigation.

...