corporate networks—but these behaviors are more common today than they
were in 2002 when the article was written. Nonetheless, it remains the most
comprehensive survey of middlebox
functionality to date, and most of the
features it describes remain in common use.
What Does an NFV-Managed
Network Look Like?
Palkar, S., Lan, C., et al. 2015. E2:
A framework for NFV Applications.
ACM Symposium on
Operating Systems Principles.
This article provides the cleanest vision
for an NFV-managed cluster to date.
The authors describe a system called
E2, which automatically schedules and
configures network functions on a cluster of general-purpose servers. E2 allows
a network administrator to specify a
“configuration” (for example, all traffic on port 80 should be routed through
this HT TP proxy, all traffic to this subnet
should be processed by an IDS), and the
framework will automatically instantiate software instances and a routing
configuration to ensure that the policy is
met. E2 is conceptually similar to cloud
frameworks such as OpenStack or Right-Scale but in practice involves many different technical challenges, including
scheduling to ensure bandwidth is not
overutilized, ensuring low latency, and
enabling efficient communication and
“chaining” between network functions.
Can I Control How Network
Functions Process My Traffic?
Naylor, D., et al. 2015. Multi-Context TLS
(mc TLS): Enabling secure in-network
functionality in TLS.
Sherry, J., et al. 2015. BlindBox:
Deep packet inspection over encrypted
traffic. ACM SIGCOMM.
Today, application developers have
no way of controlling which network
functions process their traffic, short of
making a phone call to their network
administrators. Nonetheless, develop-
ers may have concerns about inspection
or modification of traffic sent by their
applications—especially with regard to
privacy. Hence, many developers choose
to encrypt their entire connection (for
example, using SSL/TLS). While this pre-
serves privacy, it also prevents all benefits
of middlebox processing. These two ar-
ticles propose new cryptographic proto-
cols—mc TLS and BlindBox—that would
let application developers allow certain
middlebox operations but restrict oth-
ers. The two articles propose very dif-
ferent approaches to the same problem
and are worth reading side by side.
What Does NFV Mean
for Application Developers?
As NFV makes the deployment and configuration of network functions/middle-boxes easier, application developers can
expect to see increasingly complex behavior from their networks. While this
capability for complex behavior retains
some of the old challenges of middleboxes (for example, privacy), it also introduces a huge new opportunity for
application developers. NFV enables application developers to run and execute
their code not only on end hosts they
maintain, but also in the network itself.
For example, a developer who designs a custom load-balancing filter
based on a unique service architecture
might write the new code to run on the
load balancer itself. A Web service may
implement a custom cache to serve encrypted content to its users, deploying
the in-network cache within its customers’ ISPs within virtual machines
hosted in the provider’s infrastructure.
With the ability to execute arbitrary
code in the network—and smart routing and scheduling to ensure the right
traffic receives such processing—NFV
opens an entirely new programming
platform for developers. The next big
app store may be for features deployed
within datacenter networks, ISPs, or
even on home routers.
1. NFV ISG. List of members; https://portal.etsi.org/
2. NFV ISG. 2012. Network functions virtualization: An
introduction, benefits, enablers, challenges, and call
for action; https://portal.etsi.org/NFV/NFV_White_
3. Snort; https://www.snort.org/.
4. Squid; http://www.squid-cache.org/.
Justine Sherry is an assistant professor at Carnegie
Mellon University, Pittsburgh, PA, starting in the
Fall of 2017.
Copyright held by owner/author.
Publication rights licensed to ACM.
detection or caching, and physically
installs the device at a chokepoint in
the network such that all traffic entering or exiting the network must pass
through it. Alternatively, an administrator might use an off-the-shelf server
as a middlebox, installing software
such as Snort, Squid, or a proprietary
software package, and then routing
traffic through the server at a chokepoint in the network.
Network functions virtualization
(NFV) is a new movement in networking that takes the software-based approach to an extreme. The NFV ISG
(industry specification group) envisions a future in which all middlebox
functionality is implemented in software.
2 Network administrators will
deploy a server or cluster of servers
dedicated to network functions, and
network virtualization software will
automatically route traffic through
various network functions.
NFV promises many benefits for
network administrators. It reduces
costs by moving from special-purpose
to general-purpose hardware, makes
upgrades as easy as a software patch,
offers the opportunity to scale on demand, and promises more efficient
installations with multiple network
functions potentially sharing a single
server, leaving few resources wasted.
NFV has tremendous momentum in
the networking community—the NFV
working group has more than 200 industrial members1—but is in its infancy and was founded only in late 2012.
Here we present three highlights
from the research community on
middleboxes and NFV, and conclude
by discussing some of the challenges
and opportunities that NFV presents
for application developers.
What Capabilities Do Network
Carpenter, B., Brim, S. 2002. Middleboxes:
taxonomy and issues. RFC 3234, IETF.
Though it predates NFV by about a decade, this article remains a nice summary of the features for which middleboxes
are commonly deployed. The document
could have gone into more depth about
application-layer behaviors such as ex-filtration detection or intrusion detection—increasingly common in today’s