Entry Date:
August 3, 2007

Delegation-Oriented Architecture (DOA)

Principal Investigator Hari Balakrishnan


Intermediate network elements, such as network address translators (NATs), firewalls, and transparent caches are now commonplace. The usual reaction in the network architecture community to these so-called middleboxes is a combination of scorn (because they violate important architectural principles) and dismay (because these violations make the Internet less flexible). While we acknowledge these concerns, we also recognize that middleboxes have become an Internet fact of life for important reasons. To retain their functions while eliminating their dangerous side-effects, we propose an extension to the Internet architecture, called the Delegation-Oriented Architecture (DOA), that not only allows, but also facilitates, the deployment of middleboxes. DOA involves two relatively modest changes to the current architecture: (a) a set of references that are carried in packets and serve as persistent host identifiers and (b) a way to resolve these references to delegates chosen by the referenced host.

During the Internet's youth, every network entity had a globally unique, fixed IP address. However, the emergence of private networks, among other things, ended the halcyon days of unique identity and transparent reachability. Now, many Internet hosts have no globally unique handle that serves to direct packets to them. This deficiency has hindered or halted the spread of newer protocols, such as SIP and various peer-to-peer systems.

Another principle of the Internet is that network elements should not process packets that are not addressed to them. However, this decades-old guideline has become an empty commandment, as firewalls, network address translators (NATs), transparent caches, and other widely deployed network elements use higher-layer fields to perform their functions. The result of these layer violations is rigidity in the network infrastructure, as the transgressing network elements may not accommodate new traffic classes.

The hundreds of IETF proposals for working around problems introduced by NATs, firewalls, and other layer-violating boxes are compelling evidence that middleboxes (as such hosts are collectively known) and the Internet architecture are not in harmony. Indeed, because middleboxes violate one or both tenets above, Internet architects have traditionally reacted to them with disdain and despair.

We take a different view. Rather than seeing middleboxes as a blight on the Internet architecture, we see the current Internet architecture as an impediment to middleboxes. We believe they exist for important and permanent reasons, and we think the future will have more, not fewer, of them.

The market will continue to demand middleboxes for various reasons. NATs maintain and bridge between different IP spaces; now, some hosts are separated from the "global" Internet by several layers of NAT, as in the picture at the right. Firewalls and other boxes that intercept unwanted packets will be increasingly needed as attacks on end-hosts grow in rate and severity. Since even sophisticated users have difficulty configuring PCs to be impervious to attack, we believe that users would want to outsource this protection to a professionally managed host -- one not physically interposed in front of the user -- that would vet incoming packets. Under the current architecture, such outsourcing to "off-path" hosts requires special-purpose machinery and extensive manual configuration. Intermediaries can also increase performance through, for example, caching and load-balancing. Commercial service providers will continue to take advantage of such performance-enhancing middleboxes, disregarding architectural purity.

The goal is an architecture hospitable to middleboxes, specifically one that allows middleboxes to avoid architectural infractions and to retain the same functions as today. Such an architecture would let a variety of middleboxes be deployed while also letting end-system protocols evolve independently and quickly.

To achieve this goal, we propose the Delegation-Oriented Architecture (DOA), which consists of two relatively incremental extensions to the current Internet architecture. First, all entities have a globally unique identifier in a flat namespace, and packets carry these identifiers. Second, DOA allows senders and receivers to express that one or more intermediaries should process packets en route to a destination. This delegation lets the resulting architecture embrace intermediaries as first-class citizens that are explicitly invoked and need not be physically interposed in front of the hosts they service. DOA's contribution is defining a relatively incremental extension to the Internet architecture that coherently accommodates network-level intermediaries like NATs and firewalls. DOA requires no changes to IP or IP routers but does require changes to host and intermediary software. However, these changes are modular, and current applications can be easily ported.