6th ACM/TEEE International Conference on Mobile Computing and Networking(MobiCom 00) An End-to-End Approach to Host Mobility Alex C. Snoeren and Hari Balakrishnan MIT Laboratory for Computer Science Cambridge, MA 02139 [snoeren, hari]@lcs. mit. edu Abstract IP[27,29,whis ng system. This is the approach taken by Mobile deploys a home agent that intercepts packets des- We present the design and implementation of an end-to-end ar- tined for a host currently away from its home network, and delivers chitecture for Internet host mobility using dynamic updates to the it to the mobile host via a foreign agent in the foreign network. This approach does not require any changes to the fixed (correspondent) connections are retained using and efficient connection mi- hosts in the Internet, but does require changing the underlying IP gration, enabling established connections to seamlessly negotiate a substrate to effect this triangle routing, and an authentication proto- change in endpoint IP addresses without the need for a third party. col to ensure that connections are not hijacked by a malicious party Our architecture is secure--name updates are effected via the se- Mobile IP is a"pure"routing solution, a network-layer scheme that cure DNS update protocol, while TCP connection migration uses requires no changes to any higher layer of the Internet protocol novel set of Migrate optionsand provides a pure end-system alternative to routing-based approaches such as Mobile IP. There are many classes of mobile applications [16]: those where Mobile IP was designed under the principle that fixed Internet other hosts originate connections to a mobile host and can benefit hosts and applications were to remain unmodified and only the un- from both host location and handoff support (e.g, a mobile Web derlying IP substrate should change. Our architecture requires no server, mobile telephony ) those wl hanges to the unicast IP substrate, instead modifying transport pre all connections, which do not require host location services but can tocols and applications at the end hosts. We argue that this is not a benefit from handoff support(e. g, mail readers, Web browsers) hindrance to deployment; rather, in a significant number of cases, It and those where an application-level retry suffices if the network allows for an easier deployment path than Mobile IP, while simul- address changes unexpectedly during a short trans n, which taneously giving better pertormance. We compare and contrast the need neither to work well (e.g, DNS resolution). We believe that a strengths of end-to-end and network-layer mobility schemes, and argue that end-to-end schemes are better suited to many common good end-to-end architecture for host mobility will support all these modes, and empower applications to make the choice best suited to mobile applications. Our performance experiments show that hand- off times are governed by TCP migrate latencies, and are on the It is an end-to-end approach, no changes to the IP substrate are re- order of a round-trip time of the communicating peers 1 Introduction In our mobility architecture, the decision of whether to support transparent connectivity across network address changes(espe The proliferation of mobile computing devices and wireless net- cially useful for mobile servers)or not( not needed for short client working products over the past decade has made host and service server transactions)is left to the application. While Mobile IP-style mobility on the Internet an important problem. Delivering data to fully-transparent mobility support is general and sufficient for mo- a mobile host across a network address change without disrupting bile applications, this generality comes at significant cost, complex existing connections can be tackled by introducing a level of indi- ity, and performance degradation To locate mobile hosts as they change their network attachment This research was supported in part by dArPa(Grant No point, we take advantage of the widely-deployed Domain Name MDA972-99-1-0014), NTT Corporation, and IBM. Alex C Sno- System(DNS)[20] and its ability to support secure dynamic up eren is supported by a National Defense Science and Engineering dates [8,351. Because most Internet applications resolve hostnames Graduate(NDSEG) Fellowship to an IP address at the beginning of a transaction or connection, this approach is viable for initiating new sessions with mobile hosts Permission to make digital or hard copies of all or part of this work When a host changes its network attachment point(IP address),it ends a secure DNS update to one of the name servers in its home copies bear this notice and the full citation on the first pings for these hosts are uncacheable by other domains, so stale age. Copyrights for components of this work owned by others than bindings are eliminated requires prior specific permission and/or a fee The ability to support continuous communication during periods of MobiCom 2000 08/2000 Boston. MA mobility without modifying the Ip substrate is a more challenging problem. Because TCP is a connection-oriented reliable protoc C 2000 ACM
6th ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom ’00) An End-to-End Approach to Host Mobility Alex C. Snoeren and Hari Balakrishnan MIT Laboratory for Computer Science Cambridge, MA 02139 {snoeren, hari}@lcs.mit.edu Abstract We present the design and implementation of an end-to-end architecture for Internet host mobility using dynamic updates to the Domain Name System (DNS) to track host location. Existing TCP connections are retained using secure and efficient connection migration, enabling established connections to seamlessly negotiate a change in endpoint IP addresses without the need for a third party. Our architecture is secure—name updates are effected via the secure DNS update protocol, while TCP connection migration uses a novel set of Migrate options—and provides a pure end-system alternative to routing-based approaches such as Mobile IP. Mobile IP was designed under the principle that fixed Internet hosts and applications were to remain unmodified and only the underlying IP substrate should change. Our architecture requires no changes to the unicast IP substrate, instead modifying transport protocols and applications at the end hosts. We argue that this is not a hindrance to deployment; rather, in a significant number of cases, it allows for an easier deployment path than Mobile IP, while simultaneously giving better performance. We compare and contrast the strengths of end-to-end and network-layer mobility schemes, and argue that end-to-end schemes are better suited to many common mobile applications. Our performance experiments show that handoff times are governed by TCP migrate latencies, and are on the order of a round-trip time of the communicating peers. 1 Introduction The proliferation of mobile computing devices and wireless networking products over the past decade has made host and service mobility on the Internet an important problem. Delivering data to a mobile host across a network address change without disrupting existing connections can be tackled by introducing a level of indiThis research was supported in part by DARPA (Grant No. MDA972-99-1-0014), NTT Corporation, and IBM. Alex C. Snoeren is supported by a National Defense Science and Engineering Graduate (NDSEG) Fellowship. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MobiCom 2000 08/2000 Boston, MA c 2000 ACM rection in the routing system. This is the approach taken by Mobile IP [27, 29], which deploys a home agent that intercepts packets destined for a host currently away from its home network, and delivers it to the mobile host via a foreign agent in the foreign network. This approach does not require any changes to the fixed (correspondent) hosts in the Internet, but does require changing the underlying IP substrate to effect this triangle routing, and an authentication protocol to ensure that connections are not hijacked by a malicious party. Mobile IP is a “pure” routing solution, a network-layer scheme that requires no changes to any higher layer of the Internet protocol stack. There are many classes of mobile applications [16]: those where other hosts originate connections to a mobile host and can benefit from both host location and handoff support (e.g., a mobile Web server, mobile telephony); those where the mobile host originates all connections, which do not require host location services but can benefit from handoff support (e.g., mail readers, Web browsers); and those where an application-level retry suffices if the network address changes unexpectedly during a short transaction, which need neither to work well (e.g., DNS resolution). We believe that a good end-to-end architecture for host mobility will support all these modes, and empower applications to make the choice best suited to their needs. Our architecture is motivated by, and meets, this goal. It is an end-to-end approach; no changes to the IP substrate are required. In our mobility architecture, the decision of whether to support transparent connectivity across network address changes (especially useful for mobile servers) or not (not needed for short clientserver transactions) is left to the application. While Mobile IP-style, fully-transparent mobility support is general and sufficient for mobile applications, this generality comes at significant cost, complexity, and performance degradation. To locate mobile hosts as they change their network attachment point, we take advantage of the widely-deployed Domain Name System (DNS) [20] and its ability to support secure dynamic updates [8, 35]. Because most Internet applications resolve hostnames to an IP address at the beginning of a transaction or connection, this approach is viable for initiating new sessions with mobile hosts. When a host changes its network attachment point (IP address), it sends a secure DNS update to one of the name servers in its home domain updating its current location. The name-to-address mappings for these hosts are uncacheable by other domains, so stale bindings are eliminated. The ability to support continuous communication during periods of mobility without modifying the IP substrate is a more challenging problem. Because TCP is a connection-oriented reliable protocol
many TCP applications reasonably expect this service model in the The rest of this paper describes the technical details of our ap- The two communicating peers must securely negotiate a change in bility suppor l h 2. we survey related work in the area of mo- face of losses and transient link failures, route changes, or mobility. proach. In Secti describe our architecture in Section 3. and detail the underlying network-layer IP address and then seamlessly con- our new Migrate TCP option in Section 4. We discuss the security tinue communication. Furthermore, an approach that requires either ramifications of our approach in Section 5 and our implementation communicating peer to learn about the new network-layer address and performance results in Section 6. We address some deployment before a move occurs is untenable because network-layer moves issues in Section 7 and conclude in Section 8. may be quite sudden and unpredictable sign a new end-to-end TCP opti 2 Related work migration of an established TCP connection across an IP address The problem of Internet host hange. Using this option, a TCP peer can suspend an open con- many angles in the literature classified into two nection and reactivate it from another IP address, transparent to an categories. Some techniques the peer. In this protocol, security is achieved through the use of a a completely transparent fashion, hiding any changes in network structure from the end hosts. We term these techniques newwork connection identifier, or token, which may be secured by a share layer mobility. By contrast, many other approaches attempt to han- secret key negotiated through an Elliptic Curve Diffie-Hellman (ECDH) key exchange [36] during initial connection establishment dle relocation at a higher level in the end host It requires no third party to authenticate migration requests, thereby 2.1 Network-layer mobility allowing the end points to use whatever authentication mechanism they choose to establish a trust relationship. Although we only de Mobile IP(RFC 2002)[29] is the current IETF standard for sup- scribe details for TCP migration, we find that this idea is general porting mobility on the Internet. It provides transparent support for and can be implemented in a like manner for specific UDP-based host mobility by inserting a level of indirection into the routing ar- protocols such as the Real-time Transport Protocol (RTP)to achieve chitecture. By elevating the mobile host's home address from its seamless mobility for those protocols as well. unction as an interface identifier to an end-point identifier(eid One way of thinking of our work is in the context of the end-to-end Mobile IP ensures the delivery of packets destined to a mobile argument [32], which observes that functionality is often best im- hosts home address, independent of the hosts physical point of at- plemented in a higher layer at an end system, where it can be done tachment to the Internet, as reflected in its care-of address.Mobile ccording to the applications specific requirements. We show that it IP does this by creating a routing tunnel between a mobile hosts bility as an end- to-end home network and its care-of address network-layer support, while providing multiple mobility modes. In Such routing tunnels need to be implemented with care because this sense, this is akin to applications deciding between UDP and advertising explicit host routes into the wide-area routing tables de TCP as a transport protocol; many opt for UDP's simplicity and stroys routing scalability. Mobile IP uses a home agent physically timeliness over TCPs reliability. In the same fashion, applications attached to the mobile host's home network to intercept and tunnel should be able to select the mobility mode of their choice packets to the mobile host. Hence, packets undergo triangle rout The other significant advantage of handling mobility on an end-to- ing, which is often longer than the optimal unicast path end basis is that it enables higher layers like Tcp and Http to learn Further compounding the problem is the widespread deployment about mobility and adapt to it. For example, it is a good idea after a of ingress filters [9], ratified in February 2000 by the IETF as a network route change to restart TCP transmissions from slow start "Best Current Practice"to combat denial-of-service attacks. With window-halving [13] since the bottleneck might have change this mechanism, a router does not forward packets with a source adapt the transmitted content to reflect new network conditions. address foreign to the local network, which implies that a packet These optimizations can be made naturally if mobility is handled sent by a mobile host in a foreign network with its source address end-to-end, since no extra signalling is needed. Indeed, the large set to its home address will not be forwarded. The solution to this body of work in mobile-aware applications [15, 22, 25] can benefit is to use reverse tunneling, which tunnels packets originating at the mobile host first to the hosts home agent(using the hosts care-o address as a source address), and then from there on to the desti- TcP options (e.g, SacK[19), path Mtu discovery Http/l. 1, nation using the home address as the source address Thus, routing to widespread deployment than changes to the IP substrate. This Perkins and Johnson present a route optimization option for Mo- bile ip to avoid end-to-end approach may be successfully deployed cache the care-of address of mobile hosts allowing communication We have implemented this mobility architecture in Linux 2.2 and to proceed directly. It requires an authenticated message exchange have conducted several experiments with it. We are encouraged from the home agent to the correspondent host [26]. The resulting the ease with which seamless mobility can be achieved, the flexibi. but requires modifications to the end hosts'IP layer as well as the Mobile IP scheme achieves performance almost equivalent to ours, ity it provides, and the lack of performance degradation. Since our heme does not impose any triangle routing anomalies, end-to-end In fact, the draft allows on-path routers to cache the care-of latency for active connections is better than standard Mobile IP, and addresses instead of the end host, but this requires modifying yet imilar to Mobile IP with route optimization. another level of infrastructure
many TCP applications reasonably expect this service model in the face of losses and transient link failures, route changes, or mobility. The two communicating peers must securely negotiate a change in the underlying network-layer IP address and then seamlessly continue communication. Furthermore, an approach that requires either communicating peer to learn about the new network-layer address before a move occurs is untenable because network-layer moves may be quite sudden and unpredictable. We design a new end-to-end TCP option to support the secure migration of an established TCP connection across an IP address change. Using this option, a TCP peer can suspend an open connection and reactivate it from another IP address, transparent to an application that expects uninterrupted reliable communication with the peer. In this protocol, security is achieved through the use of a connection identifier, or token, which may be secured by a shared secret key negotiated through an Elliptic Curve Diffie-Hellman (ECDH) key exchange [36] during initial connection establishment. It requires no third party to authenticate migration requests, thereby allowing the end points to use whatever authentication mechanism they choose to establish a trust relationship. Although we only describe details for TCP migration, we find that this idea is general and can be implemented in a like manner for specific UDP-based protocols such as the Real-time Transport Protocol (RTP) to achieve seamless mobility for those protocols as well. One way of thinking of our work is in the context of the end-to-end argument [32], which observes that functionality is often best implemented in a higher layer at an end system, where it can be done according to the application’s specific requirements. We show that it is possible to implement mobility as an end-to-end service without network-layer support, while providing multiple mobility modes. In this sense, this is akin to applications deciding between UDP and TCP as a transport protocol; many opt for UDP’s simplicity and timeliness over TCP’s reliability. In the same fashion, applications should be able to select the mobility mode of their choice. The other significant advantage of handling mobility on an end-toend basis is that it enables higher layers like TCP and HTTP to learn about mobility and adapt to it. For example, it is a good idea after a network route change to restart TCP transmissions from slow start or a window-halving [13] since the bottleneck might have changed, or adapt the transmitted content to reflect new network conditions. These optimizations can be made naturally if mobility is handled end-to-end, since no extra signalling is needed. Indeed, the large body of work in mobile-aware applications [15, 22, 25] can benefit from our architecture. Experience with previous end-to-end enhancements such as various TCP options (e.g., SACK [19]), path MTU discovery, HTTP/1.1, etc., has shown that such techniques often meet with less resistance to widespread deployment than changes to the IP substrate. This supports our belief that, in addition to the flexibility it offers, an end-to-end approach may be successfully deployed. We have implemented this mobility architecture in Linux 2.2 and have conducted several experiments with it. We are encouraged by the ease with which seamless mobility can be achieved, the flexibility it provides, and the lack of performance degradation. Since our scheme does not impose any triangle routing anomalies, end-to-end latency for active connections is better than standard Mobile IP, and similar to Mobile IP with route optimization. The rest of this paper describes the technical details of our approach. In Section 2, we survey related work in the area of mobility support. We describe our architecture in Section 3, and detail our new Migrate TCP option in Section 4. We discuss the security ramifications of our approach in Section 5 and our implementation and performance results in Section 6. We address some deployment issues in Section 7 and conclude in Section 8. 2 Related work The problem of Internet host mobility has been approached from many angles in the literature, but they can be classified into two categories. Some techniques attempt to handle host relocation in a completely transparent fashion, hiding any changes in network structure from the end hosts. We term these techniques networklayer mobility. By contrast, many other approaches attempt to handle relocation at a higher level in the end host. 2.1 Network-layer mobility Mobile IP (RFC 2002) [29] is the current IETF standard for supporting mobility on the Internet. It provides transparent support for host mobility by inserting a level of indirection into the routing architecture. By elevating the mobile host’s home address from its function as an interface identifier to an end-point identifier (EID), Mobile IP ensures the delivery of packets destined to a mobile host’s home address, independent of the host’s physical point of attachment to the Internet, as reflected in its care-of address. Mobile IP does this by creating a routing tunnel between a mobile host’s home network and its care-of address. Such routing tunnels need to be implemented with care because advertising explicit host routes into the wide-area routing tables destroys routing scalability. Mobile IP uses a home agent physically attached to the mobile host’s home network to intercept and tunnel packets to the mobile host. Hence, packets undergo triangle routing, which is often longer than the optimal unicast path. Further compounding the problem is the widespread deployment of ingress filters [9], ratified in February 2000 by the IETF as a “Best Current Practice” to combat denial-of-service attacks. With this mechanism, a router does not forward packets with a source address foreign to the local network, which implies that a packet sent by a mobile host in a foreign network with its source address set to its home address will not be forwarded. The solution to this is to use reverse tunneling, which tunnels packets originating at the mobile host first to the host’s home agent (using the host’s care-of address as a source address), and then from there on to the destination using the home address as the source address. Thus, routing anomalies occur in both directions. Perkins and Johnson present a route optimization option for Mobile IP to avoid triangle routing [28]. Here, correspondent hosts cache the care-of address of mobile hosts, allowing communication to proceed directly. It requires an authenticated message exchange from the home agent to the correspondent host [26]. The resulting Mobile IP scheme achieves performance almost equivalent to ours, but requires modifications to the end hosts’ IP layer1 as well as the 1 In fact, the draft allows on-path routers to cache the care-of addresses instead of the end host, but this requires modifying yet another level of infrastructure
infrastructure. In contrast, our approach achieves seamless 3 An end-to-end architecture connection migration without a third-party home vides a mobile host the ability to pick a mobility sed on the In this section, we describe our end-system mobility architecture needs of its application There are three important components in this system: addressing, mobile host location, and connection migration. By giving the mo- IPv6 provides native support for multiple simultaneous host ad- bile host explicit control over its mobility mode, we remove the dresses, and Mobile IPv6 provides mobility support for IPv6 in need for an additional(third-party) home-agent to broker packet further control is managed by the communicating peers themsee routing. The DNS already provides a host location service, and for the specification of a care-of address, which explicitly separat the role of the eld(the hosts canonical IP address)and rout triggered by the mobile host when it changes network location location(the care-of address). Gupta and Reddy propose a similar redirection mechanism for IPv4 through the use of ICMP-like con We assume, like most mobility schemes, that mobile hosts do not trol messages which establish care-of bindings at the end hosts [10] change ip addresses more than a few times a minute. We believe this is a reasonable assumption for most common cases of mobil Mysore and Bharghavan propose an interesting approach to ity We emphasize that this does not preclude physical mobility at network-layer mobility [23], where each mobile host is issued a per- rapid velocities across a homogeneous link technology, since that manent Class D IP multicast address that can serve as a unique ElD. can be handled at the physical and link layers, e.g,via link-layer If multicast were widely deployed, this is a promising approach; be- bridging[12 cause a Class d eld has the benefit of being directly routable by the routing infrastructure, it removes the need for an explicit care-of The rest of this section discusses addressing in a foreign network address. However, this scheme requires a robust, scalable, and efi- and host location using the dns. Section 4 is devoted to a detailed cient multicast infrastructure for a large number of sparse groups description of TCP connection migration. 3. 1 Addressing 2.2 Higher-layer methods The key to the scalability of the Internet architecture is that the IP The home-agent-based approach has also been applied at the trans- address serves as a routing locator, reflecting the addressee's point port layer, as in MSOCKS [18], where connection redirection was of attachment in the network topology. This enables aggregation based on address prefixes and allows routing to scale well. Our mo- The general idea of using names as a level-of-indirection to handle bility architecture explicitly preserves this crucial property of Inter- net addressing. some years now, people have talked about using the dnS to effect Like Mobile IP, we separate the issues of obtaining an IP address the level-of-indirection needed to support host mobility, but to our in a foreign domain from locating and seamlessly communicating knowledge ours is the first specific and complete architecture that with mobile hosts. Any suitable mechanism for address allocation ses the dns to support Internet host mobility. Recently, Adjie- may be employed, such as manual assignment, the Dynamic Host Winoto et al. proposed the integration of name resolution and mes- Configuration Protocol (DHCP)[7, or an autoconfiguration proto- sage routing in an Intentional Naming System to implement a "late col 341 binding"option that tracks highly mobile services and nodes [i], While IP addresses fundamentally denote a point of attachment in and it seems possible to improve the performance of that scheme the Internet topology and say nothing about the identity of the host Ising our connection migration approach that may be connected to that attachment point, they have implic- Our approach differs fundamentally from EID/locator techniques itly become associated with other properties as well. For example, since it requires no additional level of global addressing or indi- they are often used to specify security and access policies as in the rection, but only a (normally pre-existing) DNS entry and a shared case of ingress filtering to alleviate denial-of-service attacks. Our connection key between the two end hosts. Furthermore, unlike pre- architecture works without violating this trust model and does not vious connection-ID draft proposals such as Huitema's ETCP [11] require any form of forward or reverse tunneling to maintain seam- for TCP connection re-addressing, it requires no modification to less connectivity. In a foreign network, a mobile host uses a locally Transmission Control Block(TCB) There is a large body of work relating to improving TCP perfo 3. 2 Locating a mobile host mance in wireless and mobile environments [5, 6]. While not the Once a mobile host obtains an IP address, there are two ways in focus of our work. our adherence to standard TCP semantics allows these schemes to continue to work well in our architecture. F which it can communicate with correspondent hosts. First, client, when it actively opens connections to the correspondent ho thermore, since end hosts are explicitly notified of mobility, signif- In this case, there is no special host location task to be performed cant performance enhancements can be achieved at the application in our architecture, using the dns as before works. However, if the mobile host were to move to another network attachment point during a connection, a new address would be obtained as described Special RST handling is required on some networks that may in the previous section, and the current connection would continue rapidly reassign IP addresses; Section 4.5 discusses this issue seamlessly via a secure negotiation with the communicating peer as
infrastructure. In contrast, our approach achieves secure, seamless connection migration without a third-party home agent. It also provides a mobile host the ability to pick a mobility mode based on the needs of its applications. IPv6 provides native support for multiple simultaneous host addresses, and Mobile IPv6 provides mobility support for IPv6 in much the same fashion as Mobile IP for IPv4. IPv6 extensions allow for the specification of a care-of address, which explicitly separates the role of the EID (the host’s canonical IP address) and routing location (the care-of address). Gupta and Reddy propose a similar redirection mechanism for IPv4 through the use of ICMP-like control messages which establish care-of bindings at the end hosts [10]. Mysore and Bharghavan propose an interesting approach to network-layer mobility [23], where each mobile host is issued a permanent Class D IP multicast address that can serve as a unique EID. If multicast were widely deployed, this is a promising approach; because a Class D EID has the benefit of being directly routable by the routing infrastructure, it removes the need for an explicit care-of address. However, this scheme requires a robust, scalable, and effi- cient multicast infrastructure for a large number of sparse groups. 2.2 Higher-layer methods The home-agent-based approach has also been applied at the transport layer, as in MSOCKS [18], where connection redirection was achieved using a split-connection proxy. The general idea of using names as a level-of-indirection to handle object and node mobility is part of computer systems folklore. For some years now, people have talked about using the DNS to effect the level-of-indirection needed to support host mobility, but to our knowledge ours is the first specific and complete architecture that uses the DNS to support Internet host mobility. Recently, AdjieWinoto et al. proposed the integration of name resolution and message routing in an Intentional Naming System to implement a “late binding” option that tracks highly mobile services and nodes [1], and it seems possible to improve the performance of that scheme using our connection migration approach. Our approach differs fundamentally from EID/locator techniques since it requires no additional level of global addressing or indirection, but only a (normally pre-existing) DNS entry and a shared connection key between the two end hosts. Furthermore, unlike previous connection-ID draft proposals such as Huitema’s ETCP [11] for TCP connection re-addressing, it requires no modification to the TCP header, packet format, or semantics.2 Instead, it uses an additional TCP option and the inserts an additional field into the Transmission Control Block (TCB). There is a large body of work relating to improving TCP performance in wireless and mobile environments [5, 6]. While not the focus of our work, our adherence to standard TCP semantics allows these schemes to continue to work well in our architecture. Furthermore, since end hosts are explicitly notified of mobility, significant performance enhancements can be achieved at the application level [25]. 2 Special RST handling is required on some networks that may rapidly reassign IP addresses; Section 4.5 discusses this issue. 3 An end-to-end architecture In this section, we describe our end-system mobility architecture. There are three important components in this system: addressing, mobile host location, and connection migration. By giving the mobile host explicit control over its mobility mode, we remove the need for an additional (third-party) home-agent to broker packet routing. The DNS already provides a host location service, and any further control is managed by the communicating peers themselves, triggered by the mobile host when it changes network location. We assume, like most mobility schemes, that mobile hosts do not change IP addresses more than a few times a minute. We believe this is a reasonable assumption for most common cases of mobility. We emphasize that this does not preclude physical mobility at rapid velocities across a homogeneous link technology, since that can be handled at the physical and link layers, e.g., via link-layer bridging [12]. The rest of this section discusses addressing in a foreign network and host location using the DNS. Section 4 is devoted to a detailed description of TCP connection migration. 3.1 Addressing The key to the scalability of the Internet architecture is that the IP address serves as a routing locator, reflecting the addressee’s point of attachment in the network topology. This enables aggregation based on address prefixes and allows routing to scale well. Our mobility architecture explicitly preserves this crucial property of Internet addressing. Like Mobile IP, we separate the issues of obtaining an IP address in a foreign domain from locating and seamlessly communicating with mobile hosts. Any suitable mechanism for address allocation may be employed, such as manual assignment, the Dynamic Host Configuration Protocol (DHCP) [7], or an autoconfiguration protocol [34]. While IP addresses fundamentally denote a point of attachment in the Internet topology and say nothing about the identity of the host that may be connected to that attachment point, they have implicitly become associated with other properties as well. For example, they are often used to specify security and access policies as in the case of ingress filtering to alleviate denial-of-service attacks. Our architecture works without violating this trust model and does not require any form of forward or reverse tunneling to maintain seamless connectivity. In a foreign network, a mobile host uses a locally obtained interface address valid in the foreign domain as its source address while communicating with other Internet hosts. 3.2 Locating a mobile host Once a mobile host obtains an IP address, there are two ways in which it can communicate with correspondent hosts. First, as a client, when it actively opens connections to the correspondent host. In this case, there is no special host location task to be performed in our architecture; using the DNS as before works. However, if the mobile host were to move to another network attachment point during a connection, a new address would be obtained as described in the previous section, and the current connection would continue seamlessly via a secure negotiation with the communicating peer as
described in Section 4. If a mobile host were always a client(not open a TCP connection to the mobile host s old address, and has no an uncommon case today ) then no updates need to be made to any automatic fail-over mechanisI third party such as a home agent or the dns In this case, the application must perform another DNS lookup to To support mobile servers and other applications where Internet find the new location of the mobile host. We note that the trend hosts actively originate communication with a mobile host, we use towards dynamic dns records has caused such application-level the dNs to provide a level of indirection between a host's current retries to find their way into applications already--for instance location and an invariant end-point identifier In Mobile IP, a hosts current FreeBSD telnet and rsh applications try alternate ad home address is the invariant, and all routing (in the absence of dresses if an initial connection fails to a host that has multiple dNs route optimization)occurs via the home agent that intercepts pack- A-records It seems to be only a minor addition to refresh DNS ets destined to this invariant Ours is not a network-layer solution bindings if connection establishment fails. and we can therefore avoid the indirection for every packet trans- mission. We take advantage of the fact that a hostname lookup 4 TCP connection migration ubiquitously done by most applications that originate communica- tion with a network host, and use the dNs name as the invariant. A TCP connection[31] is uniquely identified by a 4-tuple: (source We believe that this is a good architectural model: a DNS name address, source port, dest address, dest port). Packets addressed to dentifies a host and does not assume anything about the network a different address, even if successfully delivered to the TCP stack attachment point to which it may currently be attached, and the in- on the mobile host, must not be demultiplexed to a connection es- direction occurs only when the initial lookup is done via a control tablished from a different address. Similarly, packets from a new message(a DNS lookup). address are also not associated with connections established from a This implies that when the mobile host changes its attachment previous address. This is crucial to the proper operation of servers point, it must detect this and change the hostname-to-address ("A record")mapping in the DNS. Fortunately, both tasks are easy to We propose a new Migrate TCP option, included in SYN segments, accomplish, the former by using a user-level daemon as in mobile that identifies a syn packet as part of a previously established con- nection, rather than a request for a new connection. This Migrate able secure DNS update protocol [8, 35]. We note that some DHCP option contains a token that identifies a previously established con servers today issue a DNS update at client boot time when handing nection on the same destination (address, port) pair. The token is out a new address to a known client based on a static MAC-to-Dns negotiated during initial connection establishment through the use table. This augurs well for the incremental deployability of our ar- of a Migrate-Permitted option. After a successful token negotia- chitecture, since DNS update support is widely available tion, TCP connections may be uniquely identified by either their The dNS provides a mechanism by which name resolvers can cache traditional (source address, source port, dest address, dest port)4 name mappings for some period of time, specified in the time-to- tuple, or a new(source address, source port, token) triple on each live(TTL)field of the A-record. To avoid a stale mapping from be- host ing used from the name cache, we set the time-to-live(TTL)field A mobile host may restart a previously-established TCP connection for the A-record of the name of the mobile host to zero, which pre- from a new address by sending a special Migrate SYN packet that vents this from being cached Contrary to what some might expect, contains the token identifying the previous connection. The fixed this does not cause a significant scaling problem; name lookups for host will than re-synchronize the connection with the mobile host at an uncached A-record do not have to start from a root name server the new end point. A migrated connection maintains the same con because in general the "NS-record'"(name server record) of the m trol block and state(with a different end point, of course), including bile host's DNS name is cacheable for a long period of time(many the sequence number space, so any necessary retransmissions can hours by default). This causes the name lookup to start at the name be requested in the standard fashion. This also ensures that SACK server of the mobile host,s domain, which scales well because of and any similar options continue to operate properly. Furthermore, administrative delegation of the namespace and DNS server replica- any options negotiated on the initial SYN exchange remain in ef- on in any domain. We note that some content distribution networks fect after connection migration, and need not be resent in a Migrate for Web server replication of popular sites use the same approach of small-to-zero TtL values to redirect client requests to appropri Since SYN segments consume a byte in the TCP sequence number ate servers(e.g, Akamai [2]). There is no central hot spot because pace, Migrate S YNs are issued with the same sequence number as the name server records for a domain are themselves cacheable for the last transmitted byte of data. This results in two bytes of data relatively long periods of time in a migrated TCP connection with the same sequence number( the Even with uncacheable dNS entries there still exists a possible race ew SYN and the previously-transmitted actual data), but this is not condition where a mobile host moves between when a correspon a problem since the Migrate SYN segment need never be explicitly lent host receives the result of its dnS query and when it initiates a acknowledged. Any TCP connection. Assuming a mobile host updates its DNS entry im- grating host at the mobile host's new address that has a sequence mediately upon reconnection, the chances of such an occurrence are number in the appropriate window for the current connection im- quite small, but non-zero, especially for a mobile host that makes plicitly acknowledges the Migrate SYN. Similarly, any further frequent moves. In this case, the correspondent host will attempt to They can be, if needed. For example, it might be useful to rene MOdern versions of BIND honor this correctly gotiate a new maximum segment size(MSS)reflecting the proper- ties of the new path. We have not yet explored this in detail
described in Section 4. If a mobile host were always a client (not an uncommon case today), then no updates need to be made to any third party such as a home agent or the DNS. To support mobile servers and other applications where Internet hosts actively originate communication with a mobile host, we use the DNS to provide a level of indirection between a host’s current location and an invariant end-point identifier. In Mobile IP, a host’s home address is the invariant, and all routing (in the absence of route optimization) occurs via the home agent that intercepts packets destined to this invariant. Ours is not a network-layer solution and we can therefore avoid the indirection for every packet transmission. We take advantage of the fact that a hostname lookup is ubiquitously done by most applications that originate communication with a network host, and use the DNS name as the invariant. We believe that this is a good architectural model: a DNS name identifies a host and does not assume anything about the network attachment point to which it may currently be attached, and the indirection occurs only when the initial lookup is done via a control message (a DNS lookup). This implies that when the mobile host changes its attachment point, it must detect this and change the hostname-to-address (“Arecord”) mapping in the DNS. Fortunately, both tasks are easy to accomplish, the former by using a user-level daemon as in Mobile IP, and the latter by using the well-understood and widely available secure DNS update protocol [8, 35]. We note that some DHCP servers today issue a DNS update at client boot time when handing out a new address to a known client based on a static MAC-to-DNS table. This augurs well for the incremental deployability of our architecture, since DNS update support is widely available. The DNS provides a mechanism by which name resolvers can cache name mappings for some period of time, specified in the time-tolive (TTL) field of the A-record. To avoid a stale mapping from being used from the name cache, we set the time-to-live (TTL) field for the A-record of the name of the mobile host to zero, which prevents this from being cached.3 Contrary to what some might expect, this does not cause a significant scaling problem; name lookups for an uncached A-record do not have to start from a root name server, because in general the “NS-record” (name server record) of the mobile host’s DNS name is cacheable for a long period of time (many hours by default). This causes the name lookup to start at the name server of the mobile host’s domain, which scales well because of administrative delegation of the namespace and DNS server replication in any domain. We note that some content distribution networks for Web server replication of popular sites use the same approach of small-to-zero TTL values to redirect client requests to appropriate servers (e.g., Akamai [2]). There is no central hot spot because the name server records for a domain are themselves cacheable for relatively long periods of time. Even with uncacheable DNS entries there still exists a possible race condition where a mobile host moves between when a correspondent host receives the result of its DNS query and when it initiates a TCP connection. Assuming a mobile host updates its DNS entry immediately upon reconnection, the chances of such an occurrence are quite small, but non-zero, especially for a mobile host that makes frequent moves. In this case, the correspondent host will attempt to 3 Modern versions of BIND honor this correctly. open a TCP connection to the mobile host’s old address, and has no automatic fail-over mechanism. In this case, the application must perform another DNS lookup to find the new location of the mobile host. We note that the trend towards dynamic DNS records has caused such application-level retries to find their way into applications already—for instance, current FreeBSD telnet and rsh applications try alternate addresses if an initial connection fails to a host that has multiple DNS A-records. It seems to be only a minor addition to refresh DNS bindings if connection establishment fails. 4 TCP connection migration A TCP connection [31] is uniquely identified by a 4-tuple: source address, source port, dest address, dest port. Packets addressed to a different address, even if successfully delivered to the TCP stack on the mobile host, must not be demultiplexed to a connection established from a different address. Similarly, packets from a new address are also not associated with connections established from a previous address. This is crucial to the proper operation of servers on well-known ports. We propose a new Migrate TCP option, included in SYN segments, that identifies a SYN packet as part of a previously established connection, rather than a request for a new connection. This Migrate option contains a token that identifies a previously established connection on the same destination address, port pair. The token is negotiated during initial connection establishment through the use of a Migrate-Permitted option. After a successful token negotiation, TCP connections may be uniquely identified by either their traditional source address, source port, dest address, dest port 4- tuple, or a new source address, source port, token triple on each host. A mobile host may restart a previously-established TCP connection from a new address by sending a special Migrate SYN packet that contains the token identifying the previous connection. The fixed host will than re-synchronize the connection with the mobile host at the new end point. A migrated connection maintains the same control block and state (with a different end point, of course), including the sequence number space, so any necessary retransmissions can be requested in the standard fashion. This also ensures that SACK and any similar options continue to operate properly. Furthermore, any options negotiated on the initial SYN exchange remain in effect after connection migration, and need not be resent in a Migrate SYN.4 Since SYN segments consume a byte in the TCP sequence number space, Migrate SYNs are issued with the same sequence number as the last transmitted byte of data. This results in two bytes of data in a migrated TCP connection with the same sequence number (the new SYN and the previously-transmitted actual data), but this is not a problem since the Migrate SYN segment need never be explicitly acknowledged. Any packet received from the fixed host by a migrating host at the mobile host’s new address that has a sequence number in the appropriate window for the current connection implicitly acknowledges the Migrate SYN. Similarly, any further seg- 4 They can be, if needed. For example, it might be useful to renegotiate a new maximum segment size (MSS) reflecting the properties of the new path. We have not yet explored this in detail.
noDule fixed Upon receipt of this SYN/ACK, the mobile host similarly ACKs the previous sequence space, and the connection resumes as before All of the options negotiated on the initial SYN except the Migrate Permitted option are still in effect, and need not be replicated in this 083521:083521(0 ny subsequent migration k53 4.2 Securing the migration It is possible to partially hijack TCP connections if an attacker can guess the sequence space being used by the connection [21] With the Migrate options, an attacker who can guess both the se- quence space and the connection token can hijack the connection completely. Furthermore, the ability to generate a Migrate SYN sYN545967:545967(0) from anywhere greatly increases the connections exposure. While ingress filtering can be used to prevent connection hijacking by at- tackers not on the path between the end hosts, such methods are ineffective in our case. We must therefore take care to secure the 7 ack092398 The problem is relatively easy to solve if IP security (IPsec)[4 were deployed. While the spectrum of approaches that could be used is outside the scope of this paper, we note that IPsec pro- Figure 1: TCP Connection Migration Currently, however, IPsec has not found wide-spread deployment. Hence, we provide a mechanism to self-secure the Migrate options. ments from the mobile host provide the fixed host an implicit ac- End hosts may elect to secretly negotiate an unguessable connec- knowledgement of its SYN/ACK. Thus, there is exactly one byte in tion token, which then reduces the security of a migrateable TCP the sequence space that needs explicit acknowledgement even when connection to that of a standard TCP connection, since no addi- the migrate syn is used tional attacks are possible against a migrateable connection without guessing the token, and any attack against a standard TCP connec- 4.1 An example tion clearly remains feasible against a migrateable TCP connection An unguessable connection token is secured with a secret conmee- Figure I shows a sample connection where a mobile client con- tion key. Since any host that obtains the connection key could fab- nects to a fixed host and later moves to a new address. The mobile ricate the token and issue a Migrate request, we select the key with client initiates the TCP connection in standard fashion in message an Elliptic Curve Diffie-Hellman key exchange [36], as described I, including a Migrate-Permitted option in the SYn packet. The below. Hosts using IPsec, or unconcerned with connection security, tation scribed in Section 4.3. The fixed server, with a migrate-compliant TCP stack, indicates its acceptance of the Migrate-Permitted option 4.3 Migrate-Permitted option ) The client completes the three-way handshake with message 3, Hosts wishing to initiate a migrateable TCP connection send a an ACK. The connection then proceeds as any other TCP connec- Migrate-Permitted option in the initial SYN segment Similar to tion would, until message 4, the last packet from the fixed host to the SACK-Permitted option [19] it should only be sent on SYN he mobile host at its current addres segments, and not during an established connection. Additionally, At some time later the mobile host moves to a new address. and hosts wishing to cryptographically secure the connection token may notifies the fixed server by sending a SYN packet from its new ad- conduct an Elliptic Curve Diffie-Hellman(ECDH) key exchange dress in message 5. This SYN includes the Migrate option, which through the option negotiation.(Elliptic Curve Diffie-Hellman he previously comp preferred to other methods of key establishment due to its high segment is the same as the last byte of transmitted data. The server cryptography can find the necessary background material in(3/c gration request. Note that the sequence number of this Migrate SYN security-to-bit-length ratio. Readers unfamiliar with Elliptic Curv responds in kind in message 6, also using the sequence number of As seen in figure 2, the Migrate-Permitted option comes in twe its last transmitted byte of data. The ACK, however, is from the variants-the insecure version, of length 3, and the secure versi ame sequence space as the previous connection. While in this ex- with length 20. The secure version is used to negotiate a secret con- ple it acknowledges the same sequence number as the syn that bit Curve Name and a 136-bit e generated it, it could be the case that segments were lost during Public Key fragment. The curve name field selects a particular set period of disconnect while the mobile host moves, and that the of domain parameters( the curve, underlying finite field, F, and its ACK will be a duplicate ACK for the last successfully received in- representation, the generating point, P, and the order of P, n), as sequence byte. Since it is addressed to the mobile host's new lo- specified in [3]. Use of the insecure version, which contains only a cation, however, it serves as an implicit ACK of the SYn as we Curve Name field(which must be set to zero)allows the end host
SYN 531521:531521(0) migrateOk km, timestamp Tm, ... SYN 083521:083521(0) ack 531522, migrateOk kf , timestamp Tf , ... ack 083522 091861:092397(536) ack 545968 SYN 545967:545967(0) migrate T ,R SYN 092397:092397(0) ack 545968 ack 092398 mobile fixed 1 2 3 4 5 6 7 Figure 1: TCP Connection Migration ments from the mobile host provide the fixed host an implicit acknowledgement of its SYN/ACK. Thus, there is exactly one byte in the sequence space that needs explicit acknowledgement even when the Migrate SYN is used. 4.1 An example Figure 1 shows a sample connection where a mobile client connects to a fixed host and later moves to a new address. The mobile client initiates the TCP connection in standard fashion in message 1, including a Migrate-Permitted option in the SYN packet. The values km and Tm are parameters used in the token negotiation, described in Section 4.3. The fixed server, with a migrate-compliant TCP stack, indicates its acceptance of the Migrate-Permitted option by including the Migrate-Permitted option in its response (message 2). The client completes the three-way handshake with message 3, an ACK. The connection then proceeds as any other TCP connection would, until message 4, the last packet from the fixed host to the mobile host at its current address. At some time later the mobile host moves to a new address, and notifies the fixed server by sending a SYN packet from its new address in message 5. This SYN includes the Migrate option, which contains the previously computed connection token as part of a migration request. Note that the sequence number of this Migrate SYN segment is the same as the last byte of transmitted data. The server responds in kind in message 6, also using the sequence number of its last transmitted byte of data. The ACK, however, is from the same sequence space as the previous connection. While in this example it acknowledges the same sequence number as the SYN that generated it, it could be the case that segments were lost during a period of disconnect while the mobile host moves, and that the ACK will be a duplicate ACK for the last successfully received insequence byte. Since it is addressed to the mobile host’s new location, however, it serves as an implicit ACK of the SYN as well. Upon receipt of this SYN/ACK, the mobile host similarly ACKs in the previous sequence space, and the connection resumes as before. All of the options negotiated on the initial SYN except the MigratePermitted option are still in effect, and need not be replicated in this or any subsequent migrations. 4.2 Securing the migration It is possible to partially hijack TCP connections if an attacker can guess the sequence space being used by the connection [21]. With the Migrate options, an attacker who can guess both the sequence space and the connection token can hijack the connection completely. Furthermore, the ability to generate a Migrate SYN from anywhere greatly increases the connection’s exposure. While ingress filtering can be used to prevent connection hijacking by attackers not on the path between the end hosts, such methods are ineffective in our case. We must therefore take care to secure the connection token. The problem is relatively easy to solve if IP security (IPsec) [4] were deployed. While the spectrum of approaches that could be used is outside the scope of this paper, we note that IPsec provides sufficient mechanisms to secure migrateable connections. Currently, however, IPsec has not found wide-spread deployment. Hence, we provide a mechanism to self-secure the Migrate options. End hosts may elect to secretly negotiate an unguessable connection token, which then reduces the security of a migrateable TCP connection to that of a standard TCP connection, since no additional attacks are possible against a migrateable connection without guessing the token, and any attack against a standard TCP connection clearly remains feasible against a migrateable TCP connection. An unguessable connection token is secured with a secret connection key. Since any host that obtains the connection key could fabricate the token and issue a Migrate request, we select the key with an Elliptic Curve Diffie-Hellman key exchange [36], as described below. Hosts using IPsec, or unconcerned with connection security, may choose to disable key negotiation to avoid excess computation. 4.3 Migrate-Permitted option Hosts wishing to initiate a migrateable TCP connection send a Migrate-Permitted option in the initial SYN segment. Similar to the SACK-Permitted option [19], it should only be sent on SYN segments, and not during an established connection. Additionally, hosts wishing to cryptographically secure the connection token may conduct an Elliptic Curve Diffie-Hellman (ECDH) key exchange through the option negotiation. (Elliptic Curve Diffie-Hellman is preferred to other methods of key establishment due to its high security-to-bit-length ratio. Readers unfamiliar with Elliptic Curve cryptography can find the necessary background material in [3].) As seen in figure 2, the Migrate-Permitted option comes in two variants—the insecure version, of length 3, and the secure version, with length 20. The secure version is used to negotiate a secret connection key, and contains an 8-bit Curve Name and a 136-bit ECDH Public Key fragment. The curve name field selects a particular set of domain parameters (the curve, underlying finite field, F, and its representation, the generating point, P, and the order of P, n), as specified in [3]. Use of the insecure version, which contains only a Curve Name field (which must be set to zero) allows the end host