Middleboxes No Longer Considered Harmful (DOA)

This paper talks gives our first glimpse into the contentious world of Internet architecture by talking about how an architecture could support middle boxes, and designing such a delegation-based architecture called DOA. I had mixed views on the paper. On the one hand, it uses some interesting tricks to achieve some of its properties, such as a flat namespace of self-certifying names, allowing indirection through a global soft-state redirection service, and marking that a packet has passed through a filtering service using a MAC. On the other hand, I think that both the motivation and the practicality of the idea are a bit lacking.

The basic idea of DOA is to have extra fields in the packet (by treating DOA as another protocol under IP, at the same level as TCP and UDP), which store destination and source "endpoint IDs". These EID's are unique accross hosts and self-certifying, so you can tell whether you are being routed to the real owner of an EID. DOA maps EIDs to IP addresses or to chains of intermediate EIDs using a global resolution service such as a DHT.

My first concern is about motivation. Sure, middleboxes are unpleasant, but the Internet has managed to work more or less okay despite them. Many applications are client-server, and the servers have no trouble obtaining a globally accessible IP address and in fact use middleboxes for load-balancing, security, fault-tolerance, etc. Peer-to-peer applications, such as VOIP and video games, use NAT punchthrough mediated by a globally accessible server to establish direct connections to each other (though, admittedly, this does not always work and requires the application to use UDP). If DOA's only motivation is that it will take something that already kind of works and make it architecturally clean, there's little reason to adopt it and go change all Internet software stacks to work with it. Any proposal for new Internet architecture should say "look, here are some brand new things we'll enable you to do that were completely impossible before, and by the way, we also fix middleboxes as a nice side-effect".

My second concern is about practicality. NATs and firewalls are undoubtedly successful because of how easy they are to deploy - neither applications nor other parts of the network need to be changed for them to be useful. In fact, whether we planned the Internet's routing model carefully or not, the fact that it's so simple that adding a box on the path between two nodes can achieve filtering could arguably be a good thing - the "thin waist" also means service composition is possible. DOA requires modifying all end hosts and software stacks to use a new form of address, which is almost certainly undeployable. The paper should have tried harder to provide a story about how existing applications could be made to work through it, through some kind of tunneling, special IP address range, modified DNS, or whatever.

Finally, one disturbing thing mentioned in the paper is how it points out that the Internet research community had "derided" middleboxes due to their architectural uncleanness. It's really strange to see a research community deriding a product built by its users that is obviously meeting commercial demands! This would be like the OS community "deriding" applications that bypass the filesystem and decide to control the layout of their data structures inside a big file themselves, or applications that control their own caching without using virtual memory. The research community will never be able to anticipate all user needs, but when it fails to do so, it should work on how to meet these needs, not deride the users beacause they are breaking whatever architecture the community agreed was good!