vFW state migration problem statement

The development of data center networks (DC networks) imposes new challenges to security mechanisms. A DC network may need to support up to hundreds of thousands of virtual machines which belong to different tenants. The virtual machines may be move amongst different physical servers for efficiency, maintaince or discater recovery and ect. These virtual machines may create large amounts of traffics. To adapt the new features of data center networks, the solutions of virtualizing security mechanisms are proposed. Generally, there are two types of security virtualization soltuions, "one-to-many" or "many to one". In a "one two many" solution, a physical security device can act as multiple virtual security device for different tenants. In a "many to one" solution, multiple hardware of software security devices cooperate to privide services for the purposes of e.g., scabability, and efficiency. The cooperating procedures amongst the security devices are covered from tentents. A tentent can only see a vitualized security device. Virtual Firewalls (VFWs) are an instance of "many to one" solution. A virtual Firwalls consists of multiples hardware or software sub-Firewalls located in different positions of a DC network. Each sub-Firewall manage a certain part of the network. The sub-Firewallls may be coordinated by a centralized server. The migration of VMs brought some serious issues to vFWs. For instance, when a VM moves from an place to another, the traffic the VM generates may be transported to and processed by a different sub-Firewall. When receiving a packet sent to or from the migrated VM, the sub-Firewall may find it lacks sufficient state information to correctly process the packet. Such information includes: statistic inforamtion about a flow, ACL, and other security policies. This draft focus on analyzing the state migiration requirements on vFWs which are brought by the migration of VMs

DC: Data Center VFW: Virtual FireWall VM: Virtual Machine. AR: Access Router

Server virtualization technologies have made a very significant development in recent years. The ratio of virtualized machine (VM) to physical server keeps increasing. This enables Data Center Providers to efficiently make use of their infrastructure resources to support more tenants. In typical server virtualization mechanism, there are, usually, a VM manager, a virtualization platform, and public APIs. The following diagram shows a brief example of server virtualization components.

Everything has its pros can cons. Server virtualization complicates security mechanism as well as explores infrastructure resources. For instance , in a traditional Data Center, access routers (ARs), core layer switchs, aggregation layer switch and access layer switchs are organized from up to down in a hierachical way, and the security devices within the data center, e.g. a pair of redundant Firewalls, are placed at the top of Data Center network, usually on the AR. All the packets that need inspection are forwarded to the security devices at the top of the network. It is not a big a problem when only physical servers are deployed, since the network devices interfaces limit the amount of servers accessing to the network and the traffic they generate. However, the virtualization technologies times the amount of servers that a network has to serve, and the amount of traffic that a centralized security device needs to deal with increases coorespondently, which is a heavy burden to the centralized security devices mentioned above. In addtion, a new feature of the traffic in data centers is that the communication amongst the servers within a data center increases. The traditional centralized security solution will force such traffic to traverse un-optimized paths. A trend in Data Centers, and Data Center providers already do it, is to adopt a kind of more flat structure, less layers and distributed security devices on distributed switches. This structure enables less processing path and reduce performance bottleneck. It is a reasonable and important change. At the same time, the work of virtualizing security devices is undertaken. Mutiple virtualization OS vendors extend their virtualization platform capability in supporting security functions by either developing their own virtualized security devices in server or providing public APIs for others to use their embedded security functions on Hypervisor. Network device vendors also attempts expand their Data Center solution into servers, they develop virtual switch and virtual security engines that can co-work with Hypervisor infrastructure. The benefit of virtual security mechanisms is obvious. First, Not all of the traffic has to pass through the network from bottom to top, which optimizes traffic paths and then saves bandwidth, Secondly, virtial security mechanims can easily distribute the overhead of processing packets into different virtual devices. Therefore, compared with the centrialized security solution, a virtual security mechanism has its advantage in providing the accurate but resource-consuming security functionalities, e.g., inspecting traffic on layer 4 and higher, for a large amount of tenants. Such security functionalities is desired for the security protection of data centers.

There are various ways to implement vFWs. However, such differences in implementation do not affect the analysis in this section. Therefore, without losing generality but benefiting the discussion, in this section, we assume vFWs are deployed in servers and make use of the public APIs provided by server virtualization providers to achieve its functionalitiy. An abstracted way of vFW deployment is shown in following diagram.

The steps of vFW mechanism are as follows. As a common knowledge, people can used different technical details even with a same architecture, there are other ways to fulfill the similar function as described in below. 1) FW Policies Mgr distributes VM policies on FW Policies Agent.(It can also be a pull way, that is Agent pulls the policies from Mgr according to the traffic it receives.) 2) FW Engine executes VM policies by inspecting VM’s traffic. The policies on FW Engine is achieved from FW Polices Agent by either a push way or a pull way. FW Engine can only deal with traffic with simple polices, e.g. pass or deny. It can’t implement complicated policies, so it’s called a Fast Path of processing. 3) For the traffic that need complicate inspection, FW Engine will make the traffic go through FW Policies Agent by some way. 4) FW Policies Agent deals with the traffic and record the state of the traffic for future inspection. It’s called Slow Path of Processing. 5) FW Policies Agent transfers or drops the traffic packets according to policies.

In this section, we analyze the situation of VM live migration and corresponding state migration. There are lots of discussion of VM live migration in IETF, NV03 WG, SAMI mail list and in draft-gu-statemigration-framework, we won’t introduce more in our draft. The state we discuss in this draft is flow-associated state, here we copy the definition in draft-gu-statemigration-framework. The flow-associated state is usually instantiated through a combination of traffic inspection and broad policies, but may also be created by the use of an explicit request or signaling mechanism. Refer to Sec 4 for more introduce of flow-associated state. Assuming a VM is communicating with other VMs or with external peers, and the VM has complex policies which makes its traffic has to pass through FW Policies Agent and the Agent records the state of traffic. At a time, VM begin to migrate to a new place, the traffic is stopped at the old location, VM migrating and state on FW Policies Agent also migrating to the new FW Policies Agent at new location (server), then the traffic resumes at the new location. In this scenario, it’s similar to the state migration on physical servers as vFW state migration also need to do the following things. o Recognizing when an endpoint is staring migration o Locating vFW at the old location o Locating vFW at the new location o Getting a copy of state from vFW at the old location o Installing that state in vFW at the new location We believe state migration is needed in some, if not all, virtual security mechanisms, especially when the security mechanism is provided by a second party rather than the server virtualization vendor.

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.

TBD