Network Working Group M. Shore Internet-Draft No Mountain Software Expires: December 13, 2013 Y. Gu Huawei S. Sivakumar Cisco Systems June 11, 2013 Middlebox considerations in NVO3 overlay networks draft-shore-nvo3-middleboxes-00 Abstract This document examines middlebox considerations in nvo3 overlay networks. We are concerned with both the impacts of middlebox presence on nvo3 overlays, and the impacts of nvo3 overlays and encapsulations on middlebox function. 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 December 13, 2013. Copyright Notice Copyright (c) 2013 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 Shore, et al. Expires December 13, 2013 [Page 1] Internet-Draft NVO3 and Middleboxes June 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Middlebox function within a network . . . . . . . . . . . . . 4 3. Middleboxes and NVO3 . . . . . . . . . . . . . . . . . . . . . 5 3.1. General considerations . . . . . . . . . . . . . . . . . . 5 3.2. VM mobility . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Firewalls . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Network Address Translation . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Shore, et al. Expires December 13, 2013 [Page 2] Internet-Draft NVO3 and Middleboxes June 2013 1. Introduction This document describes issues stemming from the presence of middleboxes in networks where nvo3> overlay networks are present. We address both the impacts of nvo overlay networks and encapsulation on middlebox function, and of middlebox presence on nvo3 overlays. Much has been written about middleboxes, about middlebox impacts on networks and on transport and application protocols, about workarounds and accommodations, etc. Among recent documents, the multipath TCP (mtcp) working group has done a particularly good job describing [RFC6182] the problems introduced by the presence of middleboxes in IP networks. It is no longer safe (if it ever was) to assume that the network path between two endpoints is completely transparent, and that traffic is not being modified or inspected. Middleboxes in the network may include: o Firewalls o NAT (Network Address Translators) o Tunnel endpoints o Application-level gateways o TCP accelerators o TCP proxies among others. Please see [RFC3234] for a comprehensive, if somewhat outdated, list. This document tries to address specific impacts, but it should be understood that there are broader issues around complexity and manageability that are problematic but out of scope for this paper. Also, note that in this initial version of the draft we will be focusing on firewall and NAT middleboxes, with subsequent revisions introducing discussions of other types of middleboxes. Shore, et al. Expires December 13, 2013 [Page 3] Internet-Draft NVO3 and Middleboxes June 2013 2. Middlebox function within a network Because middleboxes are not endpoints for a communication, they typically (but not always) function by inspecting and/or modifying traffic that flows across them. For example, firewalls look into packets for particular pieces of data (addresses, protocol numbers or ports, application-specific pieces of data) as traffic flows across them. This implies several preconditions or other considerations: o the traffic must be readable by the firewalls, which is to say that it must either be unencrypted or that the firewall must have a copy of the decryption key o the data of interest must be "findable," either because they're at a fixed location within a packet or that there are other data in the packet that give the data of interest's location. o Because NAT rewrites addresses in IP headers, and potentially rewrites application endpoint addresses in "session-oriented" protocols (VoIP, for example), there may be issues with integrity- protecting traffic. If an address that is rewritten as part of a NAT process is included in integrity-protected data, validation of the data will fail. ("Content-aware" firewalls, which may also rewrite data, but in the application layer, can introduce the same problem) o It should also be noted that NAT incidentally functions as a (partial) route-pinning device, in that when a NAT writes its address into the source address of an IP packet, it is forcing return traffic through that same device. Shore, et al. Expires December 13, 2013 [Page 4] Internet-Draft NVO3 and Middleboxes June 2013 3. Middleboxes and NVO3 3.1. General considerations Middleboxes make policy (or policy-like) decisions based on packet content. Consequently, as described above, the packet contents used as a basis for policy decisions need to be accessible to the middlebox, particularly in cases where the default action is to drop a packet unless its contents match a permitted policy. As a result, packet encapsulations and tunneling protocols risk of having their contents dropped if a firewall or other type of middlebox is unable to determine whether or not the traffic conforms to permitted policy. Again, the conditions which might lead to this are o The middlebox being unable to locate the data of interest because the encapsulation offsets the data from the beginning of the packet, and o The data are encrypted and unreadable There may be considerable architectural advantage to co-locating middlebox functions with nvo3 NVEs. 3.2. VM mobility The nvo3 working group has identified Virtual Machine (VM) mobility as a problem that must be addressed by their specifications. In particular, there is an expectation that the live migration of a VM both within a data center or between geographically disparate data centers will be "seamless," or that network sessions will not be interrupted when a VM migrates. In particular, the IP addresses and MAC addresses of the VM will remain the same. 3.2.1. Firewalls Firewalls may be located in a variety of locations within a data center, and this may impact the ability of a VM to migrate without interrupting live network sessions. Firewall placement can have a varying degree of closeness, or coupledness, with the systems the firewall protects. Here are some examples of firewall placement, working from closely coupled with the system the firewall protects to very loose coupling: Shore, et al. Expires December 13, 2013 [Page 5] Internet-Draft NVO3 and Middleboxes June 2013 o A firewall may be running on a server, protecting only that server. This is often referred to as a "host-based" firewall. Examples include Linux's iptables and FreeBSD's ipfw. These are typically implemented as kernel modules and may sit between the NIC and the network stack o A firewall may be running on a hypervisor, underneath a VM. The firewall is not visible to the VM's operating system and is logically similar to a stand-alone firewall or a firewall embedded in a router. o A firewall may be running on an appliance or embedded in a router and be placed at the border between two administratively or policy disparate networks, such as between a branch office network and a central data center network. Firewalls traversed by traffic between a mobile or migrating VM and a network peer will have traffic-associated state, such as a pinhole allowing the traffic through the firewall. A pinhole may be created in several ways, such as o explicit configuration: a network administrator configures a firewall pinhole on a given port or for a given application between the mobile VM and a particular peer o policy conformance: local policy may be configured to allow traffic through if it meets certain criteria, such as an "external" address range, traffic initiated from inside the firewall always being permitted, etc. Regardless of how the state is instantiated, if that state is not migrated with the VM and there is a new firewall on the path between the migrated VM and its network peer, there will not be pinholes for the traffic and the traffic will be blocked (dropped). The only case in which state is currently migrated is in the case of host firewalls. 3.2.2. Network Address Translation NATs are often seen as being similar to firewalls, and it is the case that they play a similar role in enforcing boundaries between logically distinct networks, and that they have similar impacts on network topologies. In some cases they may have static mappings configured between external addresses/ports and internal addresses/ ports, but in nearly all cases any traffic that traverses them has the address of a device behind the NAT translated to another address. This has two consequences of interest: Shore, et al. Expires December 13, 2013 [Page 6] Internet-Draft NVO3 and Middleboxes June 2013 o Each packet traversing the device is being modified, and o Traffic from outside is being addressed to the NAT, imposing loose routing on the packet There are at least two scenarios of interest when considering a Virtual server migration and NAT. In the first case, the newly-migrated server is behind the same NAT device that it was prior to migration. When this is the case the new server could either be using the same IP address and listening on the same port for the service, or it can have a different IP address but relies on the NAT to map the external address to the current active server. Assuming that the new server is using the same IP address, the migration is transparent to the NAT device, NAT just translates the packets and forwards it. The new server would have all relevant state information migrated with it, and is ready to process packets. This is the simplest case. If the new server is listening on a different IP address, this could mean that a new NAT mapping will have to be installed once all the state migration is done between the new and the old servers. For example, the IP address of old server is S1 and is mapped to the external address on the NAT device as E1, when the old server has completely migrated to the new server, some external entity on the network (preferably the hypervisor) will remove the existing mapping between S1 and E1 and install a new mapping between S2 and E1, where S2 is the IP address of the new server. Note, the external address will remain unchanged thus hiding the internal changes in the network. The second scenario is that the server is migrated to a new location that is not behind the same NAT device as it was previously. Because of the asynchronous nature of IP communication, packets can arrive at the old NAT even after the server migration is complete. In this case, the NAT translates the IP address but will route the packet in a sub-optimal way to new server. However, the packets could be dropped or incorrectly routed if the internal address of the server is not routable by the old NAT device or if there are overlapping addresses in the network. When the server migrates in such a way that it is not behind the same NAT device, the state on the NAT device should also be migrated, so that all the packets are routed to the new NAT device on the path. If the NAT is not migrated along with the server state, the session may have to be re-established depending on the application (Eg. VoIP or FTP). Shore, et al. Expires December 13, 2013 [Page 7] Internet-Draft NVO3 and Middleboxes June 2013 4. Security Considerations Middlebox interactions are nearly always rife with security issues, in large part because for the middlebox to treat packet correctly in conformance with its policy, information about that packet must be exposed, whether it's address information or actual packet contents. We know that there are deployments of technologies, such as VoIP, where the deployer has chosen to forgo applying security technologies in favor of making the traffic available to their middleboxes. It should be noted that this is happening with or without nvo3 and is not peculiar to nvo3. However, in situations in which VMs are migrating between physical networks and middlebox state must be migrated as well, there is a risk of the state migration technology being used to hijack traffic, perform a Denial-of-Service (DoS) attack, or to create other compromises. Any time a new middlebox communication protocol is deployed it creates new security exposures. Shore, et al. Expires December 13, 2013 [Page 8] Internet-Draft NVO3 and Middleboxes June 2013 5. Informative References [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. Shore, et al. Expires December 13, 2013 [Page 9] Internet-Draft NVO3 and Middleboxes June 2013 Authors' Addresses Melinda Shore No Mountain Software PO Box 16271 Two Rivers, AK 99716 US Phone: +1 907 322 9522 Email: melinda.shore@nomountain.net Yingjie Gu Huawei Phone: +86-25-56624760 Fax: +86-25-56624702 Email: guyingjie@huawei.com Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, NC US Email: ssenthil@cisco.com Shore, et al. Expires December 13, 2013 [Page 10]