Sebastian Seeber
email: sebastian.seeber@unibw.de

Gabi Dreo Rodosek

Gaëtan Hurel
email: gaetan.hurel@inria.fr

Rémi Badonnel
email: remi.badonnel@loria.fr

Analysis and Evaluation of OpenFlow Message Usage for Security Applications

With the advances in cloud computing and virtualization technologies, Software-Defined Networking (SDN) has become a fertile ground for building network applications regarding management and security using the OpenFlow protocol giving access to the forwarding plane. This paper presents an analysis and evaluation of OpenFlow message usage for supporting network security applications. After describing the considered security attacks, we present mitigation and defence strategies that are currently used in SDN environments to tackle them. We then analyze the dependencies of these mechanisms to OpenFlow messages that support their instantiation. Finally, we conduct series of experiments on software and hardware OpenFlow switches in order to validate our analysis and quantify the limits of current security mechanisms with different OpenFlow implementations.

Introduction

Software-defined networking (SDN) has become a major paradigm for network programmability with the large-scale deployment of cloud infrastructures and the virtualization of network functions. It currently provides a convenient support to the design and implementation of different services, including security mitigation mechanisms, through the abstraction of higher-level functionality. In particular, it is often perceived or expected as a potential solution for enabling fast reconfiguration operations in order to address the growing complexity of networking environments. Indeed, decision making processes can be facilitated at the SDN controllers level, e.g. about forwarding paths, based on the logical global view of the network that is abstracted and given to applications. Moreover, the close relationship between network intelligence and the forwarding plane enables a faster reply and a more flexible way to react to security incidents, in comparison to other traditional solutions.

The abstraction induced by software-defined networking poses also important security issues with respect to the reliability and dependencies of solutions that are built on top of them. This statement is even more critical when these applications using network programmability facilities are intended to detect or prevent security attacks. Typically, these solutions are based on the OpenFlow standardized protocol, which is one of the most prominent software-defined solutions for supporting communications between network controllers and programmable switches. It therefore plays a central role in the effective reliability of applications. However, the various implementations of this protocol react in different ways. For instance, the timing and count of OpenFlow messages may differ for hardware and software implementations and among multiple vendors, which may have a direct impact on the overall performances of software-defined applications. In that context, a major challenge is to analyze the dependencies of security solutions to software-defined networking protocols, such as the exploitation of OpenFlow messages. It is also important to evaluate their performance impact on different hardware implementations to draw conclusions about the effectiveness of security approaches based on OpenFlow messages. Otherwise, vendors of OpenFlow-based security applications are bound to specific hardware and thus dashes the expectations of software-defined networking with respect to open vendor independent and standardized interfaces.

The rest of this paper is organized as follows: Section 2 gives an overview of security attacks that have been considered in this analysis and describes SDNbased security mitigation currently available to address them. In Section 3 we analyze the dependencies of these security solutions in terms of OpenFlow message usage through a dedicated mapping. We then evaluate in Section 4 the performance of different OpenFlow implementations and the induced impact on security applications. Section 5 details related work in the area of softwaredefined security. Section 6 concludes the paper and points out several research perspectives.

Network attacks and SDN-based defences

Considering the traditional taxonomy of security attacks published in [START_REF] Hansman | A taxonomy of network and computer attacks[END_REF], our analysis has focused on SDN mitigation mechanisms for tackling two major categories of security attacks, namely overloading attacks and information gathering attacks. We remind in this section each of these categories and detail defence strategies designed in traditional and software-defined environments. These strategies will then serve as a basis for analyzing and quantifying the dependencies of security mechanisms to OpenFlow messages.

Mitigation of overloading attacks

These last years have seen an increase of overloading attacks, with in particular distributed denial-of-service (DDoS) [2] whose growth has been evaluated to 90 % in the last 12 months by a recent report from Akamai [START_REF]State of the Internet -Security Report[END_REF]. The main methods used in networking and software-defined networking are based on flooding techniques, where the attacker generates a very high amount of packets to overload the target environment. A typical example is given by smurf attacks which generate ICMP echo/reply packets, where the source IP address is spoofed, with broadcast networks to multiply traffic. Following this approach, a couple of lowbandwidth sources can easily kill high-bandwidth connections. The overloading attacks may also rely on amplification techniques. In that case, the approach consists in turning a small amount of bandwidth coming from a few machines into huge attacks targeted on a specific device. For instance, in the case of NTP (Network Time Protocol) amplification attacks, this is made possible by the fact that no authentication is required in order to obtain a response. Therefore, the attacker is capable of forging their address so that the generated request looks like it originated from the intended victims machine. The attacker sends forged requests to a large distributed number of servers across the network. Since the response is up to 200 times bigger than the request, a large attack can be initiated by simply a single machine, once amplified through a number of distributed NTP servers. Such type of response is possible due to the monlist command, which is available in NTP servers. This command can return the addresses of up to the last 600 machines that the NTP server has interacted with. The amplification factor of domain name service (DNS) is much lower and ranges of around 40 to 100 depending on the effort that the attacker puts into the preparation of its attack. An overview of typical bandwidth amplification factors is presented in [START_REF]US-CERT Alert (TA14-017A) UDP-Based Amplification Attacks[END_REF]. There exist many similar overloading attacks that are initiated via network, such as Teardrop, Bonk, Boink and Ping of Death. The impact is always to severely impair or disable an host or at least its IP stack, but through packet fragmentation techniques or vulnerability reassembling. However, these attacks require of course an host IP stack in order to receive packets from the attacker.

Mitigation strategies against overloading attacks within traditional networks are experiencing difficulties regarding their deployment, because most of them induce high network complexity and prohibitive operational cost [START_REF] Zargar | A survey of defense mechanisms against distributed denial of service (ddos) flooding attacks[END_REF]. In the meantime, SDN-based networks prove to be much more flexible due to their programmable nature. In an SDN-based network, the centralized view of the network state by the controller(s), as well as the capacity of the network to be dynamically reprogrammed, significantly ease the deployment of mitigation strategies, such as DDoS mitigation, initially designed for traditional networks. In particular, Moving Target Defense (MTD) is an intrusion prevention mechanism used to periodically change a deterministic attribute (typically the IP address) of a chosen host, in order to confuse attackers and thus protect the host. Usually, deploying MTD mechanisms within traditional networks is difficult and costly, because it involves the usage of dedicated hardware facilities for hosting the MTD intelligence [START_REF] Jajodia | Moving target defense: creating asymmetric uncertainty for cyber threats[END_REF]. In an SDN-based network, the MTD intelligence is hosted at the controller level, which is able of dynamically reconfiguring the network according to its dedicated algorithm [START_REF] Kampanakis | Sdn-based solutions for moving target defense network protection[END_REF]. Traffic analysis for intrusion and anomaly detection within a given network is another example of mitigation strategies simplified by the SDN paradigm [START_REF] Lara | Network innovation using openflow: A survey[END_REF]. In such a context, the controller can simply query the switches of the network in order to gather statistical information about the network traffic, and then detect potential intrusion or anomaly according to its detection algorithm(s). Once an attack has been detected, blocking the source of the attack or redirecting the associated malicious flows to security middleboxes -i.e. providing an intrusion responsecan be done at the controller level by reprogramming the whole network [START_REF] Sahay | Towards autonomic ddos mitigation using software-defined networking[END_REF]. Such reprogramming steps are important for implementing efficient intrusion tolerance mechanisms.

Mitigation of information gathering attacks

Another important category of attacks corresponds to information gathering. The one refers to the process of determining the characteristics of one or more remote hosts (and/or networks). Information gathering can be used to construct a model of the target host, and to facilitate future penetration attempts. There exist several and complementary methods to perform a remote information gathering in the literature at various levels:

-Host detection: this method tries to identify if a host is available. In most of the cases this is done by a ping or fping which elicits e.g. an ICMP ECHO REPLY from a victim. -Service detection: service detection is typically performed based on port scanning. The objective is to detect the availability of UDP, RPC or TCP services, e.g. HTTP, DNS, through the execution of SYN or FIN scanning or slight variations like fragmentation scanning. -Network topology detection: to get more information about a network, methods like TTL modulation, e.g. with traceroute or record route, e.g. ping -R can be performed. Another non-invasive method to learn more about a network is by network sniffing. -Operating system detection: since the implementations of TCP/IP stacks of operating systems are different, the behavior of such an implementation can give information about the concrete operating system. This could be an interesting information to get access to the victim system, because the attacker can determine which vulnerabilities are present and exploitable. An additional name for this method is TCP/IP stack fingerprinting.

In the past, information gathering was performed with a one to one or one to many model; i.e. an attacker performs techniques linear against either one target host or a logical group of targets (e.g. a subnet). These methods were often optimized for speed and executed in parallel (e.g. nmap). Newer types of information gathering methods use distributed methods following the many to one or many to many model. Therefore, an attacker tries to use multiple hosts to execute some information gathering methods in random and non-linear ways. The aim of the distribution is to avoid detection either by human analysis or network intrusion detection systems.

Mitigation strategies for information gathering attacks within SDN-based networks prove to be quite similar to the ones mentioned for traditional networks. The main difference resides in the holistic view of the controller(s), which may ease both the statistic aggregation and the correlation steps, as well as blocking (after detection) by reprogramming the network. For instance, in the case of Moving Target Defence (MTD) solutions mentioned above, the mechanisms make the attacker task harder, since the information obtained from a scanning attack at a period p may not be correct anymore at the period p+1. Some other advanced MTD mechanisms have been designed in SDN-based networks to add network noise, such as dynamic fake servers and fake open ports [START_REF] Jafarian | Openflow random host mutation: transparent moving target defense using software defined networking[END_REF], as well as to prevent OS fingerprinting and service version/banner grabbing. However, this last feature may induce overhead at the controller and/or the switch layer, since it requires to look and modify information in upper layers (e.g. httpd version in HTTP header), which might seem contrary to the SDN paradigm principles.

Analysis of OpenFlow Messages used for Network Security Applications

Mitigation strategies take benefits from facilities offered by software-defined networking, even when they rely on similar models and methods well-known in traditional networks. These solutions often built on top of the software-defined layer introduce however dependencies of security mechanisms to these facilities, in particular to the OpenFlow protocol, that we analyze in the section. We typically consider three main deployment categories in software-defined infrastructures: reactive, proactive and hybrid deployments. In all of them, a flow-table lookup is performed when a network flow reaches a switch. Depending on the implementation, e.g. software vSwitch or hardware switch (ASIC (Application-Specific Integrated Circuit)) flow tables are accessed. In case no matching flow is found a request to the controller is sent for further instructions. In a reactive approach, the controller acts upon these requests through the creation and installation of a rule in the switch's flow-table for the corresponding packet. In a proactive approach, the controller populates flow-table entries for all possible traffic matches possible for this switch in advance. This mode is comparable with typical traditional routing entries today, where all static entries are installed ahead in time. Following this proactive implementation, no request needs to be sent to the controller, since all incoming flows should find a matching entry. The major advantage of proactive deployments is due to the fact that all packets are forwarded in line rate (considering flow-table entries are stored in TCAM (Ternary Content-Addressable Memory) and no delay is added. In addi- Our analysis with respect to OpenFlow message usage for network security considers a reactive environment. Indeed, software-defined networking and in particular the OpenFlow protocol is typically leveraged for a dynamic reconfiguration and setup of the network. In addition, proactive deployments are quite inflexible. Therefore, proactive scenarios are often based on hybrid environments with a reactive part that is not necessarily activated. Our approach is applicable to all OpenFlow-enabled SDN environments that include a reactive part. This behavior allows us to gather and measure useful OpenFlow-related information, such as PACKET IN messages, which are necessary for several types of security related applications. Based on this consideration, and within a security context, we specified for each attack category, a mapping of the OpenFlow message types that are used for serving security functionalities, such as detection, mitigation and reconfiguration purposes. These security mechanisms therefore rely on the reliability of these messages and the information they carry (e.g. counters). We considered the following OpenFlow message types in this security-oriented analysis and mapping:

-PACKET IN messages: these are sent from the OpenFlow-enabled switch to the controller in case a new flow arrives at the switch and no matching flow-table entry is found. This behavior is useful for detection and mitigation approaches, like e.g. blacklisting or firewalling. In this case the number of new flows (e.g. IP addresses) can be counted (gathering stats on-the-fly) and if too many new IP addresses arrive, whether they are allowed or not this could be an indication for e.g. a DDoS attack or anomalous behavior in the monitored network. To gather these kinds of statistical data there, exist dedicated OpenFlow messages (e.g. MULTIPART REQUEST). Compared to those messages, gathering PACKET IN-based statistics is done on-the-fly for reactive environments inducing no additional OpenFlow communication between the controller and the switch(es). In proactive environments MUL-TIPART REQUEST messages can assume this task. -OFPFlowMod, OFPFlowStatsRequest / OFPFlowAggregateStat-sRequest messages: these are suitable for redirection and traffic mirroring. These messages can be useful to mirror traffic to different types of intrusion detection middleboxes or security appliances. In addition, there exist specific flags within these messages to reset packet and byte counters (OF-PFF RESET COUNT) in the switch or modify the configuration of a switch in a sense that it sends a message once a flow rule has expired. As a last usecase these messages can be used to mitigate an attack by dropping malicious packets. -OFPMeterMod / OFPMeterStatsRequest messages: these allow a rate-limiting configuration, which was originally designed for quality of service purposes. Nevertheless, this functionality can be used in the area of detection for sampling packets. -OFPQueueStatsRequest messages: these can be used to gather statistics from existing queues. In the area of security applications an option is to set up two queues: one queue for legitimate traffic with high bandwidth and one queue for suspicious and malicious traffic with a limited throughput. The process of setting up such a queue states part of prevention or mitigating an attack. The statistics collection part is relevant for detection purposes.

Using the set-queue attribute an application can set up a defined action (e.g. OUTPUT, DROP) for a specific queue. -Multipart messages: these provide plenty of options useful for detection purposes. Using the OFP*Stats[Request-Reply] messages, statistics about flows and rules can be gathered from the switches. These methods are useful for applications to detect, e.g. possible anomalies in the traffic flows.

In addition, considering pre-installed rule sets for security applications the statistics collection methods are necessary to derive possible security events.

To reduce false-positives in such a detection approach correlation methods need to be developed. -PacketOut messages: these enable forging packets and send them to security devices / middleboxes in order to reconfigure the network according to already detected incidents or to change configuration options to improve detection capabilities. -OFPFlowRemoved messages: these are suitable for security diagnosis and testing purposes. With associated counters involved they could also be useful to improve detection capabilities.

The different results of this security-oriented analysis of OpenFlow message usage are summarized in Table 1 corresponding to overloading mitigation strategies, and in Table 2 focusing on information gathering mitigation strategies. Keeping in mind these dependencies between security application goals (e.g. detection, mitigation, reconfiguration) and OpenFlow messages, there is a need to evaluate the implementation of OpenFlow messages in existing software-defined devices (software and hardware), in order to quantify the potential impact on these mitigation mechanisms.

Performance Evaluation

Based on this analysis, we have performed a series of experiments in order to evaluate the accuracy and reliability of OpenFlow messages. The objective of this quantification is then to infer the potential impact of this performances on security applications developed on software-defined networking infrastructures.

In that context, we have built dedicated testbeds based on hardware and software SDN solutions and have focused on two different types of messages, namely PACKET IN and OFPQueueStatsRequest messages. However, this approach is generic and can be easily applied to the other messages identified in the previous section. The main reason of this focus was to gather statistics comparable to NetFlow / sFlow data from an OpenFlow-enabled switch. We have considered the following experimental setup for performing our evaluation, with two different testbeds. Our first testbed consists of three workstations (4xCore i3 2.93GHz and 4 GB RAM) with the Debian 7 (kernel 3.2.0) operating system. All workstations have a gigabit network card installed that is connected directly to an HP2920-24G OpenFlow-enabled switch running the WB.15.16.005 firmware and OpenFlow version 1.3 enabled. On the switch, two workstations (W2 and W3) are connected within the same VLAN which is managed via the OpenFlow protocol. The other workstation(W1) directly connected to a switch port which is dedicated for OpenFlow controller messages (Open-Flow Management VLAN). For this purpose, the machine W1 is running an SDN controller. The Ryu framework in version 3.18 [START_REF] Ryu | Ryu sdn controller[END_REF] is chosen, because it supports OpenFlow version 1.3 and is well maintained. The motivation of having two workstations (W2 and W3) connected to each other is to replay pcap files containing attacks on one machine (W2) and receive attacks from the pcap on the other machine (W3). Thus, the machine W2 can be seen as an attacker and the machine W3 as the target. Figure 1a corresponds to the first testbed. A modification of the experimental setup was done to verify the behavior of a software switch. For this second testbed, we installed Open vSwitch [START_REF]vSwitch Community: Open vswitch[END_REF] on the machine W1 where the SDN controller with the Ryu framework is located and is connected to the Open vSwitch [START_REF]vSwitch Community: Open vswitch[END_REF] locally. Moreover, we installed an additional 2 port gigabit network card and bridged the ports via the Open vSwitch [START_REF]vSwitch Community: Open vswitch[END_REF] to connect the attacker (represented by the machine W2) and the target machine W3 (see Figure 1b corresponding to the second testbed). During our experiments, we replayed network traces derived from the DEFCON 22 hacking conference [START_REF]Defcon pcap traces[END_REF]. We used tcpprep in order to change IP addresses and simulate the traffic flow from the attacker workstation (W2) to the target workstation (W3). Furthermore, we deduced the statistics from the traces to assess the results with respect to OFPQueueStatsRequest messages. We modified the Ryu [START_REF] Ryu | Ryu sdn controller[END_REF] controller code so that no new flow rule is pushed to the switch and make sure that all PACKET IN messages are counted in time when they arrive at the controller. In addition, a flow-mod message is introduced during the initialization phase of the controller in order to insert a flow-rule that matches any packet (relevant for the OFPQueueStatsRequest messages evaluation).

In order to quantify the capacity of sending PACKET IN messages from the switch to the controller, we replayed traces at different speeds from the attacker workstation W2. We considered respectively the following bandwidth speeds: 0.1Mbps, 0.25Mbps, 0.5Mbps, 1.0Mbps, 2.0Mbps, 5.0Mbps, and 10.0Mbps. In order to verify the speed and number of packets on the attacker and target workstations, we used common Linux tools, namely ip -s link, iftop or nload. In parallel, we counted on our modified Ryu [START_REF] Ryu | Ryu sdn controller[END_REF] controller the number of OpenFlow PACKET IN messages. In order to test our modified Ryu [START_REF] Ryu | Ryu sdn controller[END_REF] controller script, we also counted the number of packets via the interface statistics on the workstation W1 on which the SDN controller is running. Based on these experiments, we evaluated the difference between the replayed packets and the effective received PACKET IN messages. We then calculated the percentage of received The results are given in Figure 2a and Figure 2b where we plotted the ratio of lost PACKET IN messages while varying the bandwidth used when replaying traces for respectively the HP 2920 hardware SDN switch and the Open vSwitch software SDN switch. The results clearly show that the distorsion can be quite important in both cases, even with the bandwidth dedicated to the generated traffic is low. When we compare the two figures, it appears that the phenomenon is even more important with the first testbed, corresponding to the hardware SDN switch in our case. In a second serie of experiments, we quantified the performance with respect to the OFPQueueStatsRequest messages. We assessed the counters for the installed flow rules. Figure 3a and Figure 3b illustrate the relationship between the bandwidth and the ratio of correct packet counters for the earlier mentioned HP switch and the Open vSwitch. We can observe on the figures a similar trend as the one obtained with the experiments with the PACKET IN messages. These results are particularly interesting, when we know that counters from matching flow-rules are preferably used to implement detection solutions, such as Defense4All [START_REF]Defense4All: Defense4all module[END_REF], a module for the commonly used SDN Controller OpenDaylight [START_REF]OpenDaylight: Sdn controller opendaylight[END_REF].

These results raise important concerns about the implementation of Open-Flow in hardware as well as software solutions, and the implication that may directly have these differences in the context of security applications. It highlights severe differences in sending OpenFlow messages from the SDN switch to the controller, which may significantly degrade the performance of security mitigation mechanisms implemented based on software-defined networks.

Related Work

Security aspects related to software-defined networking and its deployments have already been discussed by Schehlmann et al. in [START_REF] Schehlmann | Blessing or curse? revisiting security aspects of software-defined networking[END_REF]. Several approaches facing security using SDN concepts have also been proposed recently. Kreutz et al. [START_REF] Kreutz | Towards secure and dependable softwaredefined networks[END_REF] argue for building dependable and secure SDN applications. Therefore, they identify and describe current threat vectors in SDN environments that could be exploited. They then propose a general design to overcome the identified threats. Complementarily, Scott et al. [START_REF] Scott-Hayward | Sdn security: A survey[END_REF] investigate possible new security issues introduced through SDN and identify the affected layers. Focusing on network security approaches using SDN capabilities, François et al. [START_REF] François | Network security through software defined networking: a survey[END_REF] reviews recent research efforts and provides a qualitative comparison, complementary to our analytical and empirical evaluation. Furthermore, existing work has been focusing on more specific attacks and their mitigation. Shishira et al. summarizes several types of distributed denialof-service (DDoS) attacks and recently developed mitigation approaches in [START_REF] Shishira | Current trends in detection and mitigation of denial of service attacks-a survey[END_REF]. Vizváry et al. have analyzed the detection and mitigation of DDoS attacks using an OpenFlow enabled SDN environment in [START_REF] Vizváry | Future of ddos attacks mitigation in software defined networks[END_REF]. Using self-organizing maps, the authors of [START_REF] Braga | Lightweight ddos flooding attack detection using nox/openflow[END_REF] propose a method to detect DDoS attacks based on flow analysis. Feamster et al. [START_REF] Feamster | Outsourcing home network security[END_REF] investigated possibilities to detect botnet traffic by using distributed monitoring approaches. Jafarian et al. presented an approach to hide the real IP addresses by introducing a virtual IP address to hide real hosts from unauthorized scanners. A similar approach was introduced by Kampanakis et al. [START_REF] Kampanakis | Sdn-based solutions for moving target defense network protection[END_REF] to obfuscate the attack surface. Combining traditional network features (sFlow) and OpenFlow, Giotis et al. [START_REF] Giotis | Combining openflow and sflow for an effective and scalable anomaly detection and mitigation mechanism on sdn environments[END_REF] proposed a mechanism to detect anomalies and mitigate attacks by modifying flow tables. A different architecture for monitoring and SDN control was proposed by Zaalouk et al. [START_REF] Zaalouk | Orchsec: An orchestratorbased architecture for enhancing network-security using network monitoring and sdn control functions[END_REF] to enhance the development of security applications by separating control and monitoring functions. In addition, the architecture supports a controller-agnostic application development by decoupling application development from the SDN controller. Our work rather aims at highlighting the limits of current software-defined solutions for implementing and supporting these security solutions.

The increasing interest for software-defined networking has contributed to the development of dedicated security solutions. However, these solutions typically built on top of these infrastructures may suffer from the performance of supporting protocols, such as the OpenFlow protocol, and their different implementations. In that context, we have proposed in the paper an analysis and evaluation of OpenFlow message usage by network security applications, in order to quantify these dependencies and their impact.

We have first describe two categories of security attacks, namely overloading attacks and information gathering attacks, that are quite common in these environments, and have detailed regular and SDN-based mitigation mechanisms that have been designed for tackling them. We have then analyzed for each category the dependencies of these mechanisms to the OpenFlow protocol commonly supporting the communications between SDN controllers and switches. These dependencies have been identified through the mapping of OpenFlow messages to security functionalities in that context. Based on this analyzis, we performed series of experiments for comparing and evaluating the accuracy and reliability that can be expected with respect to these messages based on two different testbeds. We first considered OpenFlow PACKET IN messages that are typically generated when a new flow arrives to an SDN switch and no matching rule is found in the existing rule-set. We observed that the number of PACKET IN messages sent to the controller strongly depends on the line speed of flows sent to the switch. For a higher line speed, the switch was not able to send PACKET IN messages at the same speed when new packets arrived. This is particularly impacting, because this directly influences the statistics gathered from the switch, which are used by security solutions as a starting point for several detection approaches. We then performed experiments with respect to OFPQueueStat-sRequest messages that are used to provide statistics on existing queues, and observed a similar degradation of performance. When the line speed is high, the precision of counters per flow-rule can significantly decrease.

As future work, we are interested in performing complementary experiments, in order to extend our methodology to additional OpenFlow message types. This analysis will permit to further investigate the dependencies of security applications and their limits regarding SDN implementations. This could directly influence the design of these security mechanisms, and allow us to infer and specify guidelines and patterns with that respect, in order to maximize security performance.

  of new flows/packets (detection) FlowMod Traffic redirection and queuing (mitigation) PacketOut Confuse scanning by sending forged packets to the attacker

Fig. 1 :

 1 Fig. 1: Experimentation with SDN-enabled Software and Hardware Switches

Fig. 2 :

 2 Fig. 2: PACKET IN Message Ratio on SDN-enabled Switches

Fig. 3 :

 3 Fig. 3: Correct Packet Counter Ratio on SDN-enabled Switches

Table 1 :

 1 Mapping of OpenFlow messages to security functionality addressing overloading attacks tion, hybrid environments exist where the flexibility of a reactive environment for a set of traffic is used, while the low-latency forwarding (proactive) is used for the rest of the traffic.

	PACKET IN	Monitoring of e.g number of new flows (detection)
	OFPFlowMod	Traffic redirection and queuing (mitigation)
	OFPMeterMod	Rate-limiting (detection)
	OFP*StatsRequest	Detection based on statistics collection

Table 2 :

 2 Mapping of OpenFlow messages to security functionality addressing information gathering attacks

Acknowledgment

The authors wish to thank the member of the Chair for Communication Systems and Internet Services at the Universität der Bundeswehr München, headed by Prof. Dr. Gabi Dreo Rodosek, for helpful discussions and valuable comments for this paper. This work was partly funded by FLAMINGO, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme.


Davit Harutyunyan
email: dharutyunyan@create-net.org

Roberto Riggio
email: rriggio@create-net.org

Functional Decomposition in 5G Networks

Keywords: Mobile Networks, Functional Split, Component Placement

Mobile data traffic has been rapidly increasing over the last few years. To accommodate for such an ever-growing traffic demand, mobile network operators are required to perform costly network upgrades. Cell size reduction and network virtualization are known to be two of the most effective ways to increase capacity and lower the cost to deploy and operate future mobile networks. This PhD thesis will study the tradeoffs associated with the different approaches to small cell virtualization in terms of the point at which base stations operations are decomposed into physical and virtual. Different functional splits will be compared using mathematical optimization tools (e.g., Integer Linear Programming) while novel heuristics will be devised in order to tackle problems of practical size. Finally, selected results will be empirically evaluated over the 5G-EmPOWER testbed deployed at CREATE-NET premises.

Introduction

Recent advances in network virtualization enabled mobile network operators (MNOs) to move from the D-RAN (Distributed Radio Access Network) architecture, where base-band processing and radio elements are co-located, to the C-RAN (Cloud-RAN) architecture, where base-the band units are decomposed from the radio elements and are consolidated in large data-centers. The vaunted benefits of C-RAN are enhanced radio resource utilization and coordination across multiple cells enabled by the centralization of the radio resource management tasks. The downside of such high level of centralization lies in the tight bandwidth and latency requirements imposed on the fronthaul, i.e. the link interconnecting RRHs (Remote Radio Heads) with the BBUs (Base-Band Units), which can usually be satisfied only using fiber links.

Nevertheless, although the link between RRHs and BBU Pool has been used as demarcation point in the C-RAN architecture, other functional splits can be in principle defined (see Fig. 1), each of them coming with different requirements. In general, the lower the functional split is executed within the RAN protocol stack, the higher is the centralization benefits, however the fronthaul requirements become also more stringent. For example C-RAN enables an MNOs to implement Coordinated Multi-Point (CoMP) transmission and reception, while a split above the Medium Access Control (MAC) layer cannot support CoMP only allowing higher-layers cooperation features (e.g., joint scheduling). This PhD thesis will explore the trade-offs associated with the different functional splits, including, fronthaul requirements, centralization benefits, and deployment costs, with the ultimate goal of providing MNOs with a set guidelines to design cost-efficient mobile networks. In this paper we report on some preliminary results on the BBU placement problem over a reconfigurable wireless fronthaul while also presenting a roadmap for this PhD thesis.

Background

A detailed discussion on various functional splits can be found in [START_REF] Rost | Cloud technologies for flexible 5g radio access networks[END_REF][START_REF] Wubben | Benefits and impact of cloud computing on 5g signal processing: Flexible centralization through cloud-ran[END_REF][START_REF] Maeder | Towards a flexible functional split for cloudran networks[END_REF]. The authors of [START_REF] Rost | Cloud technologies for flexible 5g radio access networks[END_REF] propose a novel RAN as a Service concept in which the level of centralization is flexible and can be adapted to the actual service demands. Several functional splits are introduced and the associated fronthaul requirements are provided in [START_REF] Wubben | Benefits and impact of cloud computing on 5g signal processing: Flexible centralization through cloud-ran[END_REF]. The authors of [START_REF] Maeder | Towards a flexible functional split for cloudran networks[END_REF] survey several wired/wireless fronthauling technologies as well as the associated bandwidth and latency requirements for different functional splits.

Extensive work on C-RAN has been published in the recent years [START_REF] Namba | Colony-RAN architecture for future cellular network[END_REF][START_REF] Carapellese | Placement of base-band units (BBUs) over fixed/mobile converged multi-stage WDM-PONs[END_REF][START_REF] Holm | Optimal assignment of cells in C-RAN deployments with multiple BBU pools[END_REF][START_REF] Al-Obaidi | Optimizing Cloud-RAN deployments in real-life scenarios using Microwave Radio[END_REF]. In [START_REF] Namba | Colony-RAN architecture for future cellular network[END_REF] the authors propose the Colony-RAN architecture for cellular systems able to adjust the cell layout by dynamically changing the connections between BBUs and RRHs. An ILP problem is formalized in [START_REF] Holm | Optimal assignment of cells in C-RAN deployments with multiple BBU pools[END_REF] for optimizing the assignment of cells to different BBU pools. The authors of [START_REF] Al-Obaidi | Optimizing Cloud-RAN deployments in real-life scenarios using Microwave Radio[END_REF] derive a mathematical model for optimizing C-RAN deployments combining fiber and microwave links.

The amount of literature on VNE (Virtual Network Embedding) is humbling, a comprehensive survey on this topic can can be found in [START_REF] Fischer | Virtual network embedding: A survey[END_REF]. Likewise, also the amount of work on VNF (Virtual Network Function) placement is considerable [START_REF] Fischer | Virtual network embedding: A survey[END_REF][START_REF] Riggio | Virtual network functions orchestration in enterprise WLANs[END_REF][START_REF] Clayman | The dynamic placement of virtual network functions[END_REF][START_REF] Moens | VNF-P: A model for efficient placement of virtualized network functions[END_REF][START_REF] Mijumbi | Design and evaluation of algorithms for mapping and scheduling of virtual network functions[END_REF]. In [START_REF] Khan | SiMPLE: Survivability in multi-path link embedding[END_REF] SiMPLE is proposed to address the survivable VNE problem, exploiting a physical path diversity to provide survivability against single and multiple path failures. Similarly, the authors of [START_REF] Soualah | A batch approach for a survivable virtual network embedding based on Monte-Carlo Tree Search[END_REF] put forward a batch approach for survivable VNE. Joint node and link embedding algorithms are presented in [START_REF] Despotovic | VNetMapper: A fast and scalable approach to virtual networks embedding[END_REF][START_REF] Guerzoni | A novel approach to virtual networks embedding for SDN management and orchestration[END_REF]. A VNF placement problem is proposed in [START_REF] Riggio | Virtual network functions orchestration in enterprise WLANs[END_REF] for the radio access network, while a dynamic VNF placement problem is presented in [START_REF] Clayman | The dynamic placement of virtual network functions[END_REF]. The authors of [START_REF] Moens | VNF-P: A model for efficient placement of virtualized network functions[END_REF] consider a hybrid environment in which part of the services are provided by dedicated hardware. In [START_REF] Mijumbi | Design and evaluation of algorithms for mapping and scheduling of virtual network functions[END_REF] an online VNF scheduling and placement problem is formulated.

Research Statement

Figure 2 depicts the reference network architecture envisioned in this PhD thesis.

In the lower part of the figure we can see a traditional C-RAN deployment where all the BBUs are centralized and long fiber links are used in order to connect BBUs with RRHs (solid black lines). In the upper part of the figure instead, we can see the architecture envisioned in this work. In this case BBU Pools are co-located with macro cells and a reconfigurable wireless fronthaul is used to connect BBUs with RRHs (dashed black lines). A traditional backhaul is used in order to connect macro cells to the core network. This approach has the potential to reduce the length of the (expensive) fiber fronthaul links, thus improving operational and capital expenses, while still enabling advanced control and coordination mechanisms. This architecture will be the starting point for this PhD thesis and will be extended in order to accommodate for different functional splits and for different fronhauling technologies. For each functional split we will formulate an optimization problem and we will study the associated trade-offs. The key performance indicators will include energy consumption as well as network performance (throughput, latency) and resiliency. Scalable heuristics will be developed in order to study networks of practical sizes. We will compare the performances of the ILP-based placement algorithm and of the heuristics using a custom discrete event simulator implemented in Matlab and based on the results we will implement a particular split in the 5G-EmPOWER testbed deployed at CREATE-NET premises 1 . Finally, we will address the economical implications of the different splits with the overarching objective of providing MNOs a set of guidelines for designing and deploying future 5G networks.

Preliminary Result

As preliminary work we formalized and solved the BBU Placement problem over a reconfigurable wireless fronthaul. This approach is made possible by recent advances in microwave communications which allow for up to a few Gbps of bandwidth over short distances, (i.e., less than one Km). In the BBU placement problem the input consists of virtual network requests composed by a variable number of small cells and BBUs, whereas the substrate network provides the physical constraints in terms of bandwidth and computational capacity. In the evaluation we considered grid-shaped substrate networks and star-shaped virtual network request. We formulate the BBU placement problem as an ILP problem and we propose a greedy heuristic. The ILP problem formulation, including the objective function and the associated constraints as well as the details of the greedy heuristic, have been omitted due to space limitations. Simulations are carried out in Matlab. In this study we assume that a fixed number of requests are embedded sequentially onto the substrate network. Figure 3 shows the percentage of accepted requests and the average embedding cost for different substrate networks. As expected the ILP-based placement algorithm is more efficient than the heuristic in mapping the incoming requests. Nevertheless the performance gap, in this particular case, is relatively small while, as expected, the time required to embed a single request using the greedy heuristic is roughly one order of magnitude smaller than the time required to perform the same embedding using the ILP-based algorithm.

Conclusion

In this paper we presented a roadmap for a comprehensive study on the tradeoffs associated with different approaches to small cell virtualization in 5G mobile networks. The study will account for a broad range of key performance indicators ranging from energy consumption to deployment costs and will produce major results in terms of design guidelines and resource allocation algorithms for future mobile networks. Selected results will also be empirically evaluated over the 5G-EmPOWER testbed deployed at CREATE-NET premises.

Fig. 1 :

 1 Fig.1: Different functional splits for 5G small-cells[START_REF]Small cell virtualization functional splits and use cases[END_REF].

Fig. 2 :

 2 Fig. 2: The reference network architecture.

Fig. 3 :

 3 Fig. 3: ILP-based algorithm and heuristics performance for different networks.

http://empower.create-net.org/


Jessica Steinberger
email: jessica.steinberger@h-da.de

Benjamin Kuhnert
email: benjamin.kuhnert@h-da.de

Anna Sperotto
email: a.sperotto@utwente.nl

Harald Baier
email: harald.baier@h-da.de

Aiko Pras
email: a.pras@utwente.nl

In Whom Do We Trust -Sharing Security Events

Keywords: Sharing Security Events, Attack mitigation, Internet Service Provider, Network Security

Security event sharing is deemed of critical importance to counteract large-scale attacks at Internet service provider (ISP) networks as these attacks have become larger, more sophisticated and frequent. On the one hand, security event sharing is regarded to speed up organization's mitigation and response capabilities. On the other hand, it is currently done on an ad-hoc basis via email, member calls or in personal meetings only under the premise that participating partners are personally known to each other. As a consequence, mitigation and response actions are delayed and thus security events are not processed in time. One approach to reduce this delay and the time for manual processing is to disseminate security events among trusted partners. However, exchanging security events and semi-automatically deploying mitigation is currently not well established as a result of two shortcomings. First, the personal knowledge of each sharing partner to develop trust does not scale very well. Second, current exchange formats and protocols often are not able to use security mechanisms (e.g., encryption and signature) to ensure both confidentiality and integrity of the security event information and its remediation. The goal of this paper is to present a trust model that determines a trust and a knowledge level of a security event in order to deploy semi-automated remediations and facilitate the dissemination of security event information using the exchange format FLEX in the context of ISPs. We show that this trust model is scalable and helps to build a trust community in order to share information about threats and its remediation suggestions.

Introduction

Nowadays, large-scale cyber attacks (e.g., Distributed Denial of Service (DDoS) attacks) have become larger, more sophisticated (e.g., multi-vector attacks) and frequent [START_REF] Anstee | Worldwide Infrastructure Security Report[END_REF]. These large-scale cyber attacks are responsible for network and service outages and thus are causing brand damage and financial loss. To counteract these attacks, one approach that gained increasing attention in recent years is to semi-automatically disseminate cyber threat information among trusted partners [START_REF]Research and Education Networking Information Sharing and Analysis Center: REN-ISAC Research and Education Networking Information Sharing and Analysis Center[END_REF][START_REF]ACDC Deliverables[END_REF] to facilitate collaboration. However, current collaborative cyber defense is founded on an ad-hoc basis via email, member calls or in personal meetings and thus a manual process [START_REF] Reitinger | Enabling Distributed Security in Cyberspace[END_REF][START_REF]Internet Architecture Board and the Internet Society: CARIS Workshop Template Submissions[END_REF]. This slows mitigation and response times and impedes mitigation and reaction efficacy [START_REF] Morrow | DDoS Open Threat Signaling (DOTS) Working Group Operational Requirements[END_REF]. Besides the fact that collaboration and information sharing often only takes place in case participating partners are personally known to each other, some legally binding orders (e.g., Executive Order 1363 [START_REF]The White House: Executive Order -Improving Critical Infrastructure Cybersecurity[END_REF]8]) have been published recently that force owners and operators of critical infrastructures to establish procedures to increase the volume, timeliness and quality of cyber threat information sharing.

To improve the timeliness of cyber defense, support collaboration among trusted partners and facilitate the dissemination of security events, a common data representation and security mechanisms to establish trust are required. Even though several exchange formats (e.g., Incident Object Description Exchange Format (IODEF) [START_REF] Danyliw | The Incident Object Description Exchange Format RFC 5070[END_REF], Intrusion Detection Message Exchange Format (IDMEF) [START_REF] Debar | The Intrusion Detection Message Exchange Format (IDMEF) RFC 4765 (Experimental)[END_REF], Abuse Reporting Format (ARF) [START_REF] Shafranovich | An Extensible Format for Email Feedback Reports RFC 5965[END_REF], Extended Abuse Reporting Format (x-arf v0.1 and v0.2) [START_REF]x-arf Network Abuse Reporting 2.0[END_REF] and Flow-based Event eXchange Format (FLEX) [START_REF] Steinberger | Exchanging Security Events of flow-based Intrusion Detection Systems at Internet Scale[END_REF]) have been published [START_REF] Steinberger | How to Exchange Security Events? Overview and Evaluation of Formats and Protocols[END_REF] to exchange security events or incidents, the majority of the exchange formats and protocols do not provide any security mechanisms to sign or encrypt a security event [START_REF] Steinberger | How to Exchange Security Events? Overview and Evaluation of Formats and Protocols[END_REF].

Besides the lack of a standardized exchange format and protocol, the development of trust is deemed of critical importance to share security events. Despite well-known and established trust models are used in other application contexts, the personal knowledge of each sharing partner to develop trust in order to share security events does not scale very well.

To overcome the constraint of personal knowledge of each sharing partner to develop trust in context of mitigation and response to large-scale cyber attacks and to establish an effective collaboration among trusted partners, this paper presents a trust model, called MiRTrust. MiRTrust determines a trust and a knowledge level of a security event in order to deploy semi-automated remediations and facilitate the dissemination of security events using FLEX in the context of ISPs. MiRTrust is based on the well known PGP trust model [START_REF] Abdul-Rahman | A distributed trust model[END_REF][START_REF] Jonczy | A probabilistic trust model for gnupg[END_REF] and used to establish different levels of trust, determine the prioritization of the shared security event, sanitize the occurrence of security events and contributes to build a trust community in order to share information about cyber threats and its remediation suggestions.

The paper is organized as follows. In Section 2, we describe the scenario in which the trust model is going to be used. Next, we present the requirements that are derived from the presented scenario. Section 3 presents the foundation and related work. Our trust model MIRTrust is presented in Section 4. In Section 5, we evaluate our trust model MiRTrust. Finally, the paper is concluded in Section 6.

In this Section, we describe the main focus of this work. First, we define the networks in which we are going to place our trust model to facilitate the semiautomated assessment and deployment of remediation suggestions. Second, we define the requirements that a trust model should fulfill, as they emerged by the scenario described in Section 2.1. In the following, we will use these requirements to evaluate the trust model. Attacks targeting the trust model are out of scope of this work.

Scenario

The primary focus of this work are multiple high-speed networks using a link speed of 10 Gbps and higher [START_REF] Golling | Towards multi-layered intrusion detection in high-speed networks[END_REF]. In addition, we focus on network operators that cooperate among trusted partners to minimize or prevent damages caused by network-based attacks and use an automated threat information exchange. The collaboration is established using an infrastructure based overlay network [START_REF] Esposito | On security in publish/subscribe services: A survey[END_REF] to prevent a full mesh within the network and to ensure scalability. Each participating partner receives security events from different origins as shown in Figure 1. Security events originating from a detection engine within the own network infrastructure is defined as an internal security event and shown in Figure 1a. Further, each participating ISP possesses a list of directly connected collaborating partners. In case of ISP a a directly connected collaborating partner is ISP c as shown in Figure 1b. The networks of ISP b, ISP d and ISP e are not directly connected to ISP a and thus are regarded as external non collaborating partners as shown in Figure 1c.

Requirements

In this section, we introduce five requirements that a trust model should fulfill in order to establish collaboration among trusted partners. These requirements are derived from European Network and Information Security Agency's (ENISA) position paper no. 2 [START_REF]Reputation-based Systems: a security analysis[END_REF] and the work of [START_REF] Fullam | A specification of the agent reputation and trust (art) testbed: Experimentation and competition for trust in agent societies[END_REF].

Ease of Deployment: The trust model and its underlaying implementation should support platform independency to ensures that they easily integrates with the existing infrastructure.

Access control:

The trust model should support the use of the Traffic Light Protocol (TLP) [START_REF]'s United States Computer Emergency Readiness Team: Traffic Light Protocol (TLP) Matrix and Frequently Asked Questions[END_REF]. The reason is that the TLP provides a scheme for sharing different detail of information tailored for its intended receivers. The reason is that the amount of provided threat information depends on the trust and sharing relationship between collaborating ISPs.

Subjectivity:

The trust model should provide the possibility that network operators are able to form their own trust options. These trust options represent the Asymmetry: The trust model should support asymmetric levels of trust for both collaborating partners as they do not need to have similar trust in each other.

Decentralized: Each trust model within the mitigation and response (MiR) system should act as a self-contained unit and thus calculates its trust decisions locally. The MiR system should exchange these decisions in form of recommendations with its directly connected collaborating partners.

Related Work

In this section, we introduce the terminology by defining trust, review reputationbased trust models and analyze existing collaboration communities used to mitigate and response to large-scale attacks..

Terminology

Currently, there is no consensus in the definition of trust available. The authors of [START_REF] Grandison | Trust Management for Internet Applications[END_REF] reported that there are various definitions of trust based on the use-case context. In this paper, we adhere to the following definition of trust: "Trust is the quantified belief by a trustor with respect to the competence, honesty, security and dependability of a trustee with a specific context [START_REF] Grandison | Trust Management for Internet Applications[END_REF]." Besides trust, we also adhere to the following definition of distrust: "Distrust is the quantified belief by a trustor that a trustee is incompetent, dishonest, not secure or not dependable within a specific context [START_REF] Grandison | Trust Management for Internet Applications[END_REF]."

Collaboration communities

The majority of the collaboration communities are private communities that require a membership application and are charging an annual fee. Recent wellknown collaboration communities that require a membership application and are charging an annual fee are the Anti-Phishing Working Group (APWG), the Messaging, Malware and Mobile Anti-Abuse Working Group (M3 AAWG), the Research and Education Networking (REN) Information Sharing and Analysis Center (REN-ISAC) and the the Forum of Incident Response and Security Teams (FIRST). In contrast to the fee-based collaboration communities are non-fee-based collaborations. The Advanced Cyber Defence Centre (ACDC), the Gigabit European Academic Network (G ÉANT) Task Force on Computer Security Incident Response Teams 3 (TF-CSIRT) and the Gigabit European Academic Network (G ÉANT) Special Interest Group on Network Operations Centres4 (SIG-NOC) and the DDoS Open Threat Signaling5 (DOTS) working group within the IETF are well-known collaboration communities in context of security event sharing.

The collaboration of APWG focuses on eliminating the identity theft and fraud that result from the growing problem of phishing and email spoofing [START_REF]Anti-Phishing Working Group: Charter and Saga -Unifying the global response to cybercrime though data exchange, research and public awareness[END_REF]. M 3 AAWG is working against bots, malware, spam, viruses, DoS attacks and other online exploitation [START_REF]Messaging, Malware and Mobile Anti-Abuse Working Group: Member application[END_REF]. REN-ISAC is sharing sensitive information regarding cyber security threat, incidents, response, and protection located in United States, Canada and New Zealand [START_REF]Research and Education Networking Information Sharing and Analysis Center: REN-ISAC Research and Education Networking Information Sharing and Analysis Center[END_REF], and FIRST cooperatively handles computer security incidents and promote incident prevention programs from around the world. ACDC focus on detection, mitigation and response of botnets. Further, ACDC also supports the mutal data sharing between partners (e.g., ISPs, government agencies, law enforcement, research groups, industry partners). TF-CSIRT and SIG-NOC facilitates knowledge exchange and collaboration in a trusted environment in order to improve cooperation and coordination. DOTS is developing a standards based approach related to DDoS detection, classification, traceback and mitigation in context of a larger collaborative system at service provider level.

All of the aforementioned collaboration communities require and provide different level of memberships, whereas the fees vary from $250 to $25 000. In addition, each application initiates a review process which is performed by the community and decides about acceptance to join. Some communities perform collaboration following the following the Chatham House Rules6 (e.g., M 3 AAWG). The number of community members within a fee-based community vary from $200 to $1 800 and FIRST is mentioned to be the oldest and biggest international collaboration community for CERTs [START_REF]CERT cooperation and its further facilitation by relevant stakeholders[END_REF].

Reputation-based trust models

e-Commerce: The trust model of e-Commerce is often a centralized reputationbased system that rely on feedback of the involved parties. This feedback system is used in eBay, AirBnB, Booking and Amazon and is a primary resource for potential buyers to determine the trustworthiness of the seller. A feedback consists of comments and five different ranking levels to evaluate several aspects (e.g., price, condition, timeliness). Further, the overall feedback score consists of a positive, neutral or negative rating. A positive feedback adds +1, a negative feedback adds -1 and a neutral feedback 0 to the overall feedback score. To calculate the overall feedback percentage, the ratio of feedback scores is computed.

Web of Trust:

The trust model web of trust (WOT) describes a decentralized public-key infrastructure (PKI) relying on trust decisions of individual participants [START_REF] Jonczy | A probabilistic trust model for gnupg[END_REF]. It is used in PGP, GnuPG and OpenPGP. The basic WOT uses three levels of trust: complete, marginal and no trust. In addition, PGP, GnuPG and OpenPGP distinguish unknown trust from no trust and thus differentiate between 5 trust levels [START_REF] Abdul-Rahman | A distributed trust model[END_REF][START_REF] Jonczy | A probabilistic trust model for gnupg[END_REF]. Each participating partner owns a personal collection of certificates called the key ring and is allowed to sign a key for any other participant. [START_REF] Jonczy | A probabilistic trust model for gnupg[END_REF] reported that the trust model accepts a given public key in the key ring as completely valid, if either i) the public key belongs to the owner of the key ring, ii) the key ring contains at least C certificates from completely trusted certificate issuer with valid public keys and iii) the key ring contains at least M certificates from marginally trusted certificate issuer with valid public keys. The default values in PGP are C = 1 and M = 2, whereas GnuPG uses C = 1 and M = 3. The calculation of the trust level is described by [START_REF] Jonczy | A probabilistic trust model for gnupg[END_REF]as follows: The key legitimacy L = c C + m M , where c and m represents the number of certificates from completely/marginally trusted certificate issuers with valid keys. A key is completley valid for L ≥ 1, marginally valid for 0 < L < 1, and invalid for L = 0.

Trust model

Our mitigation and response trust model (MiRTrust) is based on hTrust [START_REF] Capra | Engineering human trust in mobile system collaborations[END_REF], a trust management model to facilitate the construction of trust-aware mobile systems and applications and on the PGP trust model [START_REF] Abdul-Rahman | A distributed trust model[END_REF][START_REF] Jonczy | A probabilistic trust model for gnupg[END_REF]. In contrast to hTrust, MiRTrust uses the four GnuPG [START_REF]The Free Software Foundation: Trust in a key's owner[END_REF] trust levels: unknown, none, marginal and full and additionally the trust level distrust. Moreover, MiRTrust takes into account the EU Trusted Lists [START_REF]European Commission's Directorate General for Communications Networks, Content & Technology: EU Trusted Lists of Certification Service Providers[END_REF] and the Alexa top 10 million websites list in order to extract the use of certification authorities using a 3 months average ranking. Unlike hTrust, MiRTrust does not consider contexts as the security events are identified in the context of ISPs and result from a large-scale attack.

MiRTrust consists of several input parameters (yellow colored) and three components: trust formation (blue colored), trust dissemination (brown colored) and trust evaluation (green colored) as shown in Figure 2. The component trust formation is responsible to determine the trustworthiness of a security event before a semi-automated mitigation and response action is taken. In case a security event from a new collaborating partner or an unknown source was received, the trust dissemination guarantees a minimum set of information upon the predication of trust can be calculated. The last component, trust evaluation, is responsible to continuously self-adapt the trust information kept in the ISP's local trust list. The quadruple can be described as follows: ISP a informs ISP b about a security event of type s occurring at time t. The sender of a security event is referred to as trustee, whereas the receiver of a security event is called trustor. ISP b is a trustor that forms a trust opinion about the trustee ISP a based on b's previous trust experiences with a. The process to form a trust opinion about a trustee is shown in Figure 2. The trust experiences are stored locally at each MiR system and are described by a 6-tuple: (a, b, s, l, k, t). The tuple can be described as follows: ISP b trusts ISP a at level l about the security event type s in context of large-scale attacks. The trust level l is denoted as l ∈ [-2, 2], whereas -2 represents distrust, -1 represents unknown trust, 0 represents no trust, 1 represents marginal trust and 2 represents full trust. In accordance to [START_REF] Capra | Engineering human trust in mobile system collaborations[END_REF], MiRTrust also considers only partial knowledge about the trustworthiness of collaborating partner. The reason is that only directly interconnected networks are collaborating and thus their trust opinions contain a level of uncertainty. This uncertainty is expressed as knowledge k and varies from a trust based decision do not trust to a lack of evidence based decision do not know. The knowledge k is denoted as k ∈ [0, 1], whereas 0 represents unknown and 1 perfect knowledge. Both, the trust level l and the knowledge k is retrieved from local settings and past experiences. The better the experience in the past, the higher the trust level l and the knowledge k. To relate trust and knowledge to time, MiRTrust uses the variable t to refer at which time t the trust t and knowledge k was calculated.

Local settings: In a first step, MiRTrust computes a trust range Υ [lb, ub] and an initial knowledge value based on the origin of the security event. In case of an internal security event Υ [lb, ub] is set to Υ [1, 2] and the knowledge value is set to k = 1. The trust range of security events originating from external collaborating partners is set to Υ [0, 1], where as the trust range of security events originating from external non collaborating partners is set to Υ [-2, 0]. The knowledge value of security events originating from external collaborating partners is set to k = 0.5 and from external non collaborating partners to k = 0. Next, MiRTrust takes into account several local settings ls. The basic setup of MiRTrust considers three local settings: ls 1 = check CA list, ls 2 = ask collaborating partners and ls 3 =check previous security event database (DB) that all evaluate to a boolean value. ls 1 describes if IP addresses or domains within the security event are listed on the merged CA list. This CA list combines the EU Trusted list and the used certification authorities of the Alexa top 10 million websites. ls 2 describes whether the behavior that cause the security event has also been seen in collaborating partner networks [START_REF] Steinberger | Collaborative DDoS Defense using Flow-based Security Event Information[END_REF]. ls 3 refers to security events with similar behavior that have been received and stored previously.

Trust formation: The trust formation enables a trustor to predict a trustee's trustworthiness before mitigation and response actions are initiated. Therefore, the function p is used to calculate a trust value as shown in Equation ( 1

w i • c(ls i ), c(ls i ) = Υ lb if ls i = 0 Υ ub if ls i = 1 (1)
Next, MiRTrust looks up the sender of the security event in the local trust list. In case, the sender is listed within the trust list, the previous level of trust within the trust list and the current level of trust of the function p are compared. If | prev. l -curr. l | > 1, the sender is marked as suspicious. Otherwise, the past trust experiences v and the current trust value p are aggregated using the weighted average, as the trust experiences evolve over time. The trust level l is set to l = v+p 2 . In case, the sender is not listed within the trust list and thus no aggregated trust experience tuple is available, collaborating partners are asked for recommendations r. As a recommendation is transfered over the network, it uses encryption to ensure confidentiality and a signature to prove the recommendation's authenticity. Thus, the current trust value p and the trust value of the recommendation r are aggregated depending on the quality q of the recommendation and determined as shown in Equation [START_REF]Research and Education Networking Information Sharing and Analysis Center: REN-ISAC Research and Education Networking Information Sharing and Analysis Center[END_REF]. Only those recommendations are considered that provide a quality q greater than a minimum level of trust. In addition, only recommendations with a time stamp t(p) > t(r) are used. The trust value rl takes into account the inherent knowledge uncertainty k of the given recommendation. T represents the time interval in which security events are observed and the total number of security events.

q i = max l min , l i • k i • max 0, T -(t n -t) T (2)
Due to the collaboration, multiple recommendations r n are received. Therefore, a unique recommendation trust value rl is computed using a weighted average of the individual trust range of the recommendations with a quality greater than the minimum level of trust as shown in Formula (3) [START_REF] Abdul-Rahman | A distributed trust model[END_REF].

rl(r 1 , . . . , r n ) = 1 n n i=1 l i • q i |q i > l min (3)
rl and the current trust value p are aggregated using the weighted average. The trust level l is set to l = p+rl 2 .

Trust dissemination: The trust formation is used to predict the trustworthiness of an ISP. In case no aggregated tuples are available, an ISP exchanges recommendations r with its collaborating partners to guarantee a minimum set of information to decide about the trustworthiness. As a consequence, recommendations contain sensitive data that require the use of security mechanisms (e.g., encryption & signature). Therefore, the exchange format FLEX is used to disseminate the recommendations.

Trust evaluation: MiRTrust continuously updates its local settings during the occurrence of a security event and based on the received recommendations. These updates are included with equal weight to ensure that a trust opinion can not change rapidly (e.g., caused by false good recommendation). In case a recommendation r is received that conflicts with the own calculated trustworthiness, the level of trust of ISP x is not aggregated into previous trust opinions and ISP x is marked as suspicious. In case, several security events of ISP x occur with conflicting trustworthiness, the level of trust of ISP x tends to drop to -2, that represents distrust and thus identifies x as an ISP with a suspect behavior. As a consequence, recommendations of x will be disregarded.

Evaluation

In this Section, we describe the qualitative and quantitative evaluation of our trust model MiRTrust. First, we describe the characteristics of the evaluation criteria. Second, we introduce five evaluation criteria for our trust model. Further, we evaluate MiRTrust using multi-method-modeling, describe the setup of the testbed and present the test scenario of the trust model. Finally, we present and summarize the results of the evaluation.

Qualitative evaluation methodology

The trust model MiRTrust is evaluated based on the following five criteria: Ease of deployment, authorization, subjectivity, asymmetry and decentralization. These criteria were derived from the requirements described in Section 2.2. The criterion 'Ease of Deployment' describes the ability to use the trust model and its underlying implementation on different operating systems, infrastructure devices, exchange formats and protocols. The criterion 'authorization' refers to the ability to support the TLP protocol. The 'subjectivity' describes the possibility that network operators are able to form their own trust opinions. The criterion 'asymmetry' describes the possibility that two collaborating partners do not need to have the similar trust in each other. The criterion 'decentralization' refers to the ability that each participating ISP acts as a self-contained unit, calculates and stores its trust decisions locally.

Quantitative evaluation methodology

MiRTrust is evaluated using a multi-method-modeling approach consisting of an agent-based and a discrete event model using AnyLogic 7 . The model of MiRTrust is based on a scale-free network of ISPs that share security event information and perform mitigation actions based on the trust and knowledge level of each security event. The ISPs are modeled as agents. Each ISP has an individual behavior and attitude towards the trustworthiness of a sender of a security event. The process of mitigation is modeled in a discrete event way at each single ISP.

Initially, MiRTrust models a weekly contact rate to describe the assumption that 1% of potential ISPs will want to join the MiRTrust community. Besides this contact rate, non-community members are able to join the community by using a sponsoring join process. Each community member possesses a list of directly connected collaborating partners and assigns an initial trust value range of [0, 1] and a knowledge value of 0.5. Based on the findings in [START_REF] Steinberger | Collaborative Attack Mitigation and Response: A survey[END_REF], each ISP receives 5 security events per month. The sender of the security event is set using a triangular distribution. This triangular distribution is used to create security events sent from an internal detection engine of an ISP, an external collaborating ISP and an unknown ISP. Based on the sender of the security event, an ISP starts its trust formulation calculation and looks up its past trust experiences w 1 with the sender of the security event. In case no trust experiences are available and thus no previous security events have been exchanged between the sender and receiver of the security event, the receiving ISP asks its collaborating partners to send recommendation tuples about the trustworthiness of the sender. Therefore, ISPs interact and share their trust experiences. Further, MiRTrust takes into account a local created trusted CA list w 2 and if this security event has also been seen by collaborating partners w 3 . These local settings are weighted based on the formula (1) as follows: w 1 = 0.5, w 2 = 0.15 and w 3 = 0.45 with w 1 + w 2 + w 3 = 1, 0 ≤ w i ≤ 1. Next, the trust level and the knowledge values are calculated. Finally, mitigation and response actions are deployed, if the trust level pass a threshold of 0. The duration of the mitigation process is set using a triangular distribution with lower limit a = 20 and upper limit b = 1440 minutes. These mitigation values are derived from [START_REF] Steinberger | Collaborative Attack Mitigation and Response: A survey[END_REF]. Finally, the ISPs are waiting for the next occurring security event that restarts the trust formation process.

Evaluation results

In this paragraph, we present and discuss the results of the qualitative and quantitative evaluation of MiRTrust.

Ease of Deployment: The heterogeneity of network devices and used operating systems requires a platform independent trust model that easily integrates within the existing infrastructure. Therefore, the implementation of MiRTrust is based on Java and thus can easily be deployed on different operating systems. Further, MiRTrust encodes its recommendation tuples in FLEX. The dissemination of those tuples among trusted partners is using STOMP and thus ensures platform independency.

Access control: MiRTrust supports the semi-automated dissemination of security threat information based on the different level of trust. Therefore, MiRTrust differentiates between the following five different trust levels: distrust, unknown, none, marginal and full trust. The use of different trust levels allows to encode security event information using the TLP protocol and thus provide different detail of information within a security event tailored for its intended receivers. The trust level distrust, unknown and none trust are mapped to the color red of the TPL protocol. The color amber is used to encode the trust level margial trust and the color green is used to represent full trust. Decentralization: MiRTrust is deployed at each collaborating partner and thus acts as a self-contained unit that calculates and stores trust opinions locally. Further, the recommendation tuples are transfered to collaborating partners using FLEX and thus are signed. Each ISP is able to form its own trust opinion about collaborating partners similar to the principle of web of trust.

Conclusion

Nowadays, large-scale cyber attacks have become larger, more sophisticated and frequent. One approach to mitigate and respond to large-scale network-based attacks focuses on collaboration. In this paper, we introduced the trust model MiRTrust that facilitates the semi-automated assessment and deployment of remediation suggestions within a security event. MiRTrust is used to determine different levels of trust, set the prioritization of the shared security event, sanitize the occurrence of security events and contributes to built a trust community in order to share information about cyber threats and its remediation suggestions. We have shown that MiRTrust is able to support the formation of a subjective and asymmetric trust level and can be used to encode cyber threat information using TLP for dissemination. Based on our qualitative and quantitative evaluation, MiRTrust constitutes a viable and collaborative approach to assess the trust level of collaborating ISPs and thus deploy semi-automated remediations of a security events.

Fig. 1 .

 1 Fig. 1. Origin of security events

Fig. 2 .

 2 Fig. 2. Trust level calculation of MiRTrust

  ). p uses a weight w to emphasize the importance of a local setting ls. The importance of these values are defined by each participating ISP. The function c(ls i ) is used to decide which value of the trust range Υ [lb,ub] is multiplied with weight w. p(w 1 , . . . , w n , ls 1 , . . . , ls n , Υ [lb,ub] ) = n i=1

( a )Fig. 3 .

 a3 Fig. 3. Distribution of trust levels

11 Fig. 4 .

 114 Fig. 4. Asymmetric trust level

http://www.geant.org/Innovation/SIG_TF/Pages/TF-CSIRT.aspx

http://www.geant.org/Innovation/SIG_TF/Pages/SIG-NOC.aspx

https://datatracker.ietf.org/wg/dots/charter/

https://www.chathamhouse.org/about/chatham-house-rule

Acknowledgment. The work has been funded by CASED and by EU FP7 Flamingo (ICT-318488).


Siri Fagernes
email: siri.fagernes@westerdals.no

Alva L Couch
email: couch@cs.tufts.edu

Scalability and Information Exchange among Autonomous Resource Management Agents

Keywords: resource management, autonomous agents, cloud management, reactive approaches, decentralized knowledge

We study a scenario of autonomous resource management agents, aiming for fulfilling a management goal of balancing value of service with cost. We aim for a model of management based on fully distributed knowledge, avoiding traditional challenges associated with centralized approaches. Our results indicate that lack of information about the actions of other agents can be mitigated via direct observation of each agent's environment.

Introduction

We present a theoretical model of distributed resource management, which is analysed through simulations. The model involves autonomous agents that must collaborate, either directly or indirectly, to achieve a common management goal (balance cost and value). Our previous work has focused on studying the coordination of only two agents, whose primary task is to control resource usage in the system they operate, and try to estimate, based on varying information access, how to adjust their current resource level optimally.

In this paper, we study the coordination of a larger group of autonomous resource management agents, in the setting where they share a common resource pool. The main research objective is to determine whether the agents can achieve their common goal in an optimal manner without exchanging local information with each other. We see that individual observations of behaviour observed by each agent can replace information exchanged directly among the agents, which increases scalability.

Related Work

An automatic resource management process can be either reactive [START_REF] Harold C Lim | Automated control in cloud computing: challenges and opportunities[END_REF] or predictive, determined by how resources are automatically adjusted. The predictive approaches are typically based on having access to a complete model of the system, which (in theory) gives the ability to provide QoS guarantees and a more detailed view of the dynamics of the system. The major challenge of such approaches is getting access to such knowledge, if it is even possible. Examples of model-based approaches are [START_REF] Dawoud | Elastic vm for cloud resources provisioning optimization[END_REF], [START_REF] Roy | Efficient autoscaling in the cloud using predictive models for workload forecasting[END_REF], [START_REF] Gong | Press: Predictive elastic resource scaling for cloud systems[END_REF], [START_REF] Vasić | Dejavu: accelerating resource allocation in virtualized environments[END_REF], [START_REF] Shen | Cloudscale: elastic resource scaling for multi-tenant cloud systems[END_REF] and [START_REF] Sharma | A cost-aware elasticity provisioning system for the cloud[END_REF].

Reactive approaches are designed to make appropriate decisions when one lacks complete knowledge of the system model, and are used in complex systems for decision making. A common challenge in reactive approaches is that the learning algorithm responsible for making decisions requires a training period for gathering data to make appropriate action decisions. Examples of reactive approaches are presented in [START_REF] Harold C Lim | Automated control in cloud computing: challenges and opportunities[END_REF], [START_REF] Padala | Adaptive control of virtualized resources in utility computing environments[END_REF], [START_REF] Demberel | Reflective control for an elastic cloud application: an automated experiment workbench[END_REF], [START_REF] Meng | Tide: achieving selfscaling in virtualized datacenter management middleware[END_REF], [START_REF] Rodrigo N Calheiros | The aneka platform and qos-driven resource provisioning for elastic applications on hybrid clouds[END_REF], and [START_REF] Jose | Dynamic multicore resource management: A machine learning approach[END_REF].

Most of the existing approaches are based on centralized knowledge. This means they have the advantage of one component having complete system knowledge, which avoids the complexity of coordination and communication overhead in distributed approaches. However, centralized approaches in larger complex systems -cloud systems -have several drawbacks, including limited scalability, single point of failure issues, and potential bottlenecks.

Method and Approach

Our management scenario consists of ten autonomous resource management agents Q i , i ∈ [START_REF] Harold C Lim | Automated control in cloud computing: challenges and opportunities[END_REF][START_REF] Meng | Tide: achieving selfscaling in virtualized datacenter management middleware[END_REF], where Q i controls a separate resource variable R i . Each resource variable (or component in the system) contributes to delivering a service S. The main objective of management is to achieve efficient management of all the different system resource variables, with the objective to achieve a balance between cost and produced value. To determine value of the delivered service, the performance metric P represents job throughput, i.e., the reciprocal of response time. The response time will depend on how the system is able to cope with current load, which is defined as an arrival rate of requests. The system performance is hence defined as the request completion rate, and is modeled approximately as

P = B - γL R (1)
where B is the baseline performance (the performance when the system is not affected by load). γ is a constant representing resource-intensitivity, i.e. increased γ represents a service in which the service requests are more resource-intensive. Further, we define associated value of service to be proportional to throughput, so that

V = αP = α 10 i=1 P i . (2)
Similarly, cost C is proportional to resource use R, so that The autonomous agents (resource controllers), which are responsible for making decisions on resource use and adjustments, do not have access to knowledge of this theoretical model of the system's performance. Each agent observes how system value V changes with changes in R i , ∆V /∆R i , and based on the local knowledge of associated cost C(R i ), the closure operator can make an estimate of how net value N = V -C changes with R i , by calculating ∆N/∆R i . If this value is positive, the controller will increase R i , and if it is negative, decrease R i . This hill-climbing strategy will converge to a global optimum whenever the objective function N is convex.

C = βR. (3)
The agents have a perception of how system value depends on resource use. The theoretically correct global value is defined as

V = α(B - γL R 1 - γL R 2 -. . . - γL R 10 ) (4)
In our experiments, the agents assume that the value-resource relationship is modelled as

V = a L R + b. (5)

Results

When each operator receives individual value feedback, no external information about other operators is needed. When the operator has a semi-accurate model of the system dynamics and current system load, all operators perform very close to optimal, as seen in Figure 1.

Providing less information (no load information) reduces the precision of the results (Figure 2a), but the performance (achieved net value) is quite close to the theoretical optimum (Figure 2b).

Conclusion and Further Work

Although there has been significant research efforts aimed at achieving fully decentralized management of larger complex systems, most proposed solutions so far has been based on either pure centralization or partly centralization based on delegation of responsibility. Our work has been an attempt to achieve pure decentralized management. The goal of our approach is trying to come up with an intermediate approach between delegated management and agent based management, in which there is higher predictability and more accurate goal achievement. This study indicates that to achieve self-optimising behaviour among autonomous agents working towards the same goal, without direct coordination, excessive information exchange or centralized knowledge, is the ability to monitor their invidual behaviour. This means that developing efficient feedback mechanisms is a crucial factor to reduce the need for global information exchange.

One particular issue that we have not studied, is how the precision of our proposed model is affected by more heavily varying system load. Also, to test the robustness of the model, this needs to be implemented in a real scenario.

Fig. 1 :

 1 Fig. 1: 10 operators, each controller has information about current load. γ = 1 for all agents.

Fig. 2 :

 2 Fig. 2: 10 operators, each controller lacks information about system load. γ = 1 for all agents.


Aiko Pras
email: a.pras@utwente.nl

Christian Dietz
email: christian.dietz@unibw.de

Anna Sperotto
email: a.sperotto@utwente.nl

Gabi Dreo
email: gabi.dreo@unibw.de

How to Achieve Early Botnet Detection at the Provider Level?

Keywords: Botnet, Early Detection, Provider Network, DNS, IP Flow Monitoring, Coordinated Cyber Threats, Domain Registration Behaviour

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Botnets are an enabler for many cyber-criminal activities and often responsible for DDoS attacks, banking fraud and cyber-espionage. As reported in [START_REF]McAfee: The Economic Impact of Cyber-crime[END_REF][START_REF] Mossburg | A Deeper Look at the Financial Impact of Cyber Attacks[END_REF] such criminal activities cause substantial economic damage. Recent estimations [START_REF] Taylor | Cyber Attacks Fallout Could Cost the Global Economy 3 Trillion Dollar by 2020[END_REF] expect that cyber attacks could cost global economy $3 trillion by 2020. Botmasters use various techniques to create, maintain and hide their complex C&C infrastructures. First, they use P2P techniques [START_REF] Andriesse | Highly resilient peer-to-peer botnets are here: An Analysis of Gameover Zeus[END_REF] and domain fast-flux to increase the resilience against take-down actions. Second, botnets encrypt their communication payload to prevent signature based detection [START_REF] Rossow | Provex: Detecting Botnets with Encrypted Command and Control Channels[END_REF].

However, botnets often use the domain name system (DNS) [START_REF] Antonakakis | From throw-away traffic to bots: Detecting the rise of DGA-based malware[END_REF][START_REF] Nguyen | DGA Botnet Detection using Collaborative Filtering and Density-based Clustering[END_REF][START_REF] Kwon | PsyBoG: A Scalable Botnet Detection Method for Large-scale DNS Traffic[END_REF], e.g., to find peers and register malicious domains. Since, botmasters manage a large distributed overlay network, but have limited personal resources, they tend to automate domain registration, e.g. using domain name generation algorithms (DGAs) [START_REF] Yadav | Detecting Algorithmically Generated Domain-flux Attacks with DNS Traffic Analysis[END_REF]. Such automatically generated domains share similarities and possibly appear to be registered in close temporal distance. Such characteristics will be used for bot detection, while their deployment is still in preparation.

Hence, the goal of this PhD research is early detection of botnets to facilitate proactive mitigation strategies. Using such a proactive approach prevents botnets from evolving their full size and attack power. As many end users are unable to detect and clean infected machines, we favour a provider-based approach, involving ISPs and DNS registrars. This approach benefits from its overview of the network that allows to discover behavioural similarities of different connected systems. The benefit of tackling distributed large-scale attacks at provider level has been discussed in [START_REF] Steinberger | Anomaly Detection and mitigation at Internet scale: A survey[END_REF] and demonstrated by [START_REF] François | FireCol: A Collaborative Protection Network for the Detection of Flooding DDoS Attacks[END_REF]. Further, initiatives to incentivize ISPs to mitigate botnets are already ongoing [START_REF] Lone | Towards Incentivizing ISPs to Mitigate Botnets[END_REF]. In addition, several studies discuss and high-light the role of ISPs in detection and mitigation of various cyber threats, e.g. DDoS, Botnets or SPAM [START_REF] Steinberger | Collaborative Attack Mitigation and Response: A Survey[END_REF][START_REF] Asghari | Economics of Fighting Botnets: Lessons from a Decade of Mitigation[END_REF][START_REF] Van Eeten | The role of Internet Service Providers in Botnet Mitigation an Empirical Analysis based on Spam Data[END_REF].

The work done in [START_REF] Hao | Understanding the Domain Registration Behavior of Spammers[END_REF] addresses the domain registration behaviour of spammers and [START_REF] Grill | Detecting DGA Malware using NetFlow[END_REF] demonstrated DGA based malware detection by using flow-based techniques. In contrast, our approach includes the detection of malicious DNS registration behaviour, which we currently analyse for the .com, .net and .org domains. These domains represent half of the registered Internet domains. By combining DNS registration behaviour analysis with passive monitoring of DNS requests and IP flows, we are able to tackle botnets throughout their whole life-cycle. This research is still in its initial state and will result in a PhD thesis.

The remaining parts are structured as follows. Section 2, describes the research problem and questions. Section 3, describes our approach. Next, Section 4 provides early results and the current state of research. Finally, the paper is concluded in Section 5.

Research Problem & Questions

The goal of this research is to enable early botnet detection in provider environments. To achieve this goal, our approach is based on large-scale DNS registration behaviour analysis, as this will allow to discover botnet activity in the (pre-)deployment phase of its life-cycle (see Fig. 1). Thus, our novel approach could possibly prevent the botnet from becoming deployed and actively used. Furthermore, the proposed approach takes into account the dynamics of botnet malware and the Internet infrastructure, high data rates, incompleteness of data and encrypted bot communication. In order to tackle the early botnet detection problem, we ask the following questions: RQ 1: How do botnets interact with the domain name system? RQ 2: Can domain registration characteristics be used for botnet detection, and if yes, how? RQ 3: (How) Does early detection work, if some registrars do not cooperate?

The approach used for answering these research questions will be described in the next Section. Fig. 1 shows the bot life-cycle and relating research questions. The goal of this research is to allow faster botnet detection and mitigation. Current approaches are usually limited to detect bots after they already became active or while they are used in attacks. Our approach targets botnet detection in the pre-deployment phase. Therefore, our approach is based on two components: (1) passive monitoring of communication characteristics and (2) DNS registration behaviour analysis. DNS registration analysis allows to detect the preparatory actions of deployment of the C&C infrastructure and the bots. Therefore, our approach allows botnet early detection and consequently facilitates proactive botnet mitigation. In addition, our approach allows botnet detection in the subsequent phases of the bot life-cycle (preparation, infection, peer discovery, malware update, command propagation and attack) by using passive DNS and flow monitoring solutions. This is important, since bots might also be registered at domain providers that are not sharing data.

Approach

Research question 1 aims to get insight into the deployment and management of botnets. Therefore, we collect DNS registration data on a daily basis for the .com, .net and .net domains, representing half of the domains registered on the Internet. Second, we query different botnet tracking services and use DGAs to find botnet related records in the domain registration dataset.

Research question 2 aims to extract characteristics of botnets in their deployment phase. Which might allow an early detection and mitigation. To answer this question, we use registration databases of top level domain registrars. Currently, our study involves the .com, .net, and .org top level domains.

Research question 3 extends our novel approach to make it applicable in case bots are registered under domains that do not share data. In such cases, our approach might derive flow-based behaviour characteristics based on the knowledge gained in RQ1 and RQ2 for flow-based detection of bots. Flow monitoring solutions provide an overview of large parts of the Internet, in which we expect to find similarities that can be used for detection of bot behaviour.

We will validate our novel approach based on simulations and real-live environments. Further, we compile different datasets. First, we crawl the registration database of multiple top level domains, different botnet domain and IP blocklists with time stamps. This allows us to measure the temporal difference between botnet deployment and detection. Second, we passively capture IP flow data and DNS requests in multiple provider networks to evaluate (a) how accurate our approach can detect the large-scale similarities between distributed bots and (b) determine the temporal delay between malicious domain registration and the first activity. This evaluation also uses IP and DNS blocklists.

Early Results

In a first step, we used data captured from Kelihos sinkholing operation, that allowed us to observe real bots in two different states of their life-cycle, peer discovery and job requests. We successfully used our insights gained to developed a concept for flow-based detection. Further, we use multiple DGAs and C&C domain lists to extract the botnet domains (e.g., Zeus, Kelihos.B, Palevo, Drye). Early results show that botnet domains are registered in close temporal distance (bulk registration) and often have structural similarities. Thus, we assume that our approach will be able to accurately detect malicious DNS registration activities and host behaviour of bots.

Final Considerations

When provider based solutions are used for bot detection, it is important that data should be accurate and be derived characteristics should be independent of the capture infrastructure. However, as botnets are globally spread, usually one provider can only detect a fraction of a botnet. Therefore, the detection system should run and cooperate across multiple provider networks, by means of providing infrastructure independent detection information and being able to use such data from different networks. ISPs often apply sampling to their flow monitoring to reduce memory consumption, which might be an additional challenge to our approach. Moreover, anti-detection techniques of malware become more sophisticated and often involve encryption and anonymisation techniques. Our approach will be resistant against many of these techniques, due to its high-level overview and independence of packet payloads. The main goal of this approach, should be achieved within a period of four years as part of a PhD thesis.

Fig. 1 .

 1 Fig. 1. Detailed overview of botnet operations with mapped research questions.

Acknowledgments This work is partially funded by EU FP7 Flamingo Network of Excellence Project (ICT-318488).