《计算机网络》课程教学资源（参考文献）Middleboxes No Longer Considered Harmful

Middleboxes No Longer Considered harmful Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari balakrishnan robert morris. and scott shenker MIT Computer Science and Artificial Intelligence Laboratory http://nms.csail.mit.edu/doa Abstract This decades-old guideline has become an empty Intermediate network elements, such as network address commandment, as firewalls, network address translators translators(NATs), firewalls, and transparent caches are (NATs), transparent caches, and other widely deployed now commonplace. The usual reaction in the network ar- network elements use higher-layer fields to perform their chitecture community to these so-called middleboxes is functions a combination of scorn(because they violate important architectural principles)and dismay(because these vi That these tenets are routinely violated is not merely olations make the Internet less flexible). While we ac- an Internet legalism. The inability of hosts in private knowledge these concerns, we also recognize that mid- address realms to pass handles allowing other hosts dleboxes have become an Internet fact of life for impor to communicate with them has hindered or halted the tant reasons. To retain their functions while eliminating spread of newer protocols, such as SIP [24]and various their dangerous side-effects, we propose an extension to peer-to-peer systems [18J Layer violations lead to rigid- the Internet architecture, called the Delegation-Oriented ity in the network infrastructure, as the transgressing Architecture(DOA), that not only allows, but also facili- network elements may not accommodate new traffic tates, the deployment of middleboxes DOA involves two classes. The hundreds of IETF proposals for working relatively modest changes to the current architecture: (a) around problems introduced by NATs [54],firewalls a set of references that are carried in packets and serve as and other layer-violating boxes are compelling evidence persistent host identifiers and(b)a way to resolve these that middleboxres(as such hosts are collectively known) references to delegates chosen by the referenced host. and the Internet architecture are not in harmony Indeed. because middleboxes violate one or both tenets 1 Introduction above, Internet architects have traditionally reacted to The Internet' s architecture is defined not iust by a set of them with disdain and despair We take a different view. Rather than seeing middle protocol specifications but also by a collection of genera. boxes as a blight on the Internet architecture, we see the design guidelines. Among the architecture's origina principles[12] are two tenets at the network layer(i.e, current Internet architecture as an impediment to middle IP layer)that are still widely valued, but are nonetheless boxes. We believe such intermediaries, as we will call often disobeyed in the current Internet them, exist for important and permanent reasons, and we think the future will have more not fewer. of them. #1: Every Internet entity has a unique network The market will continue to demand intermediaries layer identifier that allows others to reach it. During for various reasons. NATs maintain and bridge between the Internets youth, every network entity had a globally fferent IP spaces. Firewalls and other boxes that in- unique, fixed IP address. However, the emergence tercept unwanted packets will be increasingly needed of private networks and host mobility, among othe as attacks on end-hosts grow in rate and severity things, ended the halcyon days of unique identity and even sophisticated users have difficulty configuring PCs transparent reachability. Now, many Internet hosts have to be impervious to attack, we believe that users would no globally unique handle that serves to direct packets 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 #2: Network elements should not process pack- the current architecture, such outsourcing to"off-path ets that are not addressed to them. We call this tenet hosts requires special-purpose machinery and extensive manual configuration. Intermediaries can also increase network element identified by an IP packet,'s destination I Even if the move to ipv6 as networks will field should inspect the packets higher-layer fields. remain. Moreover, private address r rotection against certain types of network attacks. Affiliation: UC Berkeley and ICSl. spaces are a temporary inconvenience that will s

Middleboxes No Longer Considered Harmful Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan, Robert Morris, and Scott Shenker∗ MIT Computer Science and Artificial Intelligence Laboratory http://nms.csail.mit.edu/doa Abstract Intermediate network elements, such as network address translators (NATs), firewalls, and transparent caches are now commonplace. The usual reaction in the network ar￾chitecture community to these so-called middleboxes is a combination of scorn (because they violate important architectural principles) and dismay (because these vi￾olations make the Internet less flexible). While we ac￾knowledge these concerns, we also recognize that mid￾dleboxes have become an Internet fact of life for impor￾tant 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 facili￾tates, the deployment of middleboxes. DOA involvestwo 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. 1 Introduction The Internet’s architecture is defined not just by a set of protocol specifications but also by a collection of general design guidelines. Among the architecture’s original principles [12] are two tenets at the network layer (i.e., IP layer) that are still widely valued, but are nonetheless often disobeyed in the current Internet: #1: Every Internet entity has a unique network￾layer identifier that allows others to reach it. During the Internet’s youth, every network entity had a globally unique, fixed IP address. However, the emergence of private networks and host mobility, 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. #2: Network elements should not process pack￾ets that are not addressed to them. We call this tenet “network-level layering”, and it implies that only a network element identified by an IP packet’s destination field should inspect the packet’s higher-layer fields. ∗Affiliation: UC Berkeley and ICSI. 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. That these tenets are routinely violated is not merely an Internet legalism. The inability of hosts in private address realms to pass handles allowing other hosts to communicate with them has hindered or halted the spread of newer protocols, such as SIP [24] and various peer-to-peer systems [18]. Layer violations lead to rigid￾ity 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 [54], 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 [8]. 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 middle￾boxes as a blight on the Internet architecture, we see the current Internet architecture as an impediment to middle￾boxes. We believe such intermediaries, as we will call them, exist for important and permanent reasons, and we think the future will have more, not fewer, of them. The market will continue to demand intermediaries for various reasons. NATs maintain and bridge between different IP spaces.1 Firewalls and other boxes that in￾tercept 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 1Even if the move to IPv6 accelerates, some IPv4 networks will remain. Moreover, private address realms give some protection against certain types of network attacks. Hence, we do not think private IP spaces are a temporary inconvenience that will soon end

balancing. Commercial service providers will continue cuss mobility and multi rts 2 This paper does not dis- performance through, for example, caching and load- application-level counter ming scenarios either(though to take advantage of such performance-enhancing inter- DOA, because it separates location and identity, could mediaries, disregarding architectural purit with modest extensions--handle those scenarios ). Given Thus, we have a fundamental conflict: although in- our limited focus, dOa should be viewed not as a com- termediaries offer clear advantages, they run afoul of prehensive architecture but rather as an architectural the two tenets above, which causes harm and makes de- component designed to address network-layer middle ploying and using intermediaries unnecessarily hard. Our boxes. Its design presumes IPv4 at the network layer but goal, therefore, is an architecture hospitable to intermedi- DOA is also compatible with, and useful for, IPv6. aries, specifically one that allows intermediaries to abide The final limitation we mention is that some peo by the two tenets, to avoid other architectural infractions, ple want to deploy tenet-violating middleboxes(e.g,a and to retain the same functions as today. Such an archi- censorious government that silently filters packets en- tecture would let a variety of middleboxes be deployed tering and exiting national borders)and that DOA can while also end-system protocols evolve indepen- neither prevent such architecturally suspect middleboxes dently and quickly nor mitigate their damage Oriented Architecture (DOA-is based on two main 2 Background ideas. First, all entities have a globally unique identi- This review of common network-layer middleboxes is fier in a flat namespace, and packets carry these identi- limited to the two we build under DoA--NATs and fiers Second. Doa allows senders and receivers to ex- firewalls--and to a subset of their draw backs for a com- press that one or more intermediaries should process plete review, see [8, 18, 23, 38, 55]. Although NAT and packets en route to a destination. This delegation lets firewalling often combined in one box. these two the resulting architecture embrace intermediaries as first- functions are logically separate class citizens that are explicitly invoked and need no 2.1 NAT and NaPt be physically interposed in front of the hosts they ser- e. Globally unique identifiers and delegation have Network Address Translation(NAT) and Network Ad- isted in previous work describing different architectures dress Port Translation(NAPT) [54 have several uses (e.8, 13 [57)); see 89 for details. This papers contribu- For the purposes of this paper, we assume the follow- tion is defining a relatively incremental extension to the ing common scenario: a NAT or NAPT box bridges two Internet architecture, DOA, that coherently accommo address realms, at least one of which is private. Private dates network-level intermediaries like Nats and fire. addresses are unique within an address realm but am- changes to IP or IP ro biguous between address realms [46]: public addresses does require changes to host and intermediary software. are globally unique and reachable from all Internet hosts However, these changes are modular, and current appli cations can be easily ported. box. Packets destined for hosts behind the box are said to We illustrate DOA with two examples: first be inbound. The difference between nat and NAPt network -extension boxes which are analogous to that NATs do not look at fields beyond the IP he realms but do not obscure hosts,' identities, and second. as"NAT", though our description focuses on NAPT(the network filtering boxes"which are analogous to today's more common of the two today ) for simplicity, we as- firewalls but do not violate network-level layering and sume that NAPTs have only one external IP address need not be topologically in front of the hosts they ser- People deploy NATs for two reasons vice. Our goal is to show how our architecture easily ac-. Convenience and Flexibility: Private addressing commodates these boxes realms allow people to administer a set of hosts with Scope and limitations Security: Since hosts behind the nat do not have DOA is based on a subset of the architecture in a pre global identities, a host outside the private realm can- vious paper [3]. That position paper touches not address the hosts in the private realm or express ous issues-including mobility, multi-homing, networ hat traffic should go to them, which protects them level middleboxes, and application-level middleboxes- from unwanted traffic. Also, by default (i.e, without with scant ion to design details or implementations lual configuration), a NAT allows only inbound In an attempt to bring some of those nebulous architec tural mutterings into focus, this paper concentrates ex sively on network-level intermediaries and ignores m时计

performance through, for example, caching and load￾balancing. Commercial service providers will continue to take advantage of such performance-enhancing inter￾mediaries, disregarding architectural purity. Thus, we have a fundamental conflict: although in￾termediaries offer clear advantages, they run afoul of the two tenets above, which causes harm and makes de￾ploying and using intermediaries unnecessarily hard. Our goal, therefore, is an architecture hospitable to intermedi￾aries, specifically one that allows intermediaries to abide by the two tenets, to avoid other architectural infractions, and to retain the same functions as today. Such an archi￾tecture would let a variety of middleboxes be deployed while also letting end-system protocols evolve indepen￾dently and quickly. Our architecture—which we call the Delegation￾Oriented Architecture (DOA)—is based on two main ideas. First, all entities have a globally unique identi- fier in a flat namespace, and packets carry these identi- fiers. Second, DOA allows senders and receivers to ex￾press 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 ser￾vice. Globally unique identifiers and delegation have ex￾isted in previous work describing different architectures (e.g., i3 [57]); see §9 for details. This paper’s contribu￾tion is defining a relatively incremental extension to the Internet architecture, DOA, that coherently accommo￾dates network-level intermediaries like NATs and fire￾walls. 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 appli￾cations can be easily ported. We illustrate DOA with two examples: first, “network-extension boxes” which are analogous to to￾day’s NATs in their establishment of private addressing realms but do not obscure hosts’ identities, and second, “network filtering boxes” which are analogous to today’s firewalls but do not violate network-level layering and need not be topologically in front of the hosts they ser￾vice. Our goal is to show how our architecture easily ac￾commodates these boxes. Scope and Limitations DOA is based on a subset of the architecture in a pre￾vious paper [3]. That position paper touches on vari￾ous issues—including mobility, multi-homing, network￾level middleboxes, and application-level middleboxes— with scant attention to design details or implementations. In an attempt to bring some of those nebulous architec￾tural mutteringsinto focus, this paper concentrates exclu￾sively on network-level intermediaries and ignores their application-level counterparts.2 This paper does not dis￾cuss mobility and multi-homing scenarios either (though DOA, because it separates location and identity, could— with modest extensions—handle those scenarios). Given our limited focus, DOA should be viewed not as a com￾prehensive architecture but rather as an architectural component designed to address network-layer middle￾boxes. Its design presumes IPv4 at the network layer but DOA is also compatible with, and useful for, IPv6. The final limitation we mention is that some peo￾ple want to deploy tenet-violating middleboxes (e.g., a censorious government that silently filters packets en￾tering and exiting national borders) and that DOA can neither prevent such architecturally suspect middleboxes nor mitigate their damage. 2 Background This review of common network-layer middleboxes is limited to the two we build under DOA—NATs and firewalls—and to a subset of their drawbacks; for a com￾plete review, see [8, 18, 23, 38, 55]. Although NAT and firewalling are often combined in one box, these two functions are logically separate. 2.1 NAT and NAPT Network Address Translation (NAT) and Network Ad￾dress Port Translation (NAPT) [54] have several uses. For the purposes of this paper, we assume the follow￾ing common scenario: a NAT or NAPT box bridges two address realms, at least one of which is private. Private addresses are unique within an address realm but am￾biguous between address realms [46]; public addresses are globally unique and reachable from all Internet hosts. The hosts in the private realm are said to be behind the box. Packets destined for hosts behind the box are said to be inbound. The difference between NAT and NAPT is that NATs do not look at fields beyond the IP header. We adopt the convention of referring to both NAT and NAPT as “NAT”, though our description focuses on NAPT (the more common of the two today); for simplicity, we as￾sume that NAPTs have only one external IP address. People deploy NATs for two reasons: • Convenience and Flexibility: Private addressing realms allow people to administer a set of hosts with￾out having to obtain public IP addresses for each. • Security: Since hosts behind the NAT do not have global identities, a host outside the private realm can￾not address the hosts in the private realm or express that traffic should go to them, which protects them from unwanted traffic. Also, by default (i.e., without manual configuration), a NAT allows only inbound 2The basic architectural ideas can be illustrated with network-level intermediaries. At the application level, one must consider how appli￾cations are structured and named, a topic outside this paper’s scope [3]

traffic that is part of a connection initiated by a host 3 Architectural Overview of doa ehind the nat This section gives an overview of DOA; we defer design The main operations performed by a NAT are: 1)dy- details to 84. We first list desired architectural proper- namically allocating a source port at its public IP address ties that aid in gracefully accommodating intermediaries when a host behind it initiates a TCP connection or sends and then describe mechanisms to achieve those proper- a UDP packet; and (2)rewriting IP address and transport- ties. The remainder of the section discusses how DOA layer port fields to demultiplex inbound packets to the extends the Internet architectur hosts behind the naT and to multiplex outbound pack- 3.1 Desired Architectural Properties ets over the same source IP address. NATs violate both tenets in S1. First, a NATed host's conception of its iden- ()Global identifiers in packets: Each packet should tity (namely its IP address) is a private address and thus contain an identifier that unambiguously specifies is not a handle that it can pass around to allow other net the ultimate destination. The Internet architecture. as work entities to reach it. Second NaTs,modification of originally conceived, did provide global identifiers in port fields violates tenet #2. packets, but IPv4 addresses no longer meet the"global NATs cause the following additional problems identifier"requirement. (IPv6 addresses, because they reflect network topology, are also unsuitable for us, as In order for a server behind a nat to receive un- we elaborate below. )The purpose of a global identifier is solicited inbound packets sent to a given destination to uniquely identify the packet's ultimate destination to port, one must statically configure the NAT with in intermediaries in a way that is apI plication-independent. structions about packets with that destination port. his manual step is called hole punching and requires (2) Delegation as a primitive: Hosts should have administrative control over the NAT. The amount of an application-independent way to express to others that manual configuration increases when a series of nAts to reach the host, packets should be sent to an interme separate a server from the public Internet, creating diary or series of intermediaries. This primitive-called a tree of private address spacesin this case, one delegation-allows end-hosts or their administrators must not only configure each of the NATs in the tree to explicitly invoke(and revoke)intermediaries. These but also coordinate among them; e.g., each globally intermediaries need not be"on the topological path reachable Web server in a given tree of NATs must get 3.2 Mechanisms traffic on a different port on the outermost NAT's pub- EIDs: To achieve property (1), each host has an unam- lic IP address.(By outermost, we mean"connected to biguous endpoint identifier picked from a large names- the globally reachable Internet".) pace. Our design imposes the following additional re- Hosts behind the same NAT cannot simultaneously quirements receive traffic sent to the same TCP port number on the NAt's public IP address. However, some applica (a)The identifier is independent of network topology tions require traffic on a specific port; e. g, IPSECex (ruling out IPv6 addresses and other identifiers with pects traffic on port 500 [44], so only one host within topology-dependent components, as in [42, 43)). a tree of nats can receive virtual private Network With this requirement, hosts can change locations (VPN21] service. while keeping the same identifiers 2.2 Firewalls (b)The identifier can carry cryptographic meaning(rul- ing out human-friendly DNS names). We explain A firewall blocks certain traffic classes on behalf of a host the purpose of this requirement later in this section by examining IP-,transport-,and sometimes application- To satisfy these requirements, we choose flat 160-bit level fields and then applying a set of"firewall rules". It endpoint identifiers(EIDs). A DOA header between must be on the topological path between the host and the the IP and TCP headers carries source and destination host's Internet provider, which we argue is unnecessarily unnecessany EIDs. Transport connections are bound to source and restrictive. Today's firewalls disobey tenet #2 because, destination EIDs (instead of to source and destination by design, they must inspect many non-lP fields in each IP addresses as in the status quo ). DOA borrow even if the intended recipient wants to allow the traffic. including Nimrod [34], HIP [39 UIP(7 eviour s the packet. Since firewalls by default distrust that which they idea of topology-independent EIDs from pre do not recognize, they may block novel but benign traffic, EIDs are resolved tion as a primitive by resolving EIDs. We presume a 3Such series of NAts are not artificial; see 85.4 and Figure 4 mapping service, accessible to Internet hosts, that maps

traffic that is part of a connection initiated by a host behind the NAT. The main operations performed by a NAT are: (1) dy￾namically allocating a source port at its public IP address when a host behind it initiates a TCP connection or sends a UDP packet; and (2) rewriting IP address and transport￾layer port fields to demultiplex inbound packets to the hosts behind the NAT and to multiplex outbound pack￾ets over the same source IP address. NATs violate both tenets in §1. First, a NATed host’s conception of its iden￾tity (namely its IP address) is a private address and thus is not a handle that it can pass around to allow other net￾work entities to reach it. Second, NATs’ modification of port fields violates tenet #2. NATs cause the following additional problems: • In order for a server behind a NAT to receive un￾solicited inbound packets sent to a given destination port, one must statically configure the NAT with in￾structions about packets with that destination port. This manual step is called hole punching and requires administrative control over the NAT. The amount of manual configuration increases when a series of NATs separate a server from the public Internet, creating a tree of private address spaces3—in this case, one must not only configure each of the NATs in the tree but also coordinate among them; e.g., each globally reachable Web server in a given tree of NATs must get traffic on a different port on the outermost NAT’s pub￾lic IP address. (By outermost, we mean “connected to the globally reachable Internet”.) • Hosts behind the same NAT cannot simultaneously receive traffic sent to the same TCP port number on the NAT’s public IP address. However, some applica￾tions require traffic on a specific port; e.g., IPSEC ex￾pects traffic on port 500 [44], so only one host within a tree of NATs can receive Virtual Private Network (VPN) [21] service. 2.2 Firewalls A firewall blocks certain traffic classes on behalf of a host by examining IP-, transport-, and sometimes application￾level fields and then applying a set of “firewall rules”. It must be on the topological path between the host and the host’s Internet provider, which we argue is unnecessarily restrictive. Today’s firewalls disobey tenet #2 because, by design, they must inspect many non-IP fields in each packet. Since firewalls by default distrust that which they do not recognize, they may block novel but benign traffic, even if the intended recipient wants to allow the traffic. 3Such series of NATs are not artificial; see §5.4 and Figure 4. 3 Architectural Overview of DOA This section gives an overview of DOA; we defer design details to §4. We first list desired architectural proper￾ties that aid in gracefully accommodating intermediaries and then describe mechanisms to achieve those proper￾ties. The remainder of the section discusses how DOA extends the Internet architecture. 3.1 Desired Architectural Properties (1) Global identifiers in packets: Each packet should contain an identifier that unambiguously specifies the ultimate destination. The Internet architecture, as originally conceived, did provide global identifiers in packets, but IPv4 addresses no longer meet the “global identifier” requirement. (IPv6 addresses, because they reflect network topology, are also unsuitable for us, as we elaborate below.) The purpose of a global identifier is to uniquely identify the packet’s ultimate destination to intermediaries in a way that is application-independent. (2) Delegation as a primitive: Hosts should have an application-independent way to express to others that, to reach the host, packets should be sent to an interme￾diary or series of intermediaries. This primitive—called delegation—allows end-hosts or their administrators to explicitly invoke (and revoke) intermediaries. These intermediaries need not be “on the topological path”. 3.2 Mechanisms EIDs: To achieve property (1), each host has an unam￾biguous endpoint identifier picked from a large names￾pace. Our design imposes the following additional re￾quirements: (a) The identifier is independent of network topology (ruling out IPv6 addresses and other identifiers with topology-dependent components, as in [42, 43]). With this requirement, hosts can change locations while keeping the same identifiers. (b) The identifier can carry cryptographic meaning (rul￾ing out human-friendly DNS names). We explain the purpose of this requirement later in this section. To satisfy these requirements, we choose flat 160-bit endpoint identifiers (EIDs). A DOA header between the IP and TCP headers carries source and destination EIDs. Transport connections are bound to source and destination EIDs (instead of to source and destination IP addresses as in the status quo). DOA borrows the idea of topology-independent EIDs from previous work, including Nimrod [34], HIP [39], UIP [17]. EIDs are resolved . . .: DOA provides for delega￾tion as a primitive by resolving EIDs. We presume a mapping service, accessible to Internet hosts, that maps

EIDs to some target specified by the EID owner. This and the packet's destination IP address is not resolution has two flavors: work element's, then the element may change to Ip addresses: In order to communicate with in the packet besides per-hop fields. (However, ge notiNg an end-host identified by an EID, a prospective peer may drop packets based on information in the IP header ses the mapping service to resolve the Eid to an IP which permits functions such as ingress and egress fil address. This indirection creates a way for a host to tering. )If, on the other hand, the packet's destination pecify that prospective peers should direct their pack- IP address matches the network element's, there are ets to a given delegate: the host has its EID resolve to two cases: (1) The destination EID in the DOA header the IP address of the delegate. matches the network element's EID (i.e, the packet has reached its destination); or(2)These ElDs do not match, to other EIDs: More generally, an EID can resolve which means the element is a delegate In the latter case, to another EID, allowing an end-host to map its ElD to network-level layering implies that the allowed packet a delegate's identity; if an end-host's EID had to map operations are up to the entities in the delegation rela- to the delegate's IP address(or any other topology dependent identifier), the end-host would have to up- N date the mapping whenever the delegate's location ering but allows violations of higher-level equivalent EIDs, each of which identifies an intermediary sp e.g., an explicitly addressed firewall that looks at appli- ified by the host. This sequence is carried in packets, cation payloads upholds the rules just given but flouts yielding a loose source route in identifier space. This application-level layering. In general, this paper claims option is reminiscent of 13s stacked identifiers. hat dOA improves on the status quo by restoring network-level layering but does not insist that intermedi- Thus, our design requires an EID resolution infrastruc- aries adhere to higher-level layering. Why not? Higher- ture. We wish the management of this infrastructure to level layers define how to organize host software, and one be as automated as possible, which is why we had re- can imagine splitting host software among boxes using quirement(b), above: automated management is easier exotic decompositions. Defining both higher-level layer- if the EIDs are vested with cryptographic meaning [36]. ing and an architecture that respects these higher layers The resolution infrastructure must scalably support a is a problem that requires care and one we have left to fu putO/getO interface over a large, sparse, and flat names- ture work. In the meantime we believe that hosts invok pace. Distributed hash tables(DHTs)[2, 14, 49, 62]give in e& intermediaries should decide how best to split func- exactly this capability, but any other technology that of- tions between them and their intermediaries fers this capability would also suffice. DNS'sresolve- We now discuss how the IP layering rules given your-own-namespace"economic model cannot be used above apply to specific intermediaries. Under DOA, here, but there are plausible scenarios for the economic NATs, which exist to bridge address realms, need not bscure host identity: as we describe in more detail in We have not yet mentioned sender-invoked interme- 85, DOA-based NATs may rewrite IP fields but will nei- diaries.Under DOA, senders invoke intermediaries by ther touch DOA fields that carry host identities nor over- putting into packets additional identifiers beyond the load transport-layer fields. Also, firewalls could be ex- identifiers that resulted from resolving the receiver's plicitly invoked, meaning that packets ending up at the EID. Sender-invoked intermediaries receive little atten- firewalls would be addressed to the firewall. While these tion in this paper but are part of DOAs design. new firewalls(which we cover in 6)could certainly have 3.3 DOA and the Two Tenets them to d classes just as today's firewalls do, they are not violat We elaborate on our earlier claim that doa allows in- ing network-level layering because packets are addressed termediaries to abide by the two tenets in sl. Because to them. One result of this explicit addressing is that the they are location-independent and drawn from a massive firewalls invocation is under users'(or their administra- namespace, EIDs can globally and unambiguously iden- tors,)control, so the user (or administrator)cor tify hosts, satisfying tenet #l. As a result, a network el- to have packets destined for it sent to another ement can reply to the source of a packet by sending one with better suited policies the location given by the resolution of the source EID y network-level layering(tenet #2), network 3. 4 DOA and Internet Evolvability elements need only follow normal IP layering rules, as follows. If an IP packet arrives at a network element The preceding point is more general than firewalls and is important for the Internets flexibility and evolvability In this case, transport connections are bound to the ultimate end. Today, there is only one easy way to deploy a middlebo point, which is identified by the last EID in the sequence. course under DOA. some

EIDs to some target specified by the EID owner. This resolution has two flavors: • . . . to IP addresses: In order to communicate with an end-host identified by an EID, a prospective peer uses the mapping service to resolve the EID to an IP address. This indirection creates a way for a host to specify that prospective peers should direct their pack￾ets to a given delegate: the host has its EID resolve to the IP address of the delegate. • . . . to other EIDs: More generally, an EID can resolve to another EID, allowing an end-host to map its EID to a delegate’s identity; if an end-host’s EID had to map to the delegate’s IP address (or any other topology￾dependent identifier), the end-host would have to up￾date the mapping whenever the delegate’s location changed. An EID can also resolve to a sequence of EIDs, each of which identifies an intermediary spec￾ified by the host. This sequence is carried in packets, yielding a loose source route in identifier space.4 This option is reminiscent of i3’s stacked identifiers. Thus, our design requires an EID resolution infrastruc￾ture. We wish the management of this infrastructure to be as automated as possible, which is why we had re￾quirement (b), above: automated management is easier if the EIDs are vested with cryptographic meaning [36]. The resolution infrastructure must scalably support a put()/get() interface over a large, sparse, and flat names￾pace. Distributed hash tables (DHTs) [2, 14, 49, 62] give exactly this capability, but any other technology that of￾fers this capability would also suffice. DNS’s “resolve￾your-own-namespace” economic model cannot be used here, but there are plausible scenarios for the economic viability of a DHT-based resolution infrastructure [61]. We have not yet mentioned sender-invoked interme￾diaries. Under DOA, senders invoke intermediaries by putting into packets additional identifiers beyond the identifiers that resulted from resolving the receiver’s EID. Sender-invoked intermediaries receive little atten￾tion in this paper but are part of DOA’s design. 3.3 DOA and the Two Tenets We elaborate on our earlier claim that DOA allows in￾termediaries to abide by the two tenets in §1. Because they are location-independent and drawn from a massive namespace, EIDs can globally and unambiguously iden￾tify hosts, satisfying tenet #1. As a result, a network el￾ement can reply to the source of a packet by sending to the location given by the resolution of the source EID. To obey network-level layering (tenet #2), network elements need only follow normal IP layering rules, as follows. If an IP packet arrives at a network element 4 In this case, transport connections are bound to the ultimate end￾point, which is identified by the last EID in the sequence. and the packet’s destination IP address is not the net￾work element’s, then the element may change nothing in the packet besides per-hop fields. (However, elements may drop packets based on information in the IP header, which permits functions such as ingress and egress fil￾tering.) If, on the other hand, the packet’s destination IP address matches the network element’s, there are two cases: (1) The destination EID in the DOA header matches the network element’s EID (i.e., the packet has reached its destination); or (2) These EIDs do not match, which means the element is a delegate. In the latter case, network-level layering implies that the allowed packet operations are up to the entities in the delegation rela￾tionship. Note that this last claim satisfies network-level lay￾ering but allows violations of higher-level equivalents, e.g., an explicitly addressed firewall that looks at appli￾cation payloads upholds the rules just given but flouts application-level layering. In general, this paper claims that DOA improves on the status quo by restoring network-level layering but does not insist that intermedi￾aries adhere to higher-level layering. Why not? Higher￾level layers define how to organize hostsoftware, and one can imagine splitting host software among boxes using exotic decompositions. Defining both higher-level layer￾ing and an architecture that respects these higher layers is a problem that requires care and one we have left to fu￾ture work. In the meantime, we believe that hosts invok￾ing intermediaries should decide how best to split func￾tions between them and their intermediaries. We now discuss how the IP layering rules given above apply to specific intermediaries. Under DOA, NATs, which exist to bridge address realms, need not obscure host identity: as we describe in more detail in §5, DOA-based NATs may rewrite IP fields but will nei￾ther touch DOA fields that carry host identities nor over￾load transport-layer fields. Also, firewalls could be ex￾plicitly invoked, meaning that packets ending up at the firewalls would be addressed to the firewall. While these new firewalls (which we cover in §6) could certainly have outmoded policies, causing them to drop novel traffic classes just as today’s firewalls do, they are not violat￾ing network-level layering because packets are addressed to them. One result of this explicit addressing is that the firewall’s invocation is under users’ (or their administra￾tors’) control, so the user (or administrator) could decide to have packets destined for it sent to another firewall, one with better suited policies. 3.4 DOA and Internet Evolvability The preceding point is more general than firewalls and is important for the Internet’s flexibility and evolvability. Today, there is only one easy way to deploy a middlebox: putting it “on the path”. Of course, under DOA, some

1516 User 4-bt4 16-bit total length DHT(internet) 160-bit source ElD Sockets Apl 160-bit destination ElD put(EID, erec) Figure 2: Example DOa header with no stacked identifiers. erec get (ElD) Kernel is best implemented on end-hosts and not"in the net work because intelligence in the network leads to inflex ibility and because end-hosts know best what functions hey need. At a high level, DOA upholds this vision: the P header doa header tcp header body explicit invocation of intermediaries means that intelli is not stuck in the network and that end-hosts c Figure 1: High-level view of doa design. invoke the intermediaries that best serve them boxes would have to be on the topological path to enforce 4 Detailed DOA Design physical security (e.g, for denial-of-service protection) 86.4 describes how DOA accommodates these on-path Given the preceding general description of DOA,we now boxes.However,DOA-with its flexible and application- present details of the design Figure I shows the DOA independent invocation primitive--also gives users or components and the interfaces between them their administrators the option to outsource functional- ity. Thus, under DOA, fewer intermediaries would need 4.1 Header format to be physically interposed, and users, no longer limited DOA packets are delivered over IP, with the IP protocol to the capabilities of the boxes in front of them, could field set to a well-known value. An example DOA header avail themselves of a menu of services igure 2; the header As a result, we believe that DOa could permit the rise length is measured in four-byte words, the protocol field of a competitive market in professionally managed inter- is the transport-level protocol(e.g, TCP, UDP)used by mediary services such as firewalls. Delegation and reso- the packet, and the length field gives the dOa packets lution are precisely what is necessary for such a market- total length(including the dOa header but not IPheader) the ability for users to select a provider and to switch in bytes. TCP and UDP pseudo-checksums include the providers Because users would have a choice, they could EIDs where IP addresses are used today(since transport seek the intermediary service that best suited their needs, logically occurs between two entities, each identified by and because these services would be professionally man- an EID). The DOa header is extensible(e.g, the re- aged, they could keep up with the rapid pace of applica- mote packet filter presented in g6 extends the basic DOA tion innovation. Thus we see DOa as contributing to the header) Internets ability to evolve. While we believe in its benefits. it is not clear that 4.2 Resolution and Invoking Intermediaries DOA is necessary for these new functions. In fact, we A DOA host wishing to send a packet to a recipient ob- conjecture that even for those applications and interme- tains the recipients EID e out-of-band(e.g, by resolving diaries that one can seemingly build only under DOA, the recipient,s DNS name to e). The sender then uses someone with enough imagination and fortitude could the EId resolution infrastructure-which is discussed achieve equivalent functionality under the status quo- in 83.2 and which we base on DHTs-to retrieve an but not without running afoul of a basic tenet of the In- erecord, depicted in Figure 3. An erecord's fields ternet architecture. We do suspect that the mechanisms of as follows: the EID field is the ElD being resol DOa will help new Internet functionality to evolve, but Target field is described in the next paragraph; the Hint ultimately we believe our contribution is not novel func- field is optional information whose use we illustrate in tion but rather novel architecture--making a class of net- 85; and the ttl field like DNS'S TtL, is a hint indicat work intermediary functions easier to build and reason ing how long entities should cache the erecord DOA presumes that EID owners (or administrators acting on A natural question is how DOA relates to the canoni- their behalf) maintain and possibly periodically refresh cal end-to-end argument [51], which is often interpreted the DHT's copy of their erecord. as a warning against intermediaries The central claim of he end-to-end argi is that application intelligence Some DHTs, like OpenDHT [29], store only soft state, requiring EID owners to do refreshes

Figure 1: High-level view of DOA design. boxes would have to be on the topological path to enforce physical security (e.g., for denial-of-service protection); §6.4 describes how DOA accommodates these on-path boxes. However, DOA—with its flexible and application￾independent invocation primitive—also gives users or their administrators the option to outsource functional￾ity. Thus, under DOA, fewer intermediaries would need to be physically interposed, and users, no longer limited to the capabilities of the boxes in front of them, could avail themselves of a menu of services. As a result, we believe that DOA could permit the rise of a competitive market in professionally managed inter￾mediary services such as firewalls. Delegation and reso￾lution are precisely what is necessary forsuch a market— the ability for users to select a provider and to switch providers. Because users would have a choice, they could seek the intermediary service that best suited their needs, and because these services would be professionally man￾aged, they could keep up with the rapid pace of applica￾tion innovation. Thus, we see DOA as contributing to the Internet’s ability to evolve. While we believe in its benefits, it is not clear that DOA is necessary for these new functions. In fact, we conjecture that even for those applications and interme￾diaries that one can seemingly build only under DOA, someone with enough imagination and fortitude could achieve equivalent functionality under the status quo— but not without running afoul of a basic tenet of the In￾ternet architecture. We do suspect that the mechanisms of DOA will help new Internet functionality to evolve, but ultimately we believe our contribution is not novel func￾tion but rather novel architecture—making a class of net￾work intermediary functions easier to build and reason about, and less likely to cause harm. A natural question is how DOA relates to the canoni￾cal end-to-end argument [51], which is often interpreted as a warning against intermediaries. The central claim of the end-to-end argument is that application intelligence 4−bit header length version 4−bit 8−bit protocol 16−bit total length 0 15 16 31 bytes 44 160−bit destination EID 160−bit source EID Figure 2: Example DOA header with no stacked identifiers. is best implemented on end-hosts and not “in the net￾work” because intelligence in the network leads to inflex￾ibility and because end-hosts know best what functions they need. At a high level, DOA upholds this vision: the explicit invocation of intermediaries means that intelli￾gence is not stuck in the network and that end-hosts can invoke the intermediaries that best serve them. 4 Detailed DOA Design Given the preceding general description of DOA, we now present details of the design. Figure 1 shows the DOA components and the interfaces between them. 4.1 Header Format DOA packets are delivered over IP, with the IP protocol field set to a well-known value. An example DOA header, with no extensions, is shown in Figure 2; the header length is measured in four-byte words, the protocol field is the transport-level protocol (e.g., TCP, UDP) used by the packet, and the length field gives the DOA packet’s total length (including the DOA header but not IP header) in bytes. TCP and UDP pseudo-checksums include the EIDs where IP addresses are used today (since transport logically occurs between two entities, each identified by an EID). The DOA header is extensible (e.g., the re￾mote packet filter presented in §6 extends the basic DOA header). 4.2 Resolution and Invoking Intermediaries A DOA host wishing to send a packet to a recipient ob￾tains the recipient’s EID e out-of-band (e.g., by resolving the recipient’s DNS name to e). The sender then uses the EID resolution infrastructure—which is discussed in §3.2 and which we base on DHTs—to retrieve an erecord, depicted in Figure 3. An erecord’s fields are as follows: the EID field is the EID being resolved; the Target field is described in the next paragraph; the Hint field is optional information whose use we illustrate in §5; and the TTL field, like DNS’s TTL, is a hint indicat￾ing how long entities should cache the erecord. DOA presumes that EID owners (or administrators acting on their behalf) maintain and possibly periodically refresh5 the DHT’s copy of their erecord. 5Some DHTs, like OpenDHT [29], store only soft state, requiring EID owners to do refreshes