EID:0x345ba4d 4.3 Security and Integrity Target: EID+ Or IP address Because identities(namely, EIDs)are separate from lo- TTL: tin cations(namely, IP addresses), the following require ment arises under DOA: The mapping from a given ElD Figure 3: The erecord to its target must be correct, i.e either resolving an EID, Recall from 83.2 that EIDs can either resolve to IP ad- or using an erecord directly sent by a host, must yield dresses(inducing what we call EID-to-IP mappings)or the lP address intended by the ElD owner or by the ElD to one or more EIDs(inducing EID-to-EID+ mappings). owner's delegates. Specifically, DOA must satisfy the If the Target field of the erecord contains only an IP following properties: address i, then, as described in 83. 2, the sender simply 1. Anyone fetching an erecord must be able to verify transmits a packet whose destination IP address is i and that the eld owner created it whose destination EID is e. In this case, the EID owner 2. Only the owner of an EID may update the correspond may or may not be directing potential senders to a del- ing erecord in the dht. egate, but the semantics are the same: the EID owner is saying"to reach me, send your packet there 3. When a host sends its erecord to another host with- If, on the other hand, the Target field of the erecord out using the dht, the sending host must not be able contains one or more ElDs, then the recipient is express to forge the erecord. ing its wish that the packet transit one or more interme- To uphold these properties, DOA uses se」 diaries before reaching the recipient. In this case, the se- certification [36]: EIDs must be the hash of a public key, mantics are"to reach me, send your packet to these in- and the erecord is signed with the corresponding pri termediaries in sequence". The sender would resolve the vate key. When a host either performs a getO operation first EID in the series to an IP address j(perhaps via in- on the dhT, resulting in an erecord, or else receives termediate resolutions to other series of ElDs, each of an erecord directly from a purported ElD owner, the which would be injected into the original series in the host must check that the erecord is signed with the logical order) and send the packet to j. This stack of EIDs private key whose corresponding public key was hashed is carried in the DOA header; transport connections are to create the EID in question. DHT nodes also perform bound to the last EID, which identifies the ultimate des- this check before accepting erecords. For more details, tination. (The design, but not our implementation, lets an including how ElD owners may update their public keys EID resolve to multiple IP addresses; the multiplicity re- without changing their ElDs, see [61]; we adopt the flects a multi-homed host or an anycast situation in which mechanisms described there a set of hosts are equivalent for the erecord owner's pur- With the above properties satisfied, erecords cannot poses. Similarly, each EID in the Target field could really be forged, but senders can still spoof source EIDs(i.e be a set of EIDs, again representing equivalent hosts. put the wrong source EID field in the packet). This at To send a packet back to the source, the receiver exe- tack is like spoofing a source IP address today(except cutes the steps just described to resolve the sender's EID, that ingress and egress filtering, which help guard against f. The receiver cannot simply use the source IP address IP address spoofing, are not applicable to ElDs): success in the original packet as the destination IP address in ful attacks do the same damage, and both attacks are de- the reply packet because f may resolve to a different IP tectable under two-way communication. For example, if address(e. g, f's host sends packets directly but wants a TCP client tries to spoof a source EID to a TCP server, packets to it sent through an intermediary) when the server looks up the source EID(or uses the c: To spare the server the burden of a DHT lookup, the signed erecord supplied by the client), the server gets ent can send its erecord as an optimization. ( The the correct(not fake)IP address for that EID, so when client may have to send more than one erecord since the server replies to the IP address, the host at that ad the clients EID may resolve to a chain of EIDs before dress will not complete the 3-way handshake being resolved to the IP address needed by the server. Security of the DHT itself is a topic outside the scope Also, DOA hosts use the erecords ttl to maintain a of this paper. We briefly observe that DHT nodes cannot TTL-based cache of eId-to-IP and EID-to-EID+ values. forge erecords but can return old versions of erecords. thus avoiding a DHT lookup for every packet A way to guard against this attack by consulting multiple he erech ord and accompanying machinery exist to DHT nodes, instead of one, is mentioned in [14] support receiver-invoked intermediaries Senders invoke Also, we note that while ip source routing cr additional intermediaries by pushing the EIDs of the in- security problems, DOA's loose source routes of ElDs termediaries onto an identifier stack in the doa header. do not inherit these difficulties. With IP source routing. receivers reverse the source route to reply to a sender, which allows an adversary to carry out a man-in-the-
EID: 0x345ba4d... Target: EID+ or IP address Hint: e.g., IP address TTL: time-to-live, a caching hint Figure 3: The erecord. Recall from §3.2 that EIDs can either resolve to IP addresses (inducing what we call EID-to-IP mappings) or to one or more EIDs (inducing EID-to-EID+ mappings). If the Target field of the erecord contains only an IP address i, then, as described in §3.2, the sender simply transmits a packet whose destination IP address is i and whose destination EID is e. In this case, the EID owner may or may not be directing potential senders to a delegate, but the semantics are the same: the EID owner is saying “to reach me, send your packet there”. If, on the other hand, the Target field of the erecord contains one or more EIDs, then the recipient is expressing its wish that the packet transit one or more intermediaries before reaching the recipient. In this case, the semantics are “to reach me, send your packet to these intermediaries in sequence”. The sender would resolve the first EID in the series to an IP address j (perhaps via intermediate resolutions to other series of EIDs, each of which would be injected into the original series in the logical order) and send the packet to j. This stack of EIDs is carried in the DOA header; transport connections are bound to the last EID, which identifies the ultimate destination. (The design, but not our implementation, lets an EID resolve to multiple IP addresses; the multiplicity re- flects a multi-homed host or an anycastsituation in which a set of hosts are equivalent for the erecord owner’s purposes. Similarly, each EID in the Target field could really be a set of EIDs, again representing equivalent hosts.) To send a packet back to the source, the receiver executes the steps just described to resolve the sender’s EID, f . The receiver cannot simply use the source IP address in the original packet as the destination IP address in the reply packet because f may resolve to a different IP address (e.g., f’s host sends packets directly but wants packets to it sent through an intermediary). To spare the server the burden of a DHT lookup, the client can send its erecord as an optimization. (The client may have to send more than one erecord since the client’s EID may resolve to a chain of EIDs before being resolved to the IP address needed by the server.) Also, DOA hosts use the erecord’s TTL to maintain a TTL-based cache of EID-to-IP and EID-to-EID+ values, thus avoiding a DHT lookup for every packet. The erecord and accompanying machinery exist to support receiver-invoked intermediaries. Senders invoke additional intermediaries by pushing the EIDs of the intermediaries onto an identifier stack in the DOA header. 4.3 Security and Integrity Because identities (namely, EIDs) are separate from locations (namely, IP addresses), the following requirement arises under DOA: The mapping from a given EID to its target must be correct, i.e., either resolving an EID, or using an erecord directly sent by a host, must yield the IP address intended by the EID owner or by the EID owner’s delegates. Specifically, DOA must satisfy the following properties: 1. Anyone fetching an erecord must be able to verify that the EID owner created it. 2. Only the owner of an EID may update the corresponding erecord in the DHT. 3. When a host sends its erecord to another host without using the DHT, the sending host must not be able to forge the erecord. To uphold these properties, DOA uses selfcertification [36]: EIDs must be the hash of a public key, and the erecord is signed with the corresponding private key. When a host either performs a get() operation on the DHT, resulting in an erecord, or else receives an erecord directly from a purported EID owner, the host must check that the erecord is signed with the private key whose corresponding public key was hashed to create the EID in question. DHT nodes also perform this check before accepting erecords. For more details, including how EID owners may update their public keys without changing their EIDs, see [61]; we adopt the mechanisms described there. With the above properties satisfied, erecords cannot be forged, but senders can still spoof source EIDs (i.e., put the wrong source EID field in the packet). This attack is like spoofing a source IP address today (except that ingress and egress filtering, which help guard against IP addressspoofing, are not applicable to EIDs): successful attacks do the same damage, and both attacks are detectable under two-way communication. For example, if a TCP client tries to spoof a source EID to a TCP server, when the server looks up the source EID (or uses the signed erecord supplied by the client), the server gets the correct (not fake) IP address for that EID, so when the server replies to the IP address, the host at that address will not complete the 3-way handshake. Security of the DHT itself is a topic outside the scope of this paper. We briefly observe that DHT nodes cannot forge erecords but can return old versions of erecords. A way to guard against this attack by consulting multiple DHT nodes, instead of one, is mentioned in [14]. Also, we note that while IP source routing creates security problems, DOA’s loose source routes of EIDs do not inherit these difficulties. With IP source routing, receivers reverse the source route to reply to a sender, which allows an adversary to carry out a man-in-the-
middle attack by placing its IP address in a forged source 5 Network Extension Boxes Under doa route. Under DOA, however, hosts do not reverse the This section and the next describe example intermedi- loose source route to reply to a sender aries under DOA. In the next section($6), our focus is on filtering packets and how to move this function"off- 4.4 Host software path". In this section, we show how the DOA framework We now describe the software interface that a production accommodates boxes that bridge between different IP ad- DOa deployment would expose Our prototype imple- dress spaces and also simplifies the use of these boxes mentation differs from this description; see 87.1 Under the status quo, these boxes are known as NATs DOA software would run in the kernel and be ex- but would be reincarnated under DOA as tenet-upholding posed to applications with the Berkeley sockets API[37, Network Extension Boxes(NEBs) hich can extend to EID-based identification Applica We first consider three usage scenarios for nebs tions would open a new socket type, PF- DOA(in anal-(35.1), then give our general approach, including a short ogy with PF-INET, used by today's IPv4-based appli- discussion of architectural coherence($5. 2), and then cations), and pass to the API a new data structure, the discuss the benefits of this approach($5.3). One of the sockaddr_eid, which holds an EID and port gust as benefits, automatically exposing hosts behind NEBs, is the sockaddr in-which todays IP-based applications particularly useful when NEBs are cascaded ($5.4). We use--holds an IP address and port). Some of the socket present several mechanisms for achieving automatic con- calls, such as connectO and sendtoo, might cause the figuration($5.5)and require that they work when there DOA software, depending on the state of its caches, are multiple levels of NEB. We conclude the section with to issue one or more DHT lookups to resolve the eId a discussion($5.6) into potentially intermediate EIDs and also an IP ad dress. One could port todays applications by substitut 5.1 Scope ing sockaddr_eid for sockaddr_ in in the code though The following NEB scenarios reflect reasons for deploy client applications would need additional logic to get a ing NATs today(g2. 1)and are ordered by the degree of server's EID, perhaps via a DNS lookup access control For example, client TCP applications would call (a)A host behind the NEB is accessible on all ports.The connectO, supplying a sockaddr eid that contained an EID and port, both of which the application had NEB creates a separate addressing realm but does not control access. Under this scenario. which cor- tained out of band. Similarly, TCP server applications responds to the"Convenience and Flexibility"reason would call accepto, getting back the EID and port of for deploying a NAT today($2.1), many hosts within the initiating client. To reply to the client, the server's an organization can be reachable as first-class mem- DOA Software would resolve the clients eld to an IP bers of the Internet, even if the organization has only address i and address reply packets to i at the IP layer one ip address For bootstrapping, DOA hosts would be configured with the EIDs and IP addresses of one or more of the (b)a host behind the NEB is accessible on configured DHT nodes, in analogy with how today's hosts learn the ports, and the NEB blocks unsolicited traffic to the IP address of a DNS resolver(via hardcoding or DHCP) host on the other ports. This scenario, which reflects On boot up the doa software would insert into the both reasons for deploying a NAT ($2. 1), is analo- DHT the hosts erecord(which could contain an ElD- gous to, e.g., today setting up a Web server behind to-EID or EID-to-IP mapping, depending on the hosts a NAT and configuring the Nat to send all packets configuration) and would refresh the mapping periodi with destination port 80 to the Web server cally or in response to host configuration changes (c) A host behind the NEB is accessible on no ports, i.e the host can only receive packets associated with con- 4.5 Limitations nections it has initiated. This scenario, which is prin- DOA hosts cache erecords, so hosts may have stale in- pally driven by the"Security"reason for deploying formation about prospective peers. Also, two DOA peers a NAT(S2.1), is the default under NAt today. in a TCP session resolve each other's EIDs only once- We expect that under DOA, scenario(b)a mix of ac at the start of the session-so hosts cannot change loca- cess control and exposure d be most common tions without breaking existing connections. DOA could However, for clarity, we focus on scenario(a)and return overcome this limitation if it were extended with a sig- to scenarios(b)and(c)at the end of the section($5.6) naling mechanism, as in [39, 53], that allows hosts to no- tify peers of IP address changes. Finally, an EID owI 5.2 Approach cannot change which intermediaries are invoked based NEBs preserve packets DOA headers and use the desti on who is trying to communicate with it. nation EID field as a demultiplexing token. For example
middle attack by placing its IP address in a forged source route. Under DOA, however, hosts do not reverse the loose source route to reply to a sender. 4.4 Host Software We now describe the software interface that a production DOA deployment would expose. Our prototype implementation differs from this description; see §7.1. DOA software would run in the kernel and be exposed to applications with the Berkeley sockets API [37], which can extend to EID-based identification. Applications would open a new socket type, PF DOA (in analogy with PF INET, used by today’s IPv4-based applications), and pass to the API a new data structure, the sockaddr eid, which holds an EID and port (just as the sockaddr in—which today’s IP-based applications use—holds an IP address and port). Some of the socket calls, such as connect() and sendto(), might cause the DOA software, depending on the state of its caches, to issue one or more DHT lookups to resolve the EID into potentially intermediate EIDs and also an IP address. One could port today’s applications by substituting sockaddr eid for sockaddr in in the code, though client applications would need additional logic to get a server’s EID, perhaps via a DNS lookup. For example, client TCP applications would call connect(), supplying a sockaddr eid that contained an EID and port, both of which the application had obtained out of band. Similarly, TCP server applications would call accept(), getting back the EID and port of the initiating client. To reply to the client, the server’s DOA software would resolve the client’s EID to an IP address i and address reply packets to i at the IP layer. For bootstrapping, DOA hosts would be configured with the EIDs and IP addresses of one or more of the DHT nodes, in analogy with how today’s hosts learn the IP address of a DNS resolver (via hardcoding or DHCP). On boot up, the DOA software would insert into the DHT the host’s erecord (which could contain an EIDto-EID+ or EID-to-IP mapping, depending on the host’s configuration) and would refresh the mapping periodically or in response to host configuration changes. 4.5 Limitations DOA hosts cache erecords, so hosts may have stale information about prospective peers. Also, two DOA peers in a TCP session resolve each other’s EIDs only once— at the start of the session—so hosts cannot change locations without breaking existing connections. DOA could overcome this limitation if it were extended with a signaling mechanism, as in [39,53], that allows hosts to notify peers of IP address changes. Finally, an EID owner cannot change which intermediaries are invoked based on who is trying to communicate with it. 5 Network Extension Boxes Under DOA This section and the next describe example intermediaries under DOA. In the next section (§6), our focus is on filtering packets and how to move this function “offpath”. In this section, we show how the DOA framework accommodates boxesthat bridge between different IP address spaces and also simplifies the use of these boxes. Under the status quo, these boxes are known as NATs but would be reincarnated under DOA as tenet-upholding Network Extension Boxes (NEBs). We first consider three usage scenarios for NEBs (§5.1), then give our general approach, including a short discussion of architectural coherence (§5.2), and then discuss the benefits of this approach (§5.3). One of the benefits, automatically exposing hosts behind NEBs, is particularly useful when NEBs are cascaded (§5.4). We present several mechanismsfor achieving automatic con- figuration (§5.5) and require that they work when there are multiple levels of NEB. We conclude the section with a discussion (§5.6). 5.1 Scope The following NEB scenarios reflect reasons for deploying NATs today (§2.1) and are ordered by the degree of access control: (a) A host behind the NEB is accessible on all ports. The NEB creates a separate addressing realm but does not control access. Under this scenario, which corresponds to the “Convenience and Flexibility” reason for deploying a NAT today (§2.1), many hosts within an organization can be reachable as first-class members of the Internet, even if the organization has only one IP address. (b) A host behind the NEB is accessible on configured ports, and the NEB blocks unsolicited traffic to the host on the other ports. This scenario, which reflects both reasons for deploying a NAT (§2.1), is analogous to, e.g., today setting up a Web server behind a NAT and configuring the NAT to send all packets with destination port 80 to the Web server. (c) A host behind the NEB is accessible on no ports, i.e., the host can only receive packets associated with connections it has initiated. This scenario, which is principally driven by the “Security” reason for deploying a NAT (§2.1), is the default under NAT today. We expect that under DOA, scenario (b)—a mix of access control and exposure—would be most common. However, for clarity, we focus on scenario (a) and return to scenarios (b) and (c) at the end of the section (§5.6). 5.2 Approach NEBs preserve packets’ DOA headers and use the destination EID field as a demultiplexing token. For example