Middlebox hate blog

Middleboxes: Why all the Hate?

Justine Sherry(Neither taking nor TA’ing this class, but somehow presenting.)

Why all the hate?

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 &Complex

ReliabilityExpensiveOne-Way

Streets ArchitecturalOssification

E2E

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 &Complex


Streets ProtocolOssification

E2E



Confusing &Complex



E2E

APLOMB (+Steve’s Discussion)



Confusing &Complex



E2E

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 flexible 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 Slide 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 find 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 offload. 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 comments…

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.

Documents

Middlebox hate blog