Conceptos teóricos de la energía eólica

In this thesis, we evaluate the resiliency of various switch flow rule eviction policies. We demonstrate the attack vector exposed by the First in First Out (FIFO) eviction policy and examine for attack resiliency, three other policies that could be imple- mented in place of FIFO. Extending the concept of switch intelligence, demonstrate that increasing the intelligence of the SDN switch can improves the resiliency of the

network against both malicious and legitimate controller saturation.

While we present a prototype here, we do not propose that the switch augmenta- tions presented here represent a complete solution for an intelligent switch. In this section we acknowledge the space for further improvements, suggesting further work that could be done in line with what is presented within this thesis and outside of that scope as well.

6.2.1

Switch Flow Rule Eviction

We expand the concept of Switch Based flow rule eviction to look at other poli- cies that could be implemented in place of the FIFO policy of OpenFlow 1.4. We evaluate the Least Recently Used, Least Frequently Used and Random Replacement policies, concluding that the Least Recently Used policy presents the most resilience to an attacker aiming to remove legitimate flow rules from the switch.

We draw inspiration for the flow rule eviction policies from the CPU cache re- placement problem. The policies evaluated here are by no means the totality of the proposals for cache replacement. Several other policies have been implemented and evaluated within the CPU cache sphere which could be ported to the switch flow rule replacement problem [147][187][188]. One such example is the Time Aware Least Recently Used [189], a variation of LRU which considers the life span of cache content in deciding eviction. Since in most cases in SDN, rules either have an idle or hard timeout in the switch, this may prove to be a viable and well suited alternative policy. Alternatively, hybrid flow rule eviction policies which combine attributes from one or more eviction policies could also be implemented. This concept would seek to combine the best attributes of multiple policies. One example of such is a Least Frequently Recently Used policy, which could combine the best of both worlds in the Least Frequently Used and Least Recently Used policies by considering the popularity of a flow rule but balancing it with the recency of its use so that “dead” flows which were once heavy hitters do not remain in the switch longer than they should.

6.2.2

Load Distribution

To demonstrate the viability and benefits of smarter SDN switches, we implement and evaluate two designs for control plane load distribution performed by the switch. In both designs, the switch selects a single controller out of the pool of connected controllers for its next flow request. This reduces the redundancy in the system (the switch is no longer forwarding all requests to all controllers) and enables the switch to get better service out of the controllers with which it is connected.

The proposals in this thesis focus solely on the aspect of flow requests being sent into the control plane. With this focus, the switch ignores the issue of propagation of network updates between the controllers. All controllers should be able to main- tain an accurate view of the flow table states of each switch under its control at all times. Our system does not currently consider this factor as it is outside of the scope of this project. While we specify that there should exist an inter controller communication system within the control plane to handle this, additional work on this module could look at its own communication protocol with the controllers to inform the others when one installs a flow into the switch table. Such a commu- nication system is also useful for integration of the switch load distribution system with other controller-based defenses. Defense systems for the SDN network which assume all flow requests pass through it (e.g [99] and [106])could be subverted by a switch based load distribution system which actively chooses where to send flow requests. It may cause them to miss out on key statistics when monitoring. This could be handled within the control plane defense system by having the controllers propagate information among each other to ensure the decisions are made using ac- curate information. Careful consideration must be given to the risk of removing the benefits of the load balancing by bombarding the controllers with updates within such an implementation, however.

6.2.3

Malicious Packet in Filter

The Random Forest Packet in Classifier and Filter presents the largest opportunity for expansion of the work done in this thesis. As part of our switch intelligence aug- mentation proposal, we implemented and evaluated a packet in filter in the switch which enables it to distinguish malicious from legitimate flow requests using Ran-

dom Forest classification and drops the malicious flow requests.

We highlighted the necessity of extracting from the attack immutable charac- teristics which an internal attacker cannot easily subvert without compromising the effectiveness of his attack. Training data for legitimate requests was gathered using several publicly available network traces and training was performed offline. This was done in absence of network generated training data specific to the network the filter would be employed on. The “training” portion of this filter concept is yet to be fully explored. The opportunity remains for implementation of a module which records the network behaviour under normal circumstances, allowing it to quickly detect when the behaviour of its own network has changed. Such a module could periodically record the behaviour of the ports it is connected to as “legitimate ac- tivity” and use this as its training data (online training). In this way, the switch is not reliant on another network’s “good behaviour” to determine good behaviour in its own environment.

Additionally, since the switch performs its filtering and protection of the network in relative isolation (without interacting with the controller), further work in this area should include updates to the controller regarding switch activity. This may take the form of periodic messages to the controller informing it of the number of attack packets blocked, or may involve sending a sample of the attack packets to the controller for verification of accurate filtering. This is to ensure the controller has an accurate view of the traffic in the network and can take its own actions in keeping with network policies to address the attack if necessary.

6.2.3.1 Limitations

The attacker model our Packet in Filter aims to protect against is an internal host which has been compromised or infected by malware. Detecting traditional DoS attacks or external attackers attempting to perform SDN focused attacks are both outside the scope of this thesis. There are several other systems which focus on both of these attacks within the SDN sphere and we propose that the filter in this system be made to work in conjunction with these other systems. We exclude ingress ports and ports connected to servers (e.g web server) from classification as they, by nature, generate a large number of flow requests within an abnormally short space of time

when compared with a host connected port. Systems such as [104] which monitor for external attackers by examining the entropy of destination addresses would be useful to implement alongside.

6.2.4

Further Switch Intelligence

We present in this thesis several augmentations for an SDN switch, increasing its in- telligence to increase the resilience of the network. We by no means claim to present a complete solution here however, and the opportunity exists for further increases in functionality of the switch. With a focus on relieving the burden on the controller, many new ideas can be implemented into the switch. Previous examples include AVANT-GUARD’s TCP attack filter [117] and Statesec [122] which detects DDoS attacks on hosts in the network. Further augmentation could allow the switch to monitor for Man In The Middle attacks or for packet signatures of malware. The switch could be envisioned not only as a forwarding device, but as a gatekeeper for the SDN network, blocking malicious activity of all sorts before it has chance to enter the network.

Controller Malfunction Detection, one attribute of an intelligent switch not im- plemented in this thesis, could be carried out by an extension of the Load Aware load distributor, which infers the load on a controller. It can also be expanded upon to make further inferences about a controller. A controller repeatedly assessed by several switches to be under high loads could be indicative of an attack in progress that the controller is unable to take action against or a Byzantine failure of some sort within the controller which is causing it to respond slowly. The switches could then inform the other controllers that feedback from this controller has been low and should be checked. Low response rates could also imply a controller behaving maliciously. Such a controller may appear to have a high number of unanswered requests to the switches, which could then alert other controllers to potential mali- cious behaviour from that controller.

Despite the potential benefits presented by augmenting the switch’s intelligence, the greatest care must be taken to preserve the switch’s core functionality: packet forwarding. Whatever additional functioning the switch is enabled to do should not

compromise its ability to quickly forward packets to their destinations.

Finally, we acknowledge the difficulty of hardware deployment for these and any other ideas which augment the switch. Within the SDN paradigm, the controller is meant to be easily configurable, with switches acting almost like an embedded system with limited functionality. The idea of intelligent switches flies in the face of this concept as it calls for switches that can be easily modified to increase their abilities. This is easily done in software switches such as Open vSwitch. It is significantly more difficult to convince vendors to include custom functionalities in hardware switches. Similar adoption difficulties were also acknowledged when the ideas of separated control and forwarding planes in hardware switches were first conceived [18]. Nevertheless, just as the OpenFlow protocol created a pseudo- standard which vendors could implement and allow for switch interaction with a centralised control plane, this presents an opportunity for a standard framework to be implemented in switches which enables modification of the functionality post deployment. Such a framework would allow network admins and programmers to easily alter what a switch does upon receiving a packet.