Internet DRAFT - draft-shore-nvo3-middleboxes

draft-shore-nvo3-middleboxes






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]