�ݺ�ߣ

Middleboxes:
Why all the Hate?
Justine Sherry
(Neither taking nor TA’ing this class, but somehow presenting.)

Why all the hate?
“Middleboxes violate the E2E principle.”

“Middleboxes encourage architectural ossification.”

“Middleboxes create reachability problems.”
“It’s like the formerly two-way Internet has a bunch of one-
way streets.”

“Middleboxes cause new and wonky failures.”

"Middleboxes create management complexity – they’re
just confusing to administer.”

Quick Taxonomy

Architectural Issues Managerial Issues

Confusing &
One-Way Expensive
Complex
Streets E2E Reliability
Architectural
Ossification

Hold up.
These are a lot of issues!

Why have middleboxes been so successful despite these
problems?

What’s good about them?

The Good Stuff
The features they provide are desirable! – Security,
performance, etc.

Ability to impose centralized, unilateral control over
protocol usage, resource consumption, etc, /without/
control of end host itself.

Ease of deployment .– just “drop in”

Nevertheless…

Back to Our Taxonomy


Confusing &
One-Way Expensive
Complex
Protocol
Ossification



Confusing &
One-Way Expensive
Complex
Protocol
Ossification
APLOMB (+Steve’s Discussion)



Confusing &
One-Way Expensive
Complex
Protocol
Ossification

Where I’m headed with this.
Let’s go through these one-by-one.

The End to End Argument
“The function in question can completely and correctly be
implemented only with the knowledge and help of the
application standing at the end points of the communication
system. Therefore, providing that questioned function as a
feature of the communication system itself is not possible.
(Sometimes an incomplete version of the function provided
by the communication system may be useful as a
performance enhancement.)

We call this line of reasoning against low-level function
implementation the "end-to-end argument."
[Saltzer, Reed, and Clark 89]

The One-Way Street Problem
Inbound connections to a host are blocked/filtered by a
middlebox, but outbound connections work just fine.

The One-Way Street Problem

Network address translation:
Goal: allow multiple “internal” hosts to all share a public
“external” IP address
Problem: When an inbound SYN comes to the shared IP
address, how do we know which host to send it to?

Firewalls:
Goal: protect internal hosts from traffic that appears
malicious; e.g., destined to inbound ports that are often
abused
Problem: What if I really do want to enable SSH logins, host
an IRC server, or run an FTP server on my internal server?

Is the One-Way Street Problem
fundamental to middleboxes?

Can we design middleboxes to
solve the One-Way Street
Problem?

Some Proposals
Stuart Cheshire and Marc Krochmal. NAT Port Mapping Protocol
(NAT-PMP). RFC Internet Draft. http://tools.ietf.org/html/draft-cheshire-
nat-pmp-07

Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan,
Robert Morris, and Scott Shenker. 2004. Middleboxes no longer
considered harmful. In Proceedings of the 6th conference on
Symposium on Operating Systems Design & Implementation - Volume
6 (OSDI'04), Vol. 6. USENIX Association, Berkeley, CA, USA, 15-15.

Justine Sherry, Daniel C. Kim, Seshadri S. Mahalingam, Amy Tang,
Steve Wang and Sylvia Ratnasamy. Netcalls: End Host Function
Calls to Network Traffic Processing Services. UC Berkeley
Technical Report No. UCB/EECS-2012-175

Protocol Ossification
Aha! Now she gets to the paper:

Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam
Greenhalgh, Mark Handley, and Hideyuki Tokuda. 2011. Is it
still possible to extend TCP?. In Proceedings of the 2011
ACM SIGCOMM conference on Internet measurement
conference (IMC '11). ACM, New York, NY, USA, 181-194.

“The great virtue of the Internet was always that it was
stupid; it did no task especially well, but it was extremely
ﬂexible and general, allowing a proliferation of protocols
and applications that the original designers could never
have foreseen.”
[Honda et al. IMC 04]

“To improve performance, reduce security exposure,
enhance control, and work around address space
shortages, the Internet has experienced an invasion of
middleboxes that do care about what the packets contain,
and perform processing at layer 4 or higher within the
network.” [Honda et al. IMC 04]

The Paper (1 �ݺ�ߣ Summary)

Question: Is it true that middleboxes are threatening our
ability to upgrade or evolve TCP?

Answer: Yes, in some cases.
Ran several tests with non-traditional TCP behaviors
(missing segments, TCP options…) to test deployability of
three real TCP extensions
“We ﬁnd that MPTCP is likely to work correctly in the Internet or
fall-back to regular TCP. TcpCrypt seems ready to be deployed,
however it is fragile if resegmentation does happen - for
instance with hardware ofﬂoad. Finally, TCP extended options in
its current form is not safe to deploy.”

Why I love this paper
Vague claims about architectural issues abound.
Middleboxes “can” or “might” interfere is different than
middleboxes “do” interfere.

This paper took a piece of common wisdom that was
thrown around, and thoroughly demonstrated through
measurements to what extent it was a problem and how
so.

Further, their examples aren’t toys – these guys attack the
problem as real protocol designers who are trying to get
their stuff deployed, and middleboxes are giving them
heck.

On to your ��ǳ��Գٲ�…

Is the data representative?
“I was not very happy with the dataset used for the experiments.
First, the sample size is too small and not divergent enough.” –
(just about everyone)

“Second, the authors target “access networks”. But it is
anecdotally known that most middleboxes in the Internet are
deployed in “enterprise (server? datacenter?) networks”. While
my ex-company had literally thousands of customers, the
revenue from consumer ISPs was really tiny. Deploying
middleboxes in access networks is not cost-effective
(middleboxes are expensive), somewhat pointless (what is the
return for the ISP?), politically disputable (network neutrality),
and potentially dangerous (dear QA, my online game doesn’t
work anymore!).”

Do we actually need to extend
TCP?
“From an evolveability perspective, the deployment of
entirely new transport protocols seems more interesting
than the deployment of incremental options to TCP. Has
anyone done a study of middlebox's effect on entirely
unknown transport protocols?”

“I think this problem could be important if people are still
struggling to modify TCP...”

To what extent is solving this in
the hands of MB vendors?
“I feel like middleboxes, as elements and players of
network, should also follow their own rules, to simplify the
work of others and be enablers of network evolution,
rather than black boxes and impediments”

“This makes me wonder whether middlebox badness is
that big a deal? Isn't it just a matter of fixing a few
middleboxes that were not behaving properly?”

“By raising the issue now, it's possible to influence how
vendors implement it as it becomes more widely
available…”

Are middleboxes the problem?

While I agree that it has become difficult to expand
network functionality, I am not fully convinced that
middleboxes are the primary cause of this problem.
Rather, I think the global nature of modern networks is
what makes it hard to implement new features: you need
to reach global agreement and acceptance, followed by
worldwide deployment to make use of new network
features. In my mind, middleboxes play an extremely
small role in this regard, and thus, I don't fully buy in to the
authors' arguments.

Is it still possible to extend
TCP?
What do you think?
What do the authors think?

Back to Protocol Ossification:
is protocol ossification
fundamental to middleboxes?
Can we redesign things such
that it isn’t a problem?

What’s next for middleboxes?
Should we throw them out?
Follow the status quo?
Do something in the middle?

Justine still loves middleboxes.

�ݺ�ߣ

Middlebox hate blog

More Related Content

Similar to Middlebox hate blog (20)

Middlebox hate blog

Editor's Notes