| Network Working Group | Y. Wang |
| Internet-Draft | Y. Gu |
| Intended status: Informational | D. Zhang |
| Expires: June 22, 2013 | Huawei |
| December 19, 2012 |
vFW state migration problem statement
draft-wang-state-migration-vfirewall-00
This draft introduces the state migration issues with the virtual security mechanisms (e.g., virtual firewalls) in data centers caused by the immgration of the virtual machines.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 22, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
----------
| VM Mgr |
---------- \
\
\
---------------------
| APP VM VM |
| | | | |
| --+--------+---+- |
| | Hypervisor | |
| ----------------- |
---------------------
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.
----------
| VM Mgr |
---------- \
\
\
----------------------------
---------- | --------- |
|FW | | |FW | |
|Policies|----+-|Polices| |
|Mgr | | |Agent | |
---------- | ---+----- |
| | |
| | APP VMs |
| | | |.. |
| ---+------------+---+- |
| | | | |
| | -------- Hypervisor| |
| | |FW | | |
| | |Engine| | |
| | -------- | |
| ---------------------- |
----------------------------
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
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |