Delegation-Oriented Architecture

Delegation-Oriented Architecture (DOA)

Description Papers Talks SFR (Sibling Project) People Funding Contact

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

A Layered Naming Architecture for the Internet (position paper): DOA is based on some of what is described in this position paper. The position paper touches on various issues -- including mobility, multi-homing, network-level middleboxes, and application-level middleboxes -- with scant attention to design details or implementations. DOA tries to bring some of those nebulous architectural mutterings into focus and accordingly concentrates exclusively on network-level intermediaries, ignoring their application-level counterparts. Some of the application-level ideas that DOA ignores are covered by the Semantic-Free Referencing (SFR) project.

i3: The two main mechanisms in DOA have, in some form, appeared in other projects, such as i3. Here is a brief comparison of DOA and i3: Like DOA, i3 is specifically designed for senders and receivers to invoke intermediaries; i3 is not intended to be an extension to the Internet architecture that coherently accommodates NATs and firewalls; identifiers under i3 refer to services whereas identifiers under DOA refer to hosts; and, what is the main technical difference, the DOA architecture requires an infrastructure to resolve identifiers while i3 depends on an infrastructure to forward packets -- under the pure i3 design, packets are sent into the infrastructure, and the infrastructure delivers the packets to their ultimate destination.

There is a lot of work besides i3 that is related to DOA. For a summary of this literature, please see the Related Work section of our paper Middleboxes No Longer Considered Harmful.

Papers

Middleboxes No Longer Considered Harmful [PS | PDF | Bibtex]
Michael Walfish, Jeremy Stribling, Maxwell Krohn,
Hari Balakrishnan, Robert Morris, and Scott Shenker
Proceedings of USENIX OSDI, San Francisco, CA, December 2004.
A Layered Naming Architecture for the Internet [PS | PDF | Bibtex]
Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy,
Scott Shenker, Ion Stoica, and Michael Walfish
Proceedings of ACM SIGCOMM, Portland, OR, September 2004.

Talks

A Layered Naming Architecture for the Internet. SIGCOMM '04. September 2, 2004. ppt
A Layered Naming Architecture. HIP Research Group, IRTF, 60th IETF. August 6, 2004. ppt