Grudge Match (TM) to Jump the Shark (TM)?

Now that I've got my "I like end-systems doing the heavy lifting" rant out there, it's time to lighten up for a bit.

One of my favorite humor sites is the World-Wide Web Fights - Grudge Match page. They take the 4th-grade (age 9 for our international readers) concept of "oooh, what if the Enterprise took on the Death Star?" to its maximum silliness and fun. I've been a regular reader (and occasional Bronze-Medal contributor as well) for most of its 10 years of existence.

So now, their current match has the interesting property of having cursed-actor Ted McGinty as one of the contestants... and their hint for their next match is "Jumping the Shark", which I'll let readers follow this link to see background information on the term.

I was concerned that one of my favorite sites would not make it to its 10-year anniversary. So I sent a mail, and got this enigmatic response (full poor-form top-posted reply included):

To: danmcd@kebe.com
Subject: Re: You're not going off the air, are you?

I can neither confirm nor deny these rumors.

- Brian (tm)

Dan McDonald wrote:
> 
> Please tell me it's a 10-year anniversary stunt... bringing Ted McGinley
> aboard, and then teasing us about Jumping the Shark... please, please, please
> don't go off the air!
> 
> A fan since 1995 (and recipient of both a Final Word and a Bronze Grudgie),
> Dan McD.

-- 
- Brian Wright
WWWF Grudge Match
http://www.grudge-match.com/

"So consistently funny it ought to be developed into
a series for Comedy Central!"
                                - Entertainment Weekly

So I'm hoping it's just a stunt - and a funny one at that. If you're semi-knowledgible about American pop culture, you'll probably bust a gut at some of the matches on this site. Please click that link above and visit... before it's too late?!?

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.