Internet DRAFT - draft-wang-state-migration-vfirewall
draft-wang-state-migration-vfirewall
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
Abstract
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.
Requirements Language
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].
Status of this Memo
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 Notice
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
Wang, et al. Expires June 22, 2013 [Page 1]
Internet-Draft Abbreviated-Title December 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Server Virtualization and the Imposed Issues . . . . . . . . . 4
4. A case of vFW . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. vFW state migration . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Wang, et al. Expires June 22, 2013 [Page 2]
Internet-Draft Abbreviated-Title December 2012
1. Introduction
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
2. Terminology
DC: Data Center
VFW: Virtual FireWall
VM: Virtual Machine.
AR: Access Router
Wang, et al. Expires June 22, 2013 [Page 3]
Internet-Draft Abbreviated-Title December 2012
3. Server Virtualization and the Imposed Issues
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
Wang, et al. Expires June 22, 2013 [Page 4]
Internet-Draft Abbreviated-Title December 2012
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.
4. A case of vFW
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.
Wang, et al. Expires June 22, 2013 [Page 5]
Internet-Draft Abbreviated-Title December 2012
----------
| VM Mgr |
---------- \
\
\
----------------------------
---------- | --------- |
|FW | | |FW | |
|Policies|----+-|Polices| |
|Mgr | | |Agent | |
---------- | ---+----- |
| | |
| | APP VMs |
| | | |.. |
| ---+------------+---+- |
| | | | |
| | -------- Hypervisor| |
| | |FW | | |
| | |Engine| | |
| | -------- | |
| ---------------------- |
----------------------------
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.
Wang, et al. Expires June 22, 2013 [Page 6]
Internet-Draft Abbreviated-Title December 2012
5. vFW state migration
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.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Wang, et al. Expires June 22, 2013 [Page 7]
Internet-Draft Abbreviated-Title December 2012
7. Security Considerations
TBD
8. Acknowledgements
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Yuchen Wang
Huawei
Email: wangyuchen@huawei.com
Yingjie Gu
Huawei
Phone:
Fax:
Email: guyingjie@huawei.com
URI:
Dacheng Zhang
Huawei
Phone:
Fax:
Email: zhangdacheng@huawei.com
URI:
Wang, et al. Expires June 22, 2013 [Page 8]
