Delegation-Oriented Architecture (original) (raw)

Description

20 second summary
Remote Packet Filter: an example DOA application.

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.

Harmful Effects of Middleboxes

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.

Our View

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
Example of hosts behind several layers of NAT

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 (see the Remote Packet Filter figure, above). 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.

Our Goal

Our 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.

DOA

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.

Here is a high-level depiction of DOA:

"EIDs" are the globally unique identifiers just mentioned. An "EID" resolves to an "e-record", which can hold a list of intermediaries specified by the EID owner. For the resolution mechanism, the design of DOA presumes a global, DHT-based resolution infrastructure. The format of the "e-record" is:

For more details on DOA, please see our paper Middleboxes No Longer Considered Harmful.

Some have asked if DOA is a pun that refers to our confidence in our architecture's chances for adoption. Answer: of course -- DOA also stands for Destined to Ostensible Adoption.

Relation to Previous Work

Papers

Talks

SFR (Sibling Project)

While DOA instantiates network-level ideas from A Layered Naming Architecture for the Internet, Semantic-Free Referencing (SFR) instantiates analogous application-level ideas.

People

Hari Balakrishnan Maxwell Krohn Robert Morris Scott Shenker Jeremy Stribling Michael Walfish

Funding

This project is being conducted as part of the IRIS project, supported by the National Science Foundation under Cooperative Agreement No. ANI-0225660.

Contact

E-mail doa at the domain nms.csail.mit.edu.