Experimental Deployment of the ARTEMIS BGP Hijacking Detection Prototype in Research and Educational Networks
The proposal "Experimental Deployment of the ARTEMIS BGP Hijacking Detection Prototype in Research and Educational Networks" is also available in PDF.
Principal Investigators: Alberto Dainotti Alistair King
Funding source: OAC-1848641 Period of performance: September 1, 2018 - August 31, 2019.
1 Introduction, Motivation and Goals
2 Background and State of the ArtAutonomous Systems (ASes) use the Border Gateway Protocol (BGP) to advertise their IP prefixes and establish inter-domain routes in the Internet. BGP is a distributed protocol, lacking authentication of routes. As a result, an AS is able to advertise illegitimate routes for IP prefixes it does not own. These illegitimate advertisements propagate and "pollute" many ASes, or even the entire Internet, affecting service availability, integrity, and confidentiality of communications. This phenomenon, called BGP prefix hijacking can be caused by router misconfiguration or malicious attacks . Events with significant impact are frequently observed, highlighting - despite the severity of such Internet infrastructural vulnerability - the ineffectiveness of existing countermeasures. For example, on the 6th of November 2017, millions of Comcast subscribers in the US could not use the Internet for approximately 90 minutes because of a prefix hijacking incident.
Evasion. None of the detection approaches in literature is capable of detecting all attack configurations (nor can they be easily combined), thus allowing sophisticated attackers to evade them. We propose a modular taxonomy describing all variations of attack scenarios and we use it to carefully analyze detection comprehensiveness of related work. ARTEMIS significantly overcomes limitations of the state of the art by covering all attack configurations in the context of a classic threat model.
Accuracy. Legitimate changes in the routing policies of a network (e.g., announcing a sub-prefix for traffic engineering or establishing a new peering connection), could be considered suspicious events by the majority of third-party detection systems avoid this, operators would need to timely inform third parties about every routing decision they make and share private information. On the other hand, adopting a less strict policy to compensate for the lack of updated information and reduce false positives (FP), incurs the danger of neglecting real hijacking events (false negatives - FN). We designed ARTEMIS detection to be run directly by the network operator without relying on a third party, thus leveraging fully and constantly (and potentially automatically) updated information that enables 0% FP and FN for most of the attack scenarios and a configurable FP-FN trade-off otherwise.
Speed. A side effect of the inaccuracy of third-party approaches is the need for manual verification of alerts, which inevitably causes slow mitigation of malicious events (e.g., hours or days). Few minutes of diverted traffic can cause large financial losses due to service unavailability or security breaches. On the contrary, the ARTEMIS approach is a fully automated solution integrating detection and mitigation, allowing an AS to quickly neutralize attacks.
Privacy and Flexibility. One of the issues that impedes the adoption of third-party detection is privacy, e.g., ISPs usually do not disclose their peering policies. Similarly, operators are sometimes reluctant to adopt mitigation services requiring other organizations to announce their prefixes or tunnel their traffic. ARTEMIS offers full privacy for detection and the option to achieve self-operated mitigation. Another factor affecting willingness to externalize mitigation is cost. Trade-offs between cost, privacy, and risk may be evaluated differently by the same organization for distinct prefixes they own. Leveraging the availability of local private information and its fully automated approach, ARTEMIS offers the flexibility to customize mitigation (e.g., self-operated or third-party-assisted) per prefix and per attack class.
3 Proposed TasksWe have already identified few candidate networks that support research, education and no-profit activities in the US and we will select at least two participants to collaborate with in the course of the project. Operators that have already expressed their interest and commitment to collaborate include Internet2 , Great Plains Networks and MERIT Networks . To achieve the goals highlighted in Section 1, we will organize our collaboration with each operator into a series of tasks that might be iterated at different stages as well as carried out in partial overlap, depending on the lessons learned during the project execution, the challenges that arise, and the potential solutions we identify.
File translated from TEX by TTH, version 4.03.
On 20 Nov 2018, 12:57.