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]
