How to use Software-‐Defined Networking to Improve Security – a Survey Jorge Proença, Tiago Cruz, Edmundo Monteiro, Paulo Simões Universidade de Coimbra, Portugal
[email protected] [email protected] [email protected] [email protected] Abstract: Despite being a relatively recent development, the SDN paradigm has already challenged the established network design, management and operation concepts. SDN is the result of a number of studies and ideas on network programming, oriented towards the improvement of the traditional network functionality and management, due to its unique levels of flexibility. One of the main characteristics of this paradigm is the breakout of the functionalities of traditional network elements (e.g., routers), moving part of them to a centralized controller. Network elements such as routers become simpler forwarding devices, and the controller becomes responsible for routing decisions. This allows the controller to have complete perspective and control over the network. Moreover, network changes become seamless, as the controller can change the network behaviour online. In this paper we present an overview and survey on the usage of the Software Defined Networking (SDN) concept for security purposes, discussing how to use to increase network security awareness, as well as for reacting to ongoing attacks. This survey analyses research studies that are representative of a variety of security measures that can be improved by the use of SDN enabled technologies. We address network security in four distinct fields: SDN-‐enabled honeypots, Denial-‐of-‐Service (DoS) mitigation, source address spoofing countermeasures, and network scanning avoidance. Keywords: Software Defined Network, SDN, Network Security, IP spoofing mitigation, DoS Spoofing Mitigation, Network Scan Avoidance, Honeypot 1. Introduction Software defined networking (SDN) is an architectural approach to network configuration and management which allows for unprecedented levels of flexibility, also enabling the implementation of evolved network virtualization scenarios. The SDN paradigm aggregates a number of studies and ideas about network programmability (Feamster 2013). In SDN routers and switches (forwarding elements) the control plane is decoupled from the forwarding plane, with the former moved to a central controller. Packet forwarding is flow oriented, meaning that both origin and destination are taken into account, instead of just packet destination (as in traditional networking). Flow policies are granted by a centralized controller, which manages the policies of a range of forwarding elements in a given network. Using this controller, control plane functions can be moved out of the forwarding element. For this reason, the controller will have a broader view of the domain, contrasting with the narrow (localized) view that an individual forwarding element has in traditional networks. As a result, this paradigm enables the creation of more flexible management mechanisms, especially suited for complex scenarios. The interface between the central controller and the forwarding elements (routers, switches) is usually based on the OpenFlow protocol (Greene 2009). While SDN is frequently leveraged to address the operation and management needs of applications such as on-‐the-‐fly network virtualization, it can also provide an effective mechanism for security applications. In fact, SDN not only improves network deployment and management, but also simplifies network security tasks in an efficient manner. Part of this is due to the fact that a centralized element with a global view of all the network entities – such as devices, flows and network elements – is able to provide more efficient information gathering and security reaction mechanisms, especially when compared with the narrow local view individually provided by each forwarding element in traditional IP networks, where constant data pooling is needed to
monitor the whole network state. This broad view of the network and ability to easily receive information from all forwarding elements can be used to provide better security methods without adding new and specific protocols (which can be a deterrent for their adoption) such as in VAVE source address spoofing countermeasure (Yao 2011). Moreover, flow-‐based forwarding rules used in SDN networks can help detecting suspicious connections and increase the efficiency of a reaction. With its flexible nature, the controller can seamlessly isolate or divert flows. Instead of blocking an attack, SDN allows an easier redirection of traffic. This is useful to extend existing techniques, improving their effectiveness, such as adding a layer of anomaly detection to remote triggered black holes (RTBH). This flexibility can also be used to improve a honeypot’s efficiency which may become active – meaning the whole system has a higher probability of detecting the attack and then to easily redirect it to the honeypot (rather than having a static honeypot passively listening on the empty scope of the network). SDN can also help handling Denial of Service (DoS) and Distributed DoS (DDoS) attacks, by providing more effective detection and reaction mechanisms. In this paper we discuss a representative sample of proposals of using SDN to improve a number of security fields ranging from avoiding attacks to their detection, namely: SDN-‐enabled honeypots, Denial-‐of-‐Service (DoS) mitigation, source address spoofing countermeasures, and network scanning avoidance. We also compare these samples with traditional techniques, which do not use an SDN approach. This is not an exhaustive analysis, but rather a survey of representative use cases related to the use of SDN technologies for security purposes. The remaining sections are ordered as follows. Section 2 explains the conceptual vision of a network into three separate planes. Section 3 gives an overview of SDN networking and compares it to traditional networking approaches. Section 4 discusses security improvements that SDN can bring to networking and Section 5 concludes the paper. 2. Software Defined Networking Overview This section intends to provide a technical background on SDN technologies and its related concepts, with the main purpose of supporting the survey study that will be introduced in the next chapter. Hereby we describe the main characteristics of SDN, including its conceptual division of networking planes and how it compares with traditional networking. 2.1 The three planes of networking From a functional standpoint, network architectures can be split across three fundamental planes: Management, Control and Data (Kreutz 2014, Ellanti 2005). Each plane has a well-‐defined purpose and specific set of characteristics (Figure 1): § The management plane relates to traffic used by software services, for provision, maintenance, and monitoring. Traffic related to this plane can be either transported through in-‐band (using the same connections as user traffic) or out-‐of-‐band (OOB) connections (a separate connection, exclusively dedicated to management operations) (Schudel 2007). § The main role of the control plane (also known as signalling plane) relates with the setup of the data plane, also encompassing the traffic between network elements. For example, routers use routing protocols to exchange network information, so that each router knows where to forward a packet for it to reach its destination. Control plane traffic includes signalling, routing information, and link-‐state protocols, among other types of traffic (Schudel 2007). § The data plane (also known as user plane, forwarding plane, carrier plane or bearer plane) is in charge of transporting user data. This means that the traffic belonging to the data plane never has source or destination IP addresses belonging to the network elements (e.g., switches and routers). It will have addresses belonging to end devices, such as computers and servers. Traffic in this data plane uses
network as transport only. The main objective of the other conceptual network planes is to support the operation of the data plane (Schudel 2007).
Management Plane
Control Plane
Data Plane
Figure 1: Network Planes. Adapted from (Kreutz 2014) This functional division is traditionally handled in such a way that control and data planes are frequently kept in close coupling, within the scope of network equipment. For instance, in a conventional Ethernet switch, the forwarding plane is integrated with the control plane – the MAC address table is maintained by the embedded electronics that constitute the packet forwarding engine. This corresponds to the conventional networking paradigm, which is challenged by SDN. 2.2 Software Defined Networking Overview The term SDN (for “Software Defined Networking") was first introduced in (Greene 2009), referring to the OpenFlow protocol being developed at the University of Stanford (ONF 2014) , which eventually became one of the first SDN-‐enabling standards. SDN breaks with the existing vertical integration that is characteristic of the traditional networking model, by decoupling of the control and data planes (Kreutz 2014). In SDN, the control plane is moved away from the forwarding elements (i.e., routers), and placed in a logically centralized controller. This does not imply a physical concentration of functionality, as the controller functions can be performed by several controller instances to improve scalability and resilience (Yeganeh 2013). The data plane remains in the forwarding elements, whose task becomes focused only on traffic forwarding. The forwarding elements can have multiple purposes and can perform the role of several devices (e.g. router, switch, and firewall) depending on the configuration provided by the controller. These changes allow the controller to have a broader view of the network, comparing with the narrow view each individual router has in traditional networks – where each router has limited scope of visibility, provided by their closest neighbouring routers and other elements (e.g. static routes). The broader view of the SDN controller allows networks to become more flexible and more manageable, with network changes becoming a simpler task. Additionally, packet forwarding is flow oriented, meaning both origin and destination are taken into account, instead of just packet destination as in traditional networking. Figure 2 illustrates the flow rule table of the OpenFlow protocol.
Flow policies are granted by a centralized controller, which manages the policies of a range of forwarding elements in a given network. Using this controller, control plane functions can be moved out of the forwarding element. For this reason, the controller will have a broader view of the domain, contrasting with the narrow view that an individual forwarding element has in a traditional IP network.
Rule
Action
Statistics Packet+ byte counters
-‐Forward packets to ports -‐Encapsulate and forward to controller -‐Drop the packet -‐Send to normal processing pipeline
Switch Port
MAC Src
MAC Dst
Eth Type
VLAN ID
IP Src
IP Dst
IP Prot
IP IP Sport Dport
Figure 2: OpenFlow flow-‐rule table. Adapted from (SDX Central 2014). The SDN paradigm allows for easier and more flexible network management, especially on complex scenarios. Moreover, migrating to SDN does not require a sudden change: it can be done incrementally, using switches that are not SDN exclusive. This way, some elements of the network can have a traditional behaviour but with some SDN benefits added on top (Levin 2013), with SDN policies being deployed gradually. Additionally, this allows the hardware to be gradually replaced taking into account its normal life expectancy. As a result, costs can be lowered in the deployment and transition between these scenarios (Jarraya 2014). This paradigm not only allows for more manageable networks, but can also improve network security. In the next section we will describe some of the possible uses for enhancing network security with the use of SDN. 3 Software Defined Network Uses in Security The benefits of SDN are not limited to network management and improved flexibility, as they can also be leveraged in the scope of network security mechanisms. This is mainly due to the fact that SDN enables network operators to manipulate traffic flows seamlessly without service interruptions (as previously discussed in Chapter 2), a capability that can be explored to implement and/or improve security measures. In this section, we detail some network security aspects that can be enhanced or mitigated using SDN. More specifically, we address security proposals in four different topics: honeypots, DoS mitigation, source address spoofing, and network scans. 3.1 SDN-‐Enabled Honeypots One of the potential applications of SDN relates with honeypots. By definition, a Honeypot is a decoy or dummy target set up to attract and detect/observe attacks. By being exposed to probing and attack, its purpose is to lure and track intruders as they advance (Simões 2013), revealing any scouting activities. Traditionally, honeypot systems live in unused address space in the system (i.e. IP addresses not used by the production system), passively waiting for attackers to “find them” (Spitzner 2003), but their operation can be greatly improved by SDN, which ads the possibility of turning them into a more proactive defence layer. Using the SDN's capability of changing network flows, it becomes possible to change the honeypot's behaviour from passive to active. One way to achieve this is for the active honeypot to work together with other security mechanisms such as network intrusion detection systems (NIDS). These are systems placed in strategic points in the network to monitor traffic from the devices in the network. They can detect suspicious activity such as probe scans, DoS attacks or MITM attacks. Snort, for instance, is one of the most popular NIDS (Roesch 1999).
When an unauthorized activity is detected by the NIDS, the SDN controller can divert the suspicious traffic to the honeypot, even when it was originally intended for production system. The attacker would be not aware of this diversion and would continue the attack, while the honeypot would log its activity for forensics analysis. Figure 3 illustrates an example of an active honeypot architecture. Compared to traditional honeypots, SDN-‐enabled honeypots provide a key advantage: while the effectiveness of traditional honeypots depends on the attacker directly contacting the Honeypot on the addresses it is using (typically by randomly or systematically probing the network under attack in order to discover its resources and layout), SDN-‐enabled honeypots can proactively “capture” any suspicious traffic, even when this traffic directly targets the production systems (either by chance or because the attacker had some prior knowledge of the system and knows the IP addresses of the production systems, therefore circumventing the honeypot trap). Data Path Failed Connection Normal Traffic
GuardiCore Defense Suite Control Logic
Active Honeypot
HP VAN SDN Controller
VM VM VM
VM VM VM
Hypervisor
Hypervisor
Figure 3: Active honeypot (Hewlett-‐Packard 2014). 3.2 DoS Mitigation Denial of service (DoS) and Distributed DoS (DDoS) attacks have the goal of disabling legitimate communications and activities such as web page browsing or online streaming, disabling the source of the service (Mirkovic 2004). This can be done in a number of ways such as by exploiting vulnerabilities or sending an excessive amount of connections in order to consume all the resources such as CPU time or memory. Moreover, the number of DoS attacks has been increasing, as well as their complexity (Yu 2014, Apps 2014). These attacks are unusually difficult to detect because of the similarities between real traffic generated by the users and false traffic generated to disable the targeted service. One method of reducing the impact of a DoS attack in traditional non-‐SDN networks is by using remote triggered black-‐holes (RTBH) to reduce the impact of a DoS attack (Kumari 2009). This technique consists of creating routing entries to drop undesirable traffic before it reaches an unprotected network. Usually, this has a secondary effect – the attacked host becomes unreachable, as traffic destined to it is dropped. Instead, by using SDN it becomes possible to prevent collateral damage on the network and hosts surrounding the victim. There are several proposals to mitigate these attacks using SDNs technologies. For instance, (Giotis 2014) proposed an OpenFlow-‐based architecture which is capable of mitigating a DoS attack, while keeping the victim available and preventing collateral damage to the remaining network. This proposal uses SDN to enhance the abovementioned RTBH method. Instead of the RTBH classical approach, in which packets are sent to a sinkhole interface of the edge router, network traffic flagged as unauthorized or malicious is sent to an OpenFlow switch. Using the Layer 2-‐4 matching capabilities of the OpenFlow protocol, malicious and benign
traffic are separated. The former is dropped and the latter is sent back to the edge router, where it will be forwarded to its intended destination. Another SDN enabled DoS mitigation proposal uses an unsupervised neural network (self-‐organizing maps) to achieve detection with low processing requirements (Braga 2010). The detection of DoS attacks is done using NOX (Gude 2008) and OpenFlow. This proposal takes advantage of the controller's overall view of the network to collect flow information from the switches to feed the classifier. The detection is performed on-‐line and uses a combination of six metrics: § Packets per flow: as DDoS relies on a transmission of a small number of packets from a large number of sources, flows with a small number of packets are possible DDoS sources. § Average bytes per flow: small payload size is common in DDoS packets to increase the attack efficiency. § Average of duration per flow: an SDN flow is deleted from its flow table if left inactive (no packets received) for a period of time. If a flow remains in the flow table for a short period of time, it can be a DDoS source. § Percentage of pair-‐flows: the asymmetry between flows coming into an out of the network can be an indicator of DDoS attack, as sometimes it increases the number of incoming connections without a corresponding outgoing one (Kreibich 2005). § Growth of single-‐flows: it is possible that the number of flows increases dramatically in the beginning of a flood attack. This growth is calculated with the number of pair-‐flows left out during a certain time interval. § Growth of different ports: Used to calculate the number of ports used in the attack (port spoofing), since it can also have a dramatic increase similar to the number of flows. Using the well-‐known KDD-‐99 dataset, the authors report good detection performance with a low percentage of false positives. Moreover, they require substantially less CPU time to perform the detection comparing with other kinds of detection. 3.3 Source Address Spoofing Countermeasures Source address spoofing is a technique that can enable a number of attacks, such as SYN Flood, man in the middle (MITM), Smurf, and DNS amplification, among others (Bi 2010). One of the most common and accepted practices to mitigate address spoofing is ingress filtering (Liu 2011). However, its deployment is slower than the internet growth and will not be effective unless fully deployed (Kwon 2015). Source Address Validation Improvement (SAVI) is an IETF effort to improve ingress filtering (McPherson 2013). SAVI does address spoofing detection by binding the switch port where a host is connected to its IP address prefix (Bagnulo 2013). However, it has some limitations. A host attached to a SAVI device can be attacked by spoofing the source address with one bound to another SAVI device (Yao 2001). Virtual source Address Validation Edge (VAVE) is an enhanced proposal for address spoofing detection. It is designed to protect the important addresses from the network from being spoofed (e.g., servers and routers) and it can prevent flows from between two SAVI switches from being spoofed (Yao 2011). It uses OpenFlow switches and NOX to improve source address verification. VAVE conceptually separates the flows coming from hosts, other OpenFlow switches and legacy (non OpenFlow) routers. When a new flow is detected, the application checks it for spoofing addresses. If source address spoofing is detected, it changes the flow rule table to drop packet. If a spoofing flow is inactive (no new packets) for some time, it is deleted. Seeing that packets are checked when they entered an OpenFlow switch from a legacy device, packets transmitted between neighbouring OpenFlow switches are not checked for spoofed addresses.
NOX Filter Generator
Validation Module
Filter Adapter
VAVE App Hit Filtering Rule
LD
VAVE
Flow Path (A, F)
OP A
OP C
LD
Spoofing Flow (S=A, D=F)
OP D
OP F
LD
OP
OP B
Spoofing Flow (S=A, D=F) OpenFlow Device
LD
OP E
OP G
LD
LD
LD
Legacy Device
LD
Figure 4: VAVE architecture (Yao 2011). 3.4 Network Scanning Avoidance Network security improvements can be done proactively: it is better to avoid an attack than to detecting it. The initial stage of several attacks consists of network scans with the objective of gathering information. To reduce the probability of a successful scan, a random host mutation is proposed in (Jafarian 2012) using OpenFlow Remote Host Mutation (OF-‐RHM). The reason behind the proposal is that static configurations are beneficial for attackers. If their targets are fixed it is easier to find and attack than if the hosts' IP addresses are constantly changing. The two main objectives of OF-‐RHM are: transparent IP address changing to the end-‐ hosts; and highly unpredictable IP changes and frequent enough to distort the attacker's view of the network. IP address changing is achieved by using the entire unused space to assign virtual IP addresses. Each host has a real IP address and is assigned a virtual (short-‐lived) IP addressed that will be translated to the real IP right before the host. There are other proposals of host mutation (Atighetchi 2003, Kewley 2001, Antonatos 2005), but have some implementation limitations such as requiring cooperation from end-‐hosts, and disrupting existing connections. A host can be reached by hostname or by its real IP address. When reached by hostname, the first stage is to query the DNS server to get the IP address associated with the hostname. As soon as a DNS query is made, the NOX controller changes fields in the DNS response. It replaces the real IP for the virtual IP and sets a small value to the time to live (TTL) field. The host will then send the first packet and because the OpenFlow switch does not have a matching rule to that connection, the controller updates its rule table. The virtual IP is assigned from the pool of unused IP addresses and can be chosen by two ways: 1) blind mutation where the new IPs are chosen randomly with a uniform probability; 2) weighted mutation where the weight is associated to each virtual IP address. This weight is based on how many times an unused IP has been scanned. The more times an IP has been scanned, the less likely it is to be scanned again by a malicious host.
According to the authors, OF-‐RHM can reduce the efficiency of network scan attacks up to 99%. This figure was achieved by running 100 scans on the network and comparing their result with the ground truth (the first scan). Moreover, up to 90% of the network hosts are saved from vicious scanning worms. This was tested with worms with low IP repetition, which use number generators to reduce the possibility of hitting the same IP several times. Although named hosts can still be reached via DNS, most scanners use IP address to collect information in order to avoid too many DNS queries and detection. Another method to avoid network scans attacks is proposed in (Song 2014). The authors propose a mitigation strategy by providing false information with the use of a honeynet. Their system uses OpenFlow to detect the scan attacks by looking at incoming packets towards a closed or unused ports, or if the packets are corrupted. A corrupted packet is one that does not follow the network protocol standard. For example, if a TCP session is initiated with a RST packet, that packet is considered corrupted. After a successful detection, the packet and successive ones in that flow are redirected to the honeynet. There are two different systems: the All-‐Alive Network and the Phantom Network. In the former, the honeypots have all ports open. The honeypot simulates popular network services (e.g. using port 80, 445, and 8080) and for the remaining ports, the authors use a program open them, but network services are not emulated, it will only reply with simple pre-‐defined data. For the Phantom Network, some network services are chosen for emulation. This network will not be the same as the real one that is being protected. 4 Discussion and Conclusion The emerging concept of Software Defined Networking is expected to strongly change the way we design and manage communications networks. While not specifically targeting network security, adoption of SDN opens the door for novel approaches to network and systems security. In this paper we discuss some of the more promising security management approaches enabled by SDN, including SDN-‐enabled honeypot scenarios, defence mechanisms for denial of service attacks, for spoofing source addresses and for network scans. Although SDN is a key element in these proposals, the authors use SDN in a number of different ways. Not only is it used to implement novel security techniques such as seamless random host mutation, it also leverages and enhances well known techniques such as RTBH and SAVI. Moreover, SDN provides flexibility to use techniques such as anomaly detection or to forward the traffic in a seamless way that is now feasible with traditional non-‐SDN techniques. Albeit all proposals have security benefits, some may have limitations in real world deployment. Some proposals such as (Braga 2010), assume a full SDN deployment while other proposals like (Giotis 2014) use SDN as an add-‐on to a traditional network. Despite the fact that SDN deployments are increasing, most networks are still traditional, and the change to a programmable networking paradigm will be gradual. This can be a leverage to solutions that use SDN in combination with the traditional network, without the need to rebuild the network. As SDN technologies gradually reach production networks, these and forthcoming approaches are expected to strongly improve network security. 5 Acknowledgements This work was partially funded by PT Inovação (in the scope of Project HolisticSDN) and by project iCIS (Intelligent Computing in the Internet of Services – CENTRO-‐07-‐0224-‐FEDER-‐002003). References Antonatos, S. et al., 2005. Defending Against Hitlist Worms Using Network Address Space Randomization. In Proceedings of the 2005 ACM Workshop on Rapid Malcode. WORM ’05. New York, NY, USA: ACM, pp. 30–40.
Apps, P., 2014. DDoS cyber attacks get bigger, smarter, more damaging. Available at: http://www.reuters.com/article/2014/03/05/us-‐cyber-‐ddos-‐idUSBREA240XZ20140305. Atighetchi, M. et al., 2003. Adaptive use of network-‐centric mechanisms in cyber-‐defense. In Object-‐Oriented Real-‐Time Distributed Computing, 2003. Sixth IEEE International Symposium on. pp. 183–192. Bagnulo, M. & García-‐Martínez, A., 2013. SAVI: The IETF standard in address validation. Communications Magazine, IEEE, 51(4), pp.66–73. Bi, J., Hu, P. & Li, P., 2010. Study on Classification and Characteristics of Source Address Spoofing Attacks in the Internet. In Networks (ICN), 2010 Ninth International Conference on. pp. 226–230. Braga, R., Mota, E. & Passito, A., 2010. Lightweight DDoS flooding attack detection using NOX/OpenFlow. In Local Computer Networks (LCN), 2010 IEEE 35th Conference on. pp. 408–415. Ellanti, M.N. et al., 2005. Next generation transport networks: data, management, and control planes, Springer. Feamster, N., Rexford, J. and Zegura, E. (2013). The Road to SDN. Queue, 11(12), pp.20-‐40. Finkle, J., 2014. Sony works for 3rd day to restore PlayStation after attack. Reuters. Available at: http://www.reuters.com/article/2014/12/27/us-‐sony-‐cybersecurity-‐playstation-‐idUSKBN0K50FV20141227. Giotis, K., Androulidakis, G. & Maglaris, V., 2014. Leveraging SDN for Efficient Anomaly Detection and Mitigation on Legacy Networks. In Software Defined Networks (EWSDN), 2014 Third European Workshop on. pp. 85–90. Greenberg, A. et al., 2008. The Cost of a Cloud: Research Problems in Data Center Networks. SIGCOMM Comput. Commun. Rev., 39(1), pp.68–73. Available at: http://doi.acm.org/10.1145/1496091.1496103. Greene, K. (2009). Tech Review 10 Breakthrough Technologies: Software-‐Defined Networking. [online] MIT Technology Review. Available at: http://Tech Review 10 Breakthrough Technologies: Software-‐Defined Networking [Accessed 12 Dez. 2014]. GuardiCore (2014). Data center security redefined. [online] Technical report, Hewlett-‐Packard. Available at: http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA5-‐1629ENW. [Accessed 10 Dez. 2014]. Gude, N. et al., 2008. NOX: Towards an Operating System for Networks. SIGCOMM Comput. Commun. Rev., 38(3), pp.105–110. Available at: http://doi.acm.org/10.1145/1384609.1384625. Hewlett-‐Packard, (2014). Data center security redefined. Available at: http://h20195.www2.hp.com/v2/GetPDF.aspx%2F4AA5-‐1629ENW.pdf. Muelder, C., Ma, K.-‐L. & Bartoletti, T., 2006. Interactive Visualization for Network and Port Scan Detection. In Proceedings of the 8th International Conference on Recent Advances in Intrusion Detection. RAID’05. Berlin, Heidelberg: Springer-‐Verlag, pp. 265–283. Jafarian, J.H., Al-‐Shaer, E. & Duan, Q., 2012. Openflow Random Host Mutation: Transparent Moving Target Defense Using Software Defined Networking. In Proceedings of the First Workshop on Hot Topics in Software Defined Networks. HotSDN ’12. New York, NY, USA: ACM, pp. 127–132. Available at: Jarraya, Y., Madi, T. and Debbabi, M. (2014). A Survey and a Layered Taxonomy of Software-‐Defined Networking. IEEE Commun. Surv. Tutorials, 16(4), pp.1955-‐1980. Kewley, D. et al., 2001. Dynamic approaches to thwart adversary intelligence gathering. In DARPA Information Survivability Conference amp; Exposition II, 2001. DISCEX ’01. Proceedings. pp. 176–185 vol.1. Koomey, J.G., 2008. Worldwide electricity used in data centers. Environmental Research Letters, 3(3), p.34008.
Kreibich, C. & Warfield, A., 2005. Using packet symmetry to curtail malicious traffic. ACM Hotnets …, 200. Available at: http://conferences.sigcomm.org/hotnets/2005/papers/kreibich.pdf [Accessed February 2, 2015]. Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C., Azodolmolky, S. and Uhlig, S. (2014). Software-‐Defined Networking: A Comprehensive Survey. Proc. IEEE, 103(1), pp.14-‐76. Kumari, W. & McPherson, D., 2009. Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF). , (5635). Available at: http://www.ietf.org/rfc/rfc5635.txt. Kwon, J., Seo, D., Kwon, M., Lee, H., Perrig, A., & Kim, H. (2015). An incrementally deployable anti-‐spoofing mechanism for software-‐defined networks. Computer Communications. Levin, D., Canini, M., Schmid, S., & Feldmann, A. (2013). Panopticon: Reaping the benefits of partial sdn deployment in enterprise networks. TU Berlin/T-‐Labs, Tech. Rep. Liu, B., Bi, J., & Zhu, Y. (2011). A deployable approach for inter-‐AS anti-‐spoofing. In Network Protocols (ICNP), 2011 19th IEEE International Conference on (pp. 19–24). doi:10.1109/ICNP.2011.6089052 Liu, Y. et al., 2014. Research of Data Center Fresh Air Ventilation Cooling System. In A. Li, Y. Zhu, & Y. Li, eds. Proceedings of the 8th International Symposium on Heating, Ventilation and Air Conditioning SE -‐ 30. Lecture Notes in Electrical Engineering. Springer Berlin Heidelberg, pp. 299–306. Available at: http://dx.doi.org/10.1007/978-‐3-‐642-‐39581-‐9_30. McPherson, D., Baker, F. & Halpern, J., 2013. Source Address Validation Improvement (SAVI) Threat Scope. , (6959). Available at: http://www.ietf.org/rfc/rfc6959.txt. Mirkovic, J. et al., 2004. Internet Denial of Service: Attack and Defense Mechanisms (Radia Perlman Computer Networking and Security), Upper Saddle River, NJ, USA: Prentice Hall PTR. ONF, Open Networking Foundation. 2014. Available at: https://www.opennetworking.org/. R. Presuhn, “Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP),” RFC 3416 (INTERNET STANDARD), Internet Engineering Task Force, Dec. 2002. [Online]. Available: http://www.ietf.org/rfc/rfc3416.txt Roesch, M. & others, 1999. Snort: Lightweight Intrusion Detection for Networks. In LISA. pp. 229–238. Schudel, G. & Smith, D., 2007. Router Security Strategies: Securing IP Network Traffic Planes, Pearson Education. Champagne, D. & Lee, R.B., 2006. Scope of DDoS Countermeasures: Taxonomy of Proposed Solutions and Design Goals for Real-‐World Deployment. Available at: http://palms.ee.princeton.edu/PALMSopen/champagne06DDoS.pdf. SDX Central (2014). What is OpenFlow?. Available at: https://www.sdxcentral.com/resources/sdn/what-‐is-‐ openflow/ Shin, S., Porras, P., Yegneswaran, V., Fong, M., Gu, G. and Tyson, M. (2013). FRESCO: Modular Composable Security Services for Software-‐Defined Networks. In: NDSS Symposium. Simões, P. et al., 2013. On the use of Honeypots for Detecting Cyber Attacks on Industrial Control Networks. In 12th European Conference on Information Warfare and Security (ECIW 2013). Song, Y., Shin, S. & Choi, Y., 2014. Network Iron Curtain: Hide Enterprise Networks with OpenFlow. In Y. Kim, H. Lee, & A. Perrig, eds. Information Security Applications SE -‐ 14. Lecture Notes in Computer Science. Springer International Publishing, pp. 218–230. Available at: http://dx.doi.org/10.1007/978-‐3-‐319-‐05149-‐9_14. Spitzner, L., 2003. Honeypots: Tracking Hackers, Addison-‐Wesley.
Stutter, J.D., 2009. Twitter hit by denial-‐of-‐service attack. CNN. Available at: http://edition.cnn.com/2009/TECH/08/06/twitter.attack/index.html. Wang, B. et al., 2014. DDoS Attack Protection in the Era of Cloud Computing and Software-‐Defined Networking. In Network Protocols (ICNP), 2014 IEEE 22nd International Conference on. pp. 624–629. Yao, G., Bi, J. & Xiao, P., 2011. Source address validation solution with OpenFlow/NOX architecture. In Network Protocols (ICNP), 2011 19th IEEE International Conference on. pp. 7–12. Yeganeh, S.H., Tootoonchian, A. & Ganjali, Y., 2013. On scalability of software-‐defined networking. Communications Magazine, IEEE, 51(2), pp.136–141. Yu, S., 2014. An Overview of DDoS Attacks. In Distributed Denial of Service Attack and Defense SE -‐ 1. SpringerBriefs in Computer Science. Springer New York, pp. 1–14. Available at: http://dx.doi.org/10.1007/978-‐ 1-‐4614-‐9491-‐1_1.
![[PDF] Download How to Use Grading to Improve ... - Google Sites](https://m.moam.info/img/260x300/pdf-download-how-to-use-grading-to-improve-google-_64771d9e097c4744708b5981.jpg)
![How to Use [PDF]](https://m.moam.info/img/260x300/how-to-use-pdf_647de705098a9e0a468b45fc.jpg)