Delegation-Oriented Architecture (DOA)

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:

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.