STE: Secure Traffic Engineering for SDN Data Center Networking

STE: Secure Traffic Engineering for SDN Data Center Networking STE: Secure Traffic Engineering for SDN Data Center Networking STE: Secure Traffic Engineering for SDN Data Center Networking Statement of Work (SOW) PI: Dijiang Huang Affiliation: Arizona State University Public IaaS cloud service providers usually grant root access to cloud tenants on their allocated virtual machines (VMs), and they do not intervene the cloud tenants activities such as installing applications in their VMs. However, this may allow vulnerable VMs running in the cloud system. Thus it is critical to perform stringent security monitoring and protections to guard against both potential internal and external attackers from compromising them. In this research, we propose to establish a Secure Traffic Engineering (STE) model for virtual Data Center networking. STE targets at to provide a dynamic defensive cloud networking defensive mechanism based on software defined networking (SDN) approaches. In other words, STE is to establish a defense in-depth intrusion detection, mitigation, and prevention framework in a cloud virtual networking environment. The design of the STE targets a set of basic utilities common to the majority of IaaS cloud networking systems that are based on OpenFlow technology, which is the current de facto implementation of SDN concept. STE will serve as the build-in security support for virtual networking based cloud service models and data centers. Additionally, there will also be performance evaluation, optimization, measurement, and management tools produced from this. Compared to existing work, STE employs the defense-in-depth and moving target security defensive concepts to detect and counter the attempts to compromise VMs, thus preventing zombie VMs. Particularly, this research will focus on the secure traffic traffic-engineering approaches when deploying the dynamic SDN-based security solutions, in which we posit that traffic engineering that is integrated with security issues, is critically needed in the virtual network environment for STE. There are a number of issues that we need to consider when addressing traffic engineering here. First, one or more VMs may be compromised that may require creation of safe VMs (and other resources) on the fly to meet a customers service level agreement. Secondary, the current traffic path may be compromised requiring new provisioning of paths for service connectivity. Finally, resources may be overextended due to an attack. This third issue becomes critical in a VM-based environment since a physical machine has many VMs where an affected VM may cause resources to be limited for other VMs. To guard this, we limit resources available to a VM to start with, and VM is not given additional resources unless the network controller affirms that the request is legitimate. In order to effectively manage the traffic engineering, the STE operates at two time scales. One is a regularly scheduled window when the virtual network (VN) provisioning is done; we refer to time instances for this schedule as review points. The second is that an on-demand action may be needed due to addressing attack countermeasures. Based on the detected attacks and corresponding SDN-based countermeasures, we can determine a number of potential scenarios, each of which may have a (slightly) different traffic engineering problem to solve, for example, one may require new VMs, another may require new paths to avoid attack location, and the third a combination of both. The reason for having different traffic engineering models ready is to be able to provide effective and efficient traffic engineering for a problem at hand. This also reduces the complexity at the STE controller in terms of invocation and execution on demand. Suppose in an attack situation, a number of VMs are compromised. Once the monitoring system recognizes this issue, it needs to shut down paths to these machines, which is relatively easy to do in a software-defined networking environment. Secondly, this requires creating new VMs and creating paths to them. This then becomes a subset of requests to consider from the above base problem between review points t and t + 1; on the other hand, the new VMs and/or additional paths that need to be considered changes the input to the traffic engineering problem. We can maintain a dictionary of appropriate traffic engineering and control schemes to invoke when necessary. Furthermore, invocation of a security-enabled traffic engineering mechanism is associated with Return on Investment (ROI) measurement; in other words, RoI will dictate which TE mechanism is preferably invoked. Also, note that STE will be a feedback loop with the attack analyzer, and the network controller so that they exchange pertinent information between them to main an effective system. To summarize, our work will address developing traffic engineering models to be used at the STE. We plan to do extensive numeric studies to understand the dynamics of this model in the temporal context as well as to understand the stability of the on-demand action for counter-measures, and how RoI plays a role in the overall system performance and effectiveness.