Network Working Group D. Wang Internet-Draft Y. Gu Intended status: Standards Track Huawei Expires: December 20, 2011 June 18, 2011 Survey and Gap Analysis for Policies and Dynamic Information Migration in Data Center draft-wang-opsawg-policies-migration-gap-analysis-00 Abstract With the virtualization of Data Center, the number of VM explodes. VM can play different roles in Data Center, such as end-host, server, firewall, and so on. Also, VM can be migrated to any places within Data Center, even to another Data Center. Since running services shouldn't be significantly interrupted while VM migrates, VM related policies and dynamic information generated by any devices must be transferred to destination devices during a proper short period. [I.D-gu-opsa-policies-migration-00] has introduced more detail problem statement and corresponding considerations. We wish we could benefit from existing work to realize accurate dynamic information migration (DIM). Therefore, we engaged in the investigation of related IETF works right after general requirements of DIM are defined. Since the solution for DIM has not been decided yet, and the author can envision several kinds of solution, e.g. centralized or distributed. It's unrealistic to enumerate all the related works for an uncertain solution. So, in this draft, only the most related IETF work, MIDCOM protocol, has been evaluated to find out whether it can fully support DIM or which characteristics can be reused in DIM. The author would like analyze other related IETF works when the WG make further decision on DIM solution. Following a short description of general DIM requirements, this draft presents a brief survey of MIDCOM protocol, and then lists the gap between MIDCOM and DIM requirements. The final section presents possible working scope on the topic of DIM in IETF. 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/. Wang & Gu Expires December 20, 2011 [Page 1] Internet-Draft GapAnalysis June 2011 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 December 20, 2011. Copyright Notice Copyright (c) 2011 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. Wang & Gu Expires December 20, 2011 [Page 2] Internet-Draft GapAnalysis June 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 5 3. General Requirements on DIM . . . . . . . . . . . . . . . . . 5 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Capability Negotiation . . . . . . . . . . . . . . . . . . 6 3.3. Unification . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. DI Elimination . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Atomicity . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Flexibility . . . . . . . . . . . . . . . . . . . . . . . 7 3.7. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 7 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 4. Brief Summary of MIDCOM Protocol . . . . . . . . . . . . . . . 7 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Policy Rule Configuration . . . . . . . . . . . . . . . . 8 4.3. Agent(s) - Middlebox(es) . . . . . . . . . . . . . . . . . 8 4.4. Transaction & Atomicity . . . . . . . . . . . . . . . . . 8 4.5. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 8 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Could be Reused . . . . . . . . . . . . . . . . . . . . . 9 5.2. New Features . . . . . . . . . . . . . . . . . . . . . . . 9 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Wang & Gu Expires December 20, 2011 [Page 3] Internet-Draft GapAnalysis June 2011 1. Introduction Dynamic information (DI) refers to any information generated by any devices in the Data Center. Therefore, DIM involves a wide range of network devices and covers various types of dynamic information. Since running service is supposed not to be significantly interrupted while VM migrates, dynamic information should be migrated during the short period after VM not running on source device but before VM running on target device. Otherwise, the migrated DI would be inaccurate and might cause traffic dropping. In DIM, there are two main issues to be addressed: (1) detect and notify accurate migration time to involved devices; (2) transfer dynamic information from source devices to target devices. To address the first issue, VDP could be extended to assist in notifying migration time to adjacnet bridge, i.e. the bridge that directly connected with the server that VM is hosted in. However, a dissemination mechanism is required for distributing migration time notification from adjacent bridge to upper layer network devices that possess VM-related DI . This is beyond the scope of this draft. For the second issue, a protocol which can realize reliable transmission of dynamic information should be applied. If no such protocols exist, a new protocol should be designed. The author can envision three kinds of solution so far, fully centralized solution, fully distributed solution, and middle solution which incorporates the above two solutions. As following a brief introduction of them will be presented. For fully centralized solution, a centralized server would be introduced. The centralized server would be notified about the migration time, and then it obtains DI from source devices and send DI to destination devices. For fully distributed solution, VDP should be extended to notify the migration time to adjacent bridges, and adjacent bridges distribute the notification to upper layer network devices. Source network devices PUSH the DI to corresponding destination devices, or reverse. For middle solution, a centralized database would be introduced. Source network devices triggered by notification message PUSH DI to database and destination devices PULL DI from database. The above description of solutions are very briefly, there must be lots of issues need to be resolved before any of them can become a reasonable solution. Since different solutions exist for DIM and none of them has been ultimately confirmed as final solution, it's difficult to investigate all related work. MIDCOM protocol, the most Wang & Gu Expires December 20, 2011 [Page 4] Internet-Draft GapAnalysis June 2011 related existing IETF work, has been analyzed to see whether it can satisfy DIM requirements or which characteristics can be reused in DIM. 2. Terminologies and concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "WOULD", "COULD", "CANNOT", "MIGHT", and "MAY"in this document are to be interpreted as described in [RFC2119]. Source device: the device from where the VM migrates. Destination device: the device to where the VM migrates. Migration pair, device-pair: a network device and its partner which involved in DIM. TCP connection table: A table containing TCP connection-specific information. Sticky table: A table of session persistence of sticky connections, which is used to match incoming requests to existing connections so that they can be grouped together. ACL: Access Control List; A list of rules that specifies which packets can be permitted, which should be denied. Middlebox: A device in the Internet that provides transport policy enforcement. Examples of these devices include firewalls, network address translators (both within and between address families), signature management for intrusion detection systems, and multimedia buffer management. Server health information: Information accumulated by middlebox, which can help decide whether the server is alive by monitoring packet activity to and from the server. It may include sever availability, application availability, and application consistency. VM: Virtual Machine; A completely isolated operation system which is installed by software on a normal operation system. A normal operation system can be virtualized into several VM. 3. General Requirements on DIM Wang & Gu Expires December 20, 2011 [Page 5] Internet-Draft GapAnalysis June 2011 3.1. Authentication For security consideration, mutual authentication between network devices must be supported. 3.2. Capability Negotiation The protocol must support capability negotiation between network devices before migration starts. The goal of capability negotiation is to make sure the destination devices supports appropriate functions and has enough software resource to support the DI which is going to be migrated. For example, a source Firewall has 6 TCP connection table items to be migrated, while the destination Firewall has only 4 items available. That implies the DI migration could fail. The source device can be aware of the situation by capability negotiation. The manager can make decision on whether to continue VM migration with the awareness of the risk of DIM failure. 3.3. Unification The protocol must enable transferring of any dynamic information generated by any devices in the Data Center. DIM involves various types of dynamic information and network devices. For example, TCP connection tables on proxies, dynamic ACLs on firewalls, sticky tables on load balancers, server health information accumulated by middleboxes, are all dynamic information generated by different devices. Except for the existing types of DI, new types of DI might also appears along with new services/ applications are introduced. It's better to design a unified solution for all kinds of DI, existing or emerging ones, instead of individual solution for specific type of DI. 3.4. DI Elimination Once dynamic information has been migrated successfully to destination device, it must be eliminated from source device in time, otherwise it might be taken advantage by malicious attackers. 3.5. Atomicity Since one device might be involved into several migrations simultaneously, migrations with different partners must be isolated to each other. The migration lanched by one device must not be interrupted by migrations launched by other devices, which can ensure atomicity of migration interactions. Wang & Gu Expires December 20, 2011 [Page 6] Internet-Draft GapAnalysis June 2011 3.6. Flexibility Since VM can be migrated to any place within Data Center, even to another Data Center, the protocol should be able to apply in different scenarios, symmetric or asymmetric architecture in the same DC domain, even between two different DC domains. 3.7. Fault Tolerance Successful VM migration should be accompanied with workable fault tolerance mechanism. A list of potential failure reasons could be pre-defined and certain failure reason could be chosen and replied to related network devices, which could help them decide whether continue migration or not. 3.8. Extensibility The protocol should be designed to be extensible to support migration of new dynamic information or between new network devices. 4. Brief Summary of MIDCOM Protocol The principal motivation behind architecting MIDCOM protocol is to enable complex applications through middleboxes, seamlessly using a trusted third party, i.e., a MIDCOM agent. MIDCOM agents with application intelligence can assist the middleboxes through the MIDCOM protocol in permitting applications. Middleboxes supporting the MIDCOM will be able to externalize application intelligence into MIDCOM agents. 4.1. Authentication A MIDCOM session is an authenticated and authorized association between agent and middlebox. Sessions are initiated by agents and can be terminated by either the agent or the middlebox. Session setup must be preceded by registration of the MIDCOM agent with either the middlebox or the MIDCOM PDP. The MIDCOM PDP acts in an advisory capacity to a middlebox, to authorize or terminate authorization for an agent attempting connectivity to the middlebox. The MIDCOM PDP maintains a list of agents that are authorized to connect to each of the middleboxes the MIDCOM PDP supports. Mutual authentication between agent and middlebox are required for session establishment between them. Security credentials, such as authentication challenge tokens and authentication tokens, are exchanged between agent and middlebox as message parameters. A successful authentication will lead to an established session between Wang & Gu Expires December 20, 2011 [Page 7] Internet-Draft GapAnalysis June 2011 them. 4.2. Policy Rule Configuration The primary task for MIDCOM protocol is to assist agents in configuring policy rules on middleboxes. Each MIDCOM policy rule contains a single action, either action "reserve" or action "enable". For any policy reserve rule, the policy condition is always true. The action is the reservation of just an IP address or a combination of an IP address and a range of port numbers on neither side, one side, or both sides of the middlebox, depending on the middlebox configuration. For any policy enable rule, the policy condition consists of a descriptor of one or more unidirectional or bidirectional packet flows, and the policy action enables packets belonging to this flow traverse the middlebox. 4.3. Agent(s) - Middlebox(es) The MIDCOM protocol allows a MIDCOM agent to communicate with more than one middlebox simultaneously, and vice versa. That is to say, both agent and middlebox may participate in several sessions at the same time. 4.4. Transaction & Atomicity Protocol interactions are structured into transactions. Different types of transactions are defined, and they can be further grouped into transaction groups concerning certain conditions. All request transactions are atomic with respect to each other. This means that processing of a request at the middlebox is never interrupted by another request arriving or already queued. In this way, the atomicity of every single transaction can be guaranteed. However, asynchronous transactions may interrupt and/or terminate processing of a request at any time. 4.5. Fault Tolerance In case of the request being processed unsuccessfully, one of the specified reasons will be returned from middlebox to agent, which allows agent behavior to be modified as a result of the information contained in the reason. 5. Gap Analysis MIDCOM protocol contains several concepts that DIM could refer to. However, there are still several requirements of DIM cannot be satisfied by MIDCOM protocol. The following table lists the gaps in Wang & Gu Expires December 20, 2011 [Page 8] Internet-Draft GapAnalysis June 2011 MIDCOM protocol on DIM. +--------------------------------------------+----------------------+ | DIM Requirements | If Supported by | | | MIDCOM | +--------------------------------------------+----------------------+ | Notification accurate migration time to | No | | devices | | | Mutual authentication | Yes | | Dynamic information transferring | No | | Configure DI on destination devices | No | | Delete DI from source devices (how & when) | No | | Peer-to-peer interaction | Yes | | Peers-to-peer interactions | Yes | | Peer-to-peers interactions | Yes | | Interaction atomicity | Yes | | Notify failure and reply reason | Yes | | Symmetric architecture in the same DC | Yes | | domain | | | Asymmetric architecture in the same DC | No | | domain | | | Between two different DC domains | No | +--------------------------------------------+----------------------+ 5.1. Could be Reused Firstly, we describe the characteristics of MIDCOM protocol which can be reused in DIM or through improvement. To verify legal identities between network devices, the mechanism of "registration and mutual authentication" in MIDCOM could be applied in DIM. Transactions in MIDCOM protocol can be utilized to ensure atomicity of DIM transactions. In this way, mutual interference among different migrations could be avoided. Fault tolerance is another mechanism that DIM can refer to. In MIDCOM, failure reasons are specified and replied to agent while middlebox cannot process its partner's request. However, much stronger fault tolerance capability might be required considering much more complicated failure situations during DIM. 5.2. New Features As we described above, some DIM requirements are beyond the semantics of MIDCOM protocol, e.g., capability negotiation between two devices, dynamic information transferring, and so on. Some of them are Wang & Gu Expires December 20, 2011 [Page 9] Internet-Draft GapAnalysis June 2011 presented below. Firstly, capability negotiation between network devices is not satisfied by MIDCOM protocol. Secondly, dynamic information transferring is not satisfied by MIDCOM protocol. If DIM takes place between two middleboxes, taking proxy firewall for example, TCP connection table must be migrated while VM migrates. Lack of such information makes running services disrupted. According to MIDCOM protocol, each item in TCP connection table can be transferred through request messages just as the way configuring single dynamic policy rule. However, in DIM, this request-configure kind of mechanism might result in a 'giant project'. Assuming a VM acts as a WEB server which provides web service to external clients, there might be hundreds, even thousands, of TCP connections on corresponding proxy firewall. Since the number of TCP connection table items that need to be migrated is huge, it might be a 'mission impossible' to transfer it per item by using MIDCOM. We consider that dynamic information could be packed into files and then transferred through some file transferring protocols, such as FTP and HTTP. On destination devices, files from the source device could be encrypted for security reason. Also, if the concept of "transfer dynamic information as files" is taken, another capability might be required for DIM, that is, file configuration capability. Finally, although in MIDCOM protocol, policy rules configured on middlebox would age out when their life time expires, it still cannot meet the requirement of dynamic information elimination. After VM migrates to new location, the dynamic information on original devices might be taken advantage by malicious attackers, if it is not eliminated in time. The elimination should be performed right after the VM running normally on destination device. How to notify all related devices the proper time to eliminate dynamic information on them cannot be addressed by MIDCOM protocol. Also, MIDCOM protocol doesn't supply a proper way to delete dynamic information from network devices. 6. Conclusions As the leading Standard Development Organizations (SDOs) on making the Internet work better, IETF is a suitable place to address the above mentioned gaps by studying and enhancing existing network protocols to meet all requirements of DIM. A potential working scope can be: define new protocol to support DIM in various scenario. Wang & Gu Expires December 20, 2011 [Page 10] Internet-Draft GapAnalysis June 2011 7. Security Considerations Security considerations have been discussed in section 5. 8. References 8.1. Normative Reference [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", August 2002. [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", August 2002. [RFC5189] Stiemerling, M., Quittek, J., and J. Quittek, "Middlebox Communication (MIDCOM) Protocol Semantics", March 2008. [RFC5190] Stiemerling, M., Quittek, J., and J. Quittek, "Definitions of Managed Objects for Middlebox Communication", March 2008. 8.2. Informative Reference [Data_Center_Fundamentals] "Data Center Fundamentals", 2003. Authors' Addresses Wang Danhua Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-56624734 Fax: +86-25-56624702 Email: wangdanhua@huawei.com Wang & Gu Expires December 20, 2011 [Page 11] Internet-Draft GapAnalysis June 2011 Gu Yingjie Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-56624760 Fax: +86-25-56624702 Email: guyingjie@huawei.com Wang & Gu Expires December 20, 2011 [Page 12]