I hate middleboxes...

Ever since I worked on one of the early IPv6 implementations, I've had a sour taste in my mouth for any node in the middle of a network that did more than forward packets (or maybe one or two other things, which I'll talk about later).

Nodes that are in the middle of the network and do not merely forward packets I will call middleboxes in this entry. The granddaddy middlebox was the firewall. These were designed to prevent classes of packets (often very large classes of packets) from reaching a network that was connected to the Internet. Given the poor state of end-node implementations (anyone remember when sendmail was the biggest source of vulnerabilities?) at the time, firewalls were a sensible solution to the problem.

To cope with people demanding Internet services while still being behind their safe firewall, the proxy came into play. These boxes pretend to be servers for machines on the inside of a firewall, and clients to machines outside the firewall.

To cope with address space "shortages" (especially when the addresses in question might never be seen on the Internet, thanks to firewalling), the Network Address Translator (NAT) was invented. To the outside world, the NAT presents a small number of Internet addresses (often that number is one). Behind the NAT, there is a whole network (usually carved out of addresses that are reserved just for this
purpose) of nodes.

These nodes often cause as many problems as they solve. A server cannot depend on IP addresses (whether or not that's good design is a discussion for another time) any more (even if they're secured with IPsec). IPsec itself does not work without the NAT-Traversal hack (now available in Solaris 10). Anything using a proxy is prone to failure if the proxy is flaky - my outbound ssh sessions often disappear because the proxy times them out. With most middleboxes, state that should only be on the two the end-nodes is now distributed to a third, or more. And often, that third node is out of the user's control.

There are some good cases for having some set of middlebox functionality. Alec Muffet has convinced me with
defense-in-depth arguments that some set of firewall functionality is useful in various environments. I can understand (but still despise) NAT in places where stingy ISPs only allow one address per subscriber, or worse, do NAT for you. We are where we are today because a lot of this was a market-driven reaction to poor implementations of network service applications (and in some cases the OS as well). We in OS and network-service development can, of course, fix this if we try hard enough. I'd suggest looking at recent articles about what historical development practices have wrought.

I think we all finally understand what our responsibilities are as end-node engineers. The sooner we act on those responsibilities, the sooner we can remove any excuses for the new classes of bridge trolls to exist. (Did I mention anyone who likes this blog should visit David Reed's excellent site?) And if any folks out there are dissatisfied with their current choice, I hope that they realize that the market will provide other choices.