s critical to help ensure the SDN infrastructure cannot be used as part of an attack. Malicious DNS queries (spoofed source IP address set to the address of the victim) Orchestrator instantiates new VM to scale-out vDNS function to accommodate more queries. hacker Orchestration eNodeB Hypervisor eNodeB Victim eNodeB Mobile Devices (Smartphones, M2M, loT) Victim receives the DNS query response (large/amplified packets) Infrastructure controls (e.g. vIDS/vIPS & vFirewalls) mitigate attack FIGURE 9.6 DNS amplification attacks enhanced by elasticity function. Network Security Since the implementation is distributed, it is imperative that the controller and the centralized source of information have correct information on the structure of the network and what is distrib- uted where. Sending commands to the incorrect virtual router or switch could result in unwarranted consequences. Recovery from this state would probably rely on backing out the latest commands and a subsequent analysis to determine what went wrong and related corrective actions. Figure 9.6 depicts an example of how the technology can provide a challenge. In this scenario, what was deemed as a benefit when dealing with a DDoS attack (e.g., adding capacity) can work to our detriment when applied to an attack mechanism. An attacker sends mali- cious domain name system (DNS) queries from a spoofed source IP address. The infrastructure reacts to the increase in queries by standing up additional virtual DNSs (vDNSs), which allows more attack traffic to reach the target or the victim. The solution in this case, involves applying traditional controls (e.g., FW, intrusion detection and prevention) as well as processes to detect and limit the damage. These controls and processes work together to alarm on the unusual activity and limit the damage. It is the balance of the flexibility and the controls that will ultimately determine and con- strain the damage imparted on the victim. This also demonstrates a case where the operations team and processes need to be a