《计算机网络》课程教学资源（参考文献）An End-to-End Approach to Host Mobility

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 ar￾chitecture 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 mi￾gration, 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 se￾cure 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 un￾derlying IP substrate should change. Our architecture requires no changes to the unicast IP substrate, instead modifying transport pro￾tocols 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 simul￾taneously 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 hand￾off 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 net￾working 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 indi￾This research was supported in part by DARPA (Grant No. MDA972-99-1-0014), NTT Corporation, and IBM. Alex C. Sno￾eren 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 advan￾tage, 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 des￾tined 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 proto￾col 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 re￾quired. In our mobility architecture, the decision of whether to support transparent connectivity across network address changes (espe￾cially useful for mobile servers) or not (not needed for short client￾server transactions) is left to the application. While Mobile IP-style, fully-transparent mobility support is general and sufficient for mo￾bile applications, this generality comes at significant cost, complex￾ity, 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 up￾dates [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 map￾pings 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 con￾tinue 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 con￾nection 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 de￾scribe 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 im￾plemented 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-to￾end 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 flexibil￾ity 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 ap￾proach. In Section 2, we survey related work in the area of mo￾bility 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 network￾layer mobility. By contrast, many other approaches attempt to han￾dle 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 sup￾porting mobility on the Internet. It provides transparent support for host mobility by inserting a level of indirection into the routing ar￾chitecture. 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 at￾tachment 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 de￾stroys 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 rout￾ing, 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 desti￾nation using the home address as the source address. Thus, routing anomalies occur in both directions. Perkins and Johnson present a route optimization option for Mo￾bile 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 pro￾vides 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 ad￾dresses, 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 con￾trol 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 per￾manent Class D IP multicast address that can serve as a unique EID. If multicast were widely deployed, this is a promising approach; be￾cause 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 trans￾port 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, Adjie￾Winoto et al. proposed the integration of name resolution and mes￾sage 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 indi￾rection, but only a (normally pre-existing) DNS entry and a shared connection key between the two end hosts. Furthermore, unlike pre￾vious 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 perfor￾mance 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. Fur￾thermore, since end hosts are explicitly notified of mobility, signif￾icant 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 mo￾bile 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 mobil￾ity. 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 mo￾bility architecture explicitly preserves this crucial property of Inter￾net 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 proto￾col [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 implic￾itly 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 seam￾less 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 pack￾ets destined to this invariant. Ours is not a network-layer solution and we can therefore avoid the indirection for every packet trans￾mission. We take advantage of the fact that a hostname lookup is ubiquitously done by most applications that originate communica￾tion 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 in￾direction 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 (“A￾record”) 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 avail￾able 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 ar￾chitecture, 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-to￾live (TTL) field of the A-record. To avoid a stale mapping from be￾ing 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 pre￾vents 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 mo￾bile 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 replica￾tion 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 appropri￾ate 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 correspon￾dent host receives the result of its DNS query and when it initiates a TCP connection. Assuming a mobile host updates its DNS entry im￾mediately 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 ad￾dresses 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 es￾tablished 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 con￾nection, rather than a request for a new connection. This Migrate option contains a token that identifies a previously established con￾nection 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 negotia￾tion, 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 con￾trol 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 ef￾fect 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 mi￾grating host at the mobile host’s new address that has a sequence number in the appropriate window for the current connection im￾plicitly acknowledges the Migrate SYN. Similarly, any further seg- 4 They can be, if needed. For example, it might be useful to rene￾gotiate a new maximum segment size (MSS) reflecting the proper￾ties 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 ac￾knowledgement 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 con￾nects 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, de￾scribed 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 connec￾tion 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 ad￾dress in message 5. This SYN includes the Migrate option, which contains the previously computed connection token as part of a mi￾gration 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 ex￾ample 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 in￾sequence byte. Since it is addressed to the mobile host’s new lo￾cation, 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 Migrate￾Permitted 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 se￾quence 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 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 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 pro￾vides 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 connec￾tion token, which then reduces the security of a migrateable TCP connection to that of a standard TCP connection, since no addi￾tional attacks are possible against a migrateable connection without guessing the token, and any attack against a standard TCP connec￾tion clearly remains feasible against a migrateable TCP connection. An unguessable connection token is secured with a secret connec￾tion key. Since any host that obtains the connection key could fab￾ricate 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 con￾nection 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

Kind: 15 Length=3/20 Curve Name ECDH PK Kind. ECDH Public Key(cont ECDH Public Key(cont) Token(cont ECDH Public Key(cont) ECDH Public Key(cont Request(cont Figure 2: TCP Migrate-Permitted option Figure 3: TCP Migrate option negotiation process. In that case, the connection key is used)in its SYN/ACk segment. It similarly selects a random Xi Ell, n-1 which it uses to construct kj, its public key, whi it sends in the same fashion use of the Timestamp [14]option in order to store up to 200 bits of After the initiating host's reception of the SYN/ACK with the ECDH keying material. The EDCH Public Key is encoded using the compressed conversion routine described in [ 3, Section 4.3.6 compute a shared secret key, K, as specified in[36] The 136 least-significant bits are stored in the edCh Public Key field of the Migrate-Permitted option, while the remaining 64 bits K=ki*x=k,*Xi of the key are encoded in the Timestamp option. The timestamp op- This secret key is then used to compute a connection validation to- ion, while often included, is not used on SYN segments. The Pre ken. This token, T, is computed by hashing together the key and tection Against Wrapped Sequence Numbers(PAwS)[14] check the initial equence numbers N and N using the Secure Hash Al- is only performed on synchronized connections, which by defini gorithm(SHA-1)[24 in the following fashion (recall that host i tion 31] includes only segments after the three-way handshake initiated the connection with an active open, and host j is perform- Similarly, the Round-Trip Time Measurement(RTTM)[14] pro- ing a passive open) cedure only functions when a timestamp has been echoed--clearly this is never the case on an initial SYN segment. Hence the value of T=SHAI(Ni, N, K) the Timestamp option on SYN segments is entirely irrelevant to cur- While SHA-1 produces a 160-bit hash, all but the 64 most Permitted option on a SYN/ACK, hence the Timestamp option will significant bits are discarded, resulting in a cryptographically be processed normally. Special handling is only required for the secure 64-bit token that is unique to the particular connection.Since SYN/ACK and following ACK segment on connections that have SHA-I is collision-resistant, the chance that another connection on negotiated the Migrate-Permitted option, as Timestamp fields on the same (address, port)pair has an identical token is extremely unlikely. If a collision is detected, however, the connection must be these segments will not contain timestamps. Hence the rTTM algo- aborted by sending a RST segment (The host performing a passive connections that have negotiated the Migrate-Permitted option. ope pen can check for collisions before issuing a SYN/ACK, and se- lect a new random Xi until a unique token is obtained. Hence the The Timestamp TSVal field contains the 32 most-significant bits of only chance of collision occurs on the host performing the active the public key, while the sEcr field contains the next 32 most- open.) significant bits. These two components, combined with the 136-bit EDCH Public Key field of the Migrate-Permitted option, constitute 4.4 Migrate option the hosts public key, k. If the public key is less than 200 bits, it is left-padded with zeros. For any host, i, ki is generated by selecting The Migrate option is used to request the migration of a currently random number, Xi E[1, n-1], where n is the order of P, and open TCP connection to a new address. It is sent in a SYN segment exists(in the ESTABlisHEd or FIN-WAIT states), over which the Migrate-Permitted option has been negotiated The operation is the scalar multiplication operation over the field There are two 64-bit fields in a Migrate option: a token, and a re- which must be monotonically increasing with each new migrate the control block for each new connection. Any necessary retrans- missions of the syn or synack must include identical values connection.(The sequence num- ber allows correspondent hosts to ensure Migrate SYNs were not for the Migrate-Permitted and Timestamp option. reordered by the network Sequence space wrap-around is dealt Upon receipt of an initial SYN with a Migrate-Permitted option, with in the standard fashion. The token is simply the 64 most a host, j, with a compliant TCP stack must include a Migrate- significant bits of the connections SHA-1 hash as computed in the Permitted option(and a Timestamp option if the secure variant Migrate-Permitted option exchange. The request, R, is similarly

Kind: 15 Length = 3/20 Curve Name ECDH PK ECDH Public Key (cont.) ECDH Public Key (cont.) ECDH Public Key (cont.) ECDH Public Key (cont.) Figure 2: TCP Migrate-Permitted option to skip the key negotiation process. In that case, the connection key is set to all zeros. The secure variant of the Migrate-Permitted option also requires the use of the Timestamp [14] option in order to store up to 200 bits of ECDH keying material. The EDCH Public Key is encoded using the compressed conversion routine described in [3, Section 4.3.6]. The 136 least-significant bits are stored in the EDCH Public Key field of the Migrate-Permitted option, while the remaining 64 bits of the key are encoded in the Timestamp option. The timestamp op￾tion, while often included, is not used on SYN segments. The Pro￾tection Against Wrapped Sequence Numbers (PAWS) [14] check is only performed on synchronized connections, which by defini￾tion [31] includes only segments after the three-way handshake. Similarly, the Round-Trip Time Measurement (RTTM) [14] pro￾cedure only functions when a timestamp has been echoed—clearly this is never the case on an initial SYN segment. Hence the value of the Timestamp option on SYN segments is entirely irrelevant to cur￾rent TCP stacks. Legacy TCP stacks will never receive a Migrate￾Permitted option on a SYN/ACK, hence the Timestamp option will be processed normally. Special handling is only required for the SYN/ACK and following ACK segment on connections that have negotiated the Migrate-Permitted option, as Timestamp fields on these segments will not contain timestamps. Hence the RTTM algo￾rithm must not be invoked for SYN/ACK or initial ACK segments of connections that have negotiated the Migrate-Permitted option. The Timestamp TSVal field contains the 32 most-significant bits of the public key, while the TSecr field contains the next 32 most￾significant bits. These two components, combined with the 136-bit EDCH Public Key field of the Migrate-Permitted option, constitute the host’s public key, k. If the public key is less than 200 bits, it is left-padded with zeros. For any host, i, ki is generated by selecting a random number, Xi ∈ [1, n − 1], where n is the order of P, and computing ki = Xi ∗ P The ∗ operation is the scalar multiplication operation over the field F. The security of the connection hinges on the secrecy of the ne￾gotiated key, hence Xi should be randomly generated and stored in the control block for each new connection. Any necessary retrans￾missions of the SYN or SYN/ACK must include identical values for the Migrate-Permitted and Timestamp option. Upon receipt of an initial SYN with a Migrate-Permitted option, a host, j, with a compliant TCP stack must include a Migrate￾Permitted option (and a Timestamp option if the secure variant Kind: 16 Length = 19 ReqNo Token Token (cont.) Request Request (cont.) Figure 3: TCP Migrate option is used) in its SYN/ACK segment. It similarly selects a random Xj ∈ [1, n − 1] which it uses to construct kj , its public key, which it sends in the same fashion. After the initiating host’s reception of the SYN/ACK with the Migrate-Permitted and Timestamp options, both hosts can then compute a shared secret key, K, as specified in [36]: K = ki ∗ Xj = kj ∗ Xi This secret key is then used to compute a connection validation to￾ken. This token, T, is computed by hashing together the key and the initial sequence numbers Ni and Nj using the Secure Hash Al￾gorithm (SHA-1) [24] in the following fashion (recall that host i initiated the connection with an active open, and host j is perform￾ing a passive open): T = SHA1(Ni, Nj , K) While SHA-1 produces a 160-bit hash, all but the 64 most￾significant bits are discarded, resulting in a cryptographically￾secure 64-bit token that is unique to the particular connection. Since SHA-1 is collision-resistant, the chance that another connection on the same
address, port pair has an identical token is extremely unlikely. If a collision is detected, however, the connection must be aborted by sending a RST segment. (The host performing a passive open can check for collisions before issuing a SYN/ACK, and se￾lect a new random Xj until a unique token is obtained. Hence the only chance of collision occurs on the host performing the active open.) 4.4 Migrate option The Migrate option is used to request the migration of a currently open TCP connection to a new address. It is sent in a SYN segment to a host with which a previously-established connection already exists (in the ESTABLISHED or FIN WAIT states), over which the Migrate-Permitted option has been negotiated. There are two 64-bit fields in a Migrate option: a token, and a re￾quest. In addition, there is an 8-bit sequence number field, reqNo, which must be monotonically increasing with each new migrate re￾quest issued by an end host for a connection. (The sequence num￾ber allows correspondent hosts to ensure Migrate SYNs were not reordered by the network. Sequence space wrap-around is dealt with in the standard fashion.) The token is simply the 64 most￾significant bits of the connection’s SHA-1 hash as computed in the Migrate-Permitted option exchange. The request, R, is similarly

the 64 most-significant bits of a sHA-1 hash calculated from the quence number of the connection initial sequence numbers Migrate SYN segment, S, the connection key, K, and the request open send:(nothing) R=SHAl(Ni, Ni, K, S, D) SYN segments may now correctly arrive on a bound port not in the Listen state. They should be processed only if they contain the Migrate option as specified above. Otherwise, they should be treated as specified in [31]. Upon receipt of a syn packet with the Migrate option, a TCP stack that supports migration attempts to locate the connection on the receiving port with the corresponding (SYN. R token. The token values for each connection were precomputed at d: SYN. ACK (SYN SENT connection establishment, reducing the search to a hash lookup If the token is valid meaning an established connection on this address, porn) pair has the same token, and the reg No is greater than any previously received migrate request, the fixed host then computes R SHAl(Ni, N,, K, S, I)as described above, and YESTABLISHED compares it with the value of the request in the Migrate SYN. If the comparison fails, or the token was invalid a rSt is sent to the If, on the other hand, the token and request are valid, but the regno is smaller than a previously received request, the sYN is assumed to be out-of-order and silently discarded. If the reqNo is identical (MIGRATE. WAIT ---- to the most recently received migrate request this SYN is assumed to be a duplicate of the most recently received SYN, and processed cordingly. Figure 4: Partial TCP state transition diagram with Migrate transitions(adapted from 33, figure 1812D) Otherwise, the destination address and port associated with the matching connection should be updated to reflect the source of the in MIGRATE-WAIT for over a specified period of time. We recom Migrate SYN, and a SYNACk packet generated, with the ACK mend using the 2MSL ([31]specifies a Maximum Ifetime field set to the last received contiguous byte of data, and the con- (MSL)as 2 minutes, but common implementatio Ise values nection placed in the SYN-RCVD state. Upon receipt of an ACk, of I minute or 30 seconds for MSL [33])period he connection continues as before for the TIme-wait state 4.5 MIGRATE WAIT state any segments received while in the MIgrate WAIt state should be processed as in the ESTaBLiSHEd state, except that no ACKs This section assumes that the reader is familiar with the TCP state should be generated The only way a connection is removed from machine and transitions [33, Chapter 18] the migrate-WaIT state is on the receipt of a Migrate SYN with Special processing of TCP RST messages is required with migrate- the same fashion as if it were in the established state when it able connections, as a mobile host's old IP address may be reas- received the SYN signed before it has issued a migrate request to the fixed host. Figure 4 shows the modified TCP state transition diagram for connections The MIgrate-Walt state prevents connections from being in that have successfully negotiated the Migrate-Permitted option. The advertently dropped if the address allocation policy on the mobile receipt of a RST that passes the standard sequence number checks hosts previous network reassigns the mobile hosts old IP address n the ESTABLISHEd state does not immediately terminate the before the mobile host has reconnected at a new location and had connection, as specified in [31]. Instead, the connection is placed chance to migrate the connection. It also prevents the continued into a new MIGRATE_WAIT state.(A similar, but far less likely sit retransmission of data to an unreachable host uation can occur if the fixed host is in the FIN- WAITI state-the This passive approach to disconnection discovery is preferred over application on the fixed host has closed the connection, but there remains data in the connection buffer to be transmitted. For sim- an active. mobile-initiated squelch message because any such mes- age could be lost. Furthermore, a mobile host may not have suf plicity, these additional state transitions are not shown in figure 4.) ficient(if any) notice of address reassignment to issue such mes- Connections in the migrate-WaIT state function as if they sages. As an added performance enhancement, however, mobile hosts aware of an impending migration may themselves emit or ACKs), and are moved to CLOSEd if they remain special RST to the peer, which will force the connection into MI- Migrated connections will generally originate from the same GRATE-WAIT, preventing additional packet transmission until the port as before. However, if the mobile host is behind a NAT,it And any guaranteed-reliable transmission mechanism could possible the connection has been mapped to a different port. take unbounded time

the 64 most-significant bits of a SHA-1 hash calculated from the sequence number of the connection initial sequence numbers N, Migrate SYN segment, S, the connection key, K, and the request sequence number, I. R = SHA1(Ni, Nj , K, S, I) SYN segments may now correctly arrive on a bound port not in the LISTEN state. They should be processed only if they contain the Migrate option as specified above. Otherwise, they should be treated as specified in [31]. Upon receipt of a SYN packet with the Migrate option, a TCP stack that supports migration attempts to locate the connection on the receiving port with the corresponding token. The token values for each connection were precomputed at connection establishment, reducing the search to a hash lookup. If the token is valid, meaning an established connection on this
address, port pair has the same token, and the reqNo is greater than any previously received migrate request, the fixed host then computes R = SHA1(Ni, Nj , K, S, I) as described above, and compares it with the value of the request in the Migrate SYN. If the comparison fails, or the token was invalid, a RST is sent to the address and port issuing the Migrate SYN, and the SYN ignored. If, on the other hand, the token and request are valid, but the reqNo is smaller than a previously received request, the SYN is assumed to be out-of-order and silently discarded. If the reqNo is identical to the most recently received migrate request this SYN is assumed to be a duplicate of the most recently received SYN, and processed accordingly. Otherwise, the destination address and port5 associated with the matching connection should be updated to reflect the source of the Migrate SYN, and a SYN/ACK packet generated, with the ACK field set to the last received contiguous byte of data, and the con￾nection placed in the SYN RCVD state. Upon receipt of an ACK, the connection continues as before. 4.5 MIGRATE WAIT state This section assumes that the reader is familiar with the TCP state machine and transitions [33, Chapter 18]. Special processing of TCP RST messages is required with migrate￾able connections, as a mobile host’s old IP address may be reas￾signed before it has issued a migrate request to the fixed host. Figure 4 shows the modified TCP state transition diagram for connections that have successfully negotiated the Migrate-Permitted option. The receipt of a RST that passes the standard sequence number checks in the ESTABLISHED state does not immediately terminate the connection, as specified in [31]. Instead, the connection is placed into a new MIGRATE WAIT state. (A similar, but far less likely sit￾uation can occur if the fixed host is in the FIN WAIT1 state—the application on the fixed host has closed the connection, but there remains data in the connection buffer to be transmitted. For sim￾plicity, these additional state transitions are not shown in figure 4.) Connections in the MIGRATE WAIT state function as if they were in the ESTABLISHED state, except that they do not emit any seg￾ments (data or ACKs), and are moved to CLOSED if they remain 5 Migrated connections will generally originate from the same port as before. However, if the mobile host is behind a NAT, it is possible the connection has been mapped to a different port. CLOSED LISTEN SYN RCVD SYN SENT ESTABLISHED MIGRATE WAIT 2MSL timeout appl: close or timeout appl: passive open send: nothing appl: active open send: SYN recv: SYN send: SYN, ACK recv: ACK recv:SYN,ACK;send:ACK appl: send data send: SYN recv: RST recv: SYN; send: SYN, ACK recv: SYN migrate T,R send: SYN, ACK appl: migrate send: SYN migrate T,R recv: RST recv: SYN migrate T,R send: SYN, ACK Figure 4: Partial TCP state transition diagram with Migrate transitions (adapted from [33, figure 18.12]) in MIGRATE WAIT for over a specified period of time. We recom￾mend using the 2MSL ([31] specifies a Maximum Segment Lifetime (MSL) as 2 minutes, but common implementations also use values of 1 minute or 30 seconds for MSL [33]) period of time specified for the TIME WAIT state. Any segments received while in the MIGRATE WAIT state should be processed as in the ESTABLISHED state, except that no ACKs should be generated. The only way a connection is removed from the MIGRATE WAIT state is on the receipt of a Migrate SYN with the corresponding connection key. The connection then responds in the same fashion as if it were in the ESTABLISHED state when it received the SYN. The MIGRATE WAIT state prevents connections from being in￾advertently dropped if the address allocation policy on the mobile host’s previous network reassigns the mobile host’s old IP address before the mobile host has reconnected at a new location and had a chance to migrate the connection. It also prevents the continued retransmission of data to an unreachable host. This passive approach to disconnection discovery is preferred over an active, mobile-initiated squelch message because any such mes￾sage could be lost.6 Furthermore, a mobile host may not have suf- ficient (if any) notice of address reassignment to issue such mes￾sages. As an added performance enhancement, however, mobile hosts aware of an impending migration may themselves emit a special RST to the peer, which will force the connection into MI￾GRATE WAIT, preventing additional packet transmission until the 6 And any guaranteed-reliable transmission mechanism could take unbounded time.

mobile host has successfully relocated, although such action in- 5.2 Connection hijacking vokes the strict 2MsL time bound on the allowable delay for host relocation and connection migration. Since a Migrate request contains a hash of both the SYN segment's sequence number and migrate request sequence number, a replayed Migrate option can only be used until either a new byte of data or 5 Security issues another migrate connection is sent on the connection. Since self- gration is not allowed, duplicate Migrate SYNs(received out An end-to-end approach to mobility simplifies the trust relation- side of the three-way handshake)are ignored by the peer 1 ships required to securely support end-host mobility compared to however, the mobile host moves rapidly to a another new location, network-layer approaches such as Mobile IP. In addition to the re- a replayed Migrate SYN could be used to migrate the connection several Mobile IP-based proposals require that a correspondent host back to the mobile hosts previous IP, which may have been subse in communication with a mobile host assume the responsibility quently assumed by the attacker. In order to prevent this attack, the Migrate Request option processing ignores the source address and of authenticating communication with an arbitrary set of foreign port in duplicate packets, as a valid request from a relocated mobile agents In their route optimization draft [28, Perkins and Johnson host would include a higher request number More worrisome. however is the fact that once a migrate syn has One of the most difficult aspects of Route Optimization been transmitted, the token is known by any hosts on the new path, for Mobile IP in the Internet today is that of providing and denial-of-service attacks could be launched by sending bogus authentication for all messages that affect the routing of Migrate sYNs with valid tokens. If a mobile host includes a new datagrams to a mobile node Migrate-Permitted option in its Migrate SYN, however, the window of opportunity when the previous connection token can be used (if Since no third parties are required or even authorized to speak on it was snooped)is quite small-only until the new three-way hand the mobile host' s behalf in an end-to-end architecture, the only trust shake is successfully completed relationship required for secure relocation is between the mobile and correspondent host. Clearly they already must have a level of 5.3 Key security trust commensurate with the nature of their communications since they chose to communicate in the first place The connection key used by the Migrate option is negotiated via Regardless of the simplicity of trust relationships, there remains the Elliptic Curve Diffie-Hellman to make it extremely difficult even possibility that untrusted parties could launch attacks against the for hosts that can eavesdrop on the connection in both directions DNS updates or the Migrate and Migrate-Permitted options. The keys off-line, an attacker would have to continually generate Mi- grate SYNs and transmit them to one of the end hosts, hoping to security of dynamic dNS updates is addressed in RFC 2137[81 receive a SYN/ACK in response to a correct guess. Clearly such an resting on the strength of the digital signature scheme used to au- thenticate mobile hosts attack is of little concern in practice, as the expected 2 SYN pack ets required to successfully guess the key would generate sufficient Possible attacks the Migrate TCP options include both load as to be a dos problem in and of themselves denial-of-service away from their and methods of migrating connections Hosts that lie on the path between end hosts, however, have suf- iate end hosts. We discuss these attacks ficient information (namely the two Elliptic Curve Diffie-hellman low, and either show why the migrate options are not vulnerable. or explain why the attack presents no additional threat in relation to components)to launch an attack against the Elliptic Curve syster itself. The best known attack is a distributed version of pollards tandard TCp rho-algorithm [30], which [17] uses to show that a 193-bit EC sys- tem would require 8.52-10 4 MIPS years, or about 1.89-102 years 5.1 Denial of service on a 450Mhz Pentium ll. to defeat. SYN fooding is a common form of Denial-of-Service(DoS)at- While this seems more than secure against ordinary attackers, an tack, and most modern TCP implementations have taken great care extremely well-financed attacker might be able to launch such an at- to avoid consuming u ry resources unless a three-way hand- tack on a long-running connection in the not-too-distant future. The shake is complete. To validate a Migrate request, the correspondent host performs a significant computation(the SHA-I hash), whicl are restricted by the 40-byte limitation on TCP options. Given the implies we need to be especially vigilant against DoS attacks that prevalence of the MSS (4 bytes), Window Scale(3 bytes),SACK attempt to deplete the CPU resources of a target host. The val Permitted(2 bytes), and Timestamp (10 bytes)options(of which dation is not performed unless an attacker succeeds in guessing a we are already using 8 bytes)in todays SYN segments, the 20-byte valid, pre-computable token(with a I in 2 probability ) since a that further securing the connection key against brute-force attacks RST message is generated if either the token or the request is in. from hosts on the path between the two end hosts is largely irrel valid, an attacker has no way to identify when it has found a valie token. Because a would-be attacker would therefore have to issue evant, given the ability of such hosts to launch man-in-the-middle roughly 26 Migrate SYNs to force a request validation, we argue attacks against TCP with much less difficulty that the TCP Migrate option does not introduce any additional Dos The security of TCP connections, migrateable or not, continues to concerns above standard TCl remain with the authentication of end hosts and the establishment

mobile host has successfully relocated, although such action in￾vokes the strict 2MSL time bound on the allowable delay for host relocation and connection migration. 5 Security issues An end-to-end approach to mobility simplifies the trust relation￾ships required to securely support end-host mobility compared to network-layer approaches such as Mobile IP. In addition to the re￾lationship between a mobile host and any proxies or home agents, several Mobile IP-based proposals require that a correspondent host in communication with a mobile host assume the responsibility of authenticating communication with an arbitrary set of foreign agents. In their route optimization draft [28], Perkins and Johnson state: One of the most difficult aspects of Route Optimization for Mobile IP in the Internet today is that of providing authentication for all messages that affect the routing of datagrams to a mobile node. Since no third parties are required or even authorized to speak on the mobile host’s behalf in an end-to-end architecture, the only trust relationship required for secure relocation is between the mobile and correspondent host. Clearly they already must have a level of trust commensurate with the nature of their communications since they chose to communicate in the first place. Regardless of the simplicity of trust relationships, there remains the possibility that untrusted parties could launch attacks against the end hosts or connections between them utilizing either dynamic DNS updates or the Migrate and Migrate-Permitted options. The security of dynamic DNS updates is addressed in RFC 2137 [8], resting on the strength of the digital signature scheme used to au￾thenticate mobile hosts. Possible attacks against the Migrate TCP options include both denial-of-service attacks and methods of migrating connections away from their appropriate end hosts. We discuss these attacks below, and either show why the Migrate options are not vulnerable, or explain why the attack presents no additional threat in relation to standard TCP. 5.1 Denial of service SYN flooding is a common form of Denial-of-Service (DoS) at￾tack, and most modern TCP implementations have taken great care to avoid consuming unnecessary resources unless a three-way hand￾shake is complete. To validate a Migrate request, the correspondent host performs a significant computation (the SHA-1 hash), which implies we need to be especially vigilant against DoS attacks that attempt to deplete the CPU resources of a target host. The vali￾dation is not performed unless an attacker succeeds in guessing a valid, pre-computable token (with a 1 in 264 probability); since a RST message is generated if either the token or the request is in￾valid, an attacker has no way to identify when it has found a valid token. Because a would-be attacker would therefore have to issue roughly 263 Migrate SYNs to force a request validation, we argue that the TCP Migrate option does not introduce any additional DoS concerns above standard TCP. 5.2 Connection hijacking Since a Migrate request contains a hash of both the SYN segment’s sequence number and migrate request sequence number, a replayed Migrate option can only be used until either a new byte of data or another migrate connection is sent on the connection. Since self￾migration is not allowed, duplicate Migrate SYNs (received out￾side of the three-way handshake) are ignored by the peer TCP. If, however, the mobile host moves rapidly to a another new location, a replayed Migrate SYN could be used to migrate the connection back to the mobile host’s previous IP, which may have been subse￾quently assumed by the attacker. In order to prevent this attack, the Migrate Request option processing ignores the source address and port in duplicate packets, as a valid request from a relocated mobile host would include a higher request number. More worrisome, however, is the fact that once a Migrate SYN has been transmitted, the token is known by any hosts on the new path, and denial-of-service attacks could be launched by sending bogus Migrate SYNs with valid tokens. If a mobile host includes a new Migrate-Permitted option in its Migrate SYN, however, the window of opportunity when the previous connection token can be used (if it was snooped) is quite small—only until the new three-way hand￾shake is successfully completed. 5.3 Key security The connection key used by the Migrate option is negotiated via Elliptic Curve Diffie-Hellman to make it extremely difficult even for hosts that can eavesdrop on the connection in both directions to guess the key. Without sufficient information to verify possible keys off-line, an attacker would have to continually generate Mi￾grate SYNs and transmit them to one of the end hosts, hoping to receive a SYN/ACK in response to a correct guess. Clearly such an attack is of little concern in practice, as the expected 263 SYN pack￾ets required to successfully guess the key would generate sufficient load as to be a DoS problem in and of themselves. Hosts that lie on the path between end hosts, however, have suf- ficient information (namely the two Elliptic Curve Diffie-Hellman components) to launch an attack against the Elliptic Curve system itself. The best known attack is a distributed version of Pollard’s rho-algorithm [30], which [17] uses to show that a 193-bit EC sys￾tem would require 8.52·1014 MIPS years, or about 1.89·1012 years on a 450Mhz Pentium II, to defeat. While this seems more than secure against ordinary attackers, an extremely well-financed attacker might be able to launch such an at￾tack on a long-running connection in the not-too-distant future. The obvious response is to increase the key space. Unfortunately, we are restricted by the 40-byte limitation on TCP options. Given the prevalence of the MSS (4 bytes), Window Scale (3 bytes), SACK Permitted (2 bytes), and Timestamp (10 bytes) options (of which we are already using 8 bytes) in today’s SYN segments, the 20-byte Migrate-Permitted option is already as large as is feasible. We argue that further securing the connection key against brute-force attacks from hosts on the path between the two end hosts is largely irrel￾evant, given the ability of such hosts to launch man-in-the-middle attacks against TCP with much less difficulty! The security of TCP connections, migrateable or not, continues to remain with the authentication of end hosts, and the establishment

ng session keys to authenticate ongo though we have taken care to ensure the Migrate option does not Mobile further decrease the security of TCP connections, the latter are inherently insecure, as IP address spoofing and sequence number 19.2Kbps guessing are not very difficult. Hence we strongly caution users Modem concerned with connection security to use additional application- layer cryptographic techniques to authenticate end points and the payload traffic Host 5.4 IPsec When used in conjunction with IPsec [4, there are additional is- 19.2Kbps sues raised by the use of the Migrate options. IPsec Security As- Modem sociations(SAs)are established on an IP-address basis. When a Mobile connection with an associated Sa is migrated, a new Sa must be Location established with the new destination address before communica- tion is resumed. lf the establishment of a this new sa conflicts with existing policy, the connection is dropped. This seemingly unfor unate result is actually appropriate. Since IPsec's Security Polict Figure 5: Network topology used for migration experiments Database(SPD)is keyed on IP network address, the policies speci- fied within speak to a belief about the trustworthiness of a particular a CDPD link, it seems likely that the user would opt to migrate most open connections to the address associated with the 802.11 link. Similarly the daemon could watch for address changes on at- If a mobile host attaches to a foreign network, any security assump- tached interfaces(possibly as a result of DHCP lease expirations tions based on its normal point of attachment are invalid. If the end and renewals) and migrate connections appropriately. We plan to host itself continues to have sufficient credentials independent of its implement such a daemon in the near fut nt of attachment, an end-to-end authentication method should be used. and a secure tunnel established for communication 6.1 Experiments untrusted network. a discussion of such techniques is outside of the scope of this document. Figure 5 shows the network topology used to gather the TCP traces shown in figures 6 and 7. The traces were collected at the fixed 6 Implementation basestation, which is on the path between the fixed host and both mobile host locations. We conducted tcp bulk transfers from a We have implemented this architecture in the linux 2.2.15 kernel, server on the fixed host to a client on the mobile host. The client ing bind 8.2.2-P3 as the name server for mobile hosts. The IPv4 initiates the connection from one location, and migrates to another TCP stack has been modified to support the Migrate options. Con- location at some later point. Both mobile host locations use iden- nection migration can be affected through two methods. Applica- tical connections, a 19 2Kbps serial link with a100ms round-trip tions with open connections may explicitly request a migration by latency. The basestation and fixed host are on a 100Mbps Ether- suing an ioctl()on the connection's file descriptor specify. net segment, hence the link to the mobile host is the connection the address to migrate to. Most current applications, howeve bottleneck. This topology is intentionally simple in order to isolate lack a notification method so the system can inform them the host the various subtleties of migrating TCP connections, as discussed has moved. Hence we also provide a mechanism for processes to migrate open connections, regardless of whether they have the file descriptor open Figure 6 shows the TCP sequence trace of a migrated TCP connec- tion. At time t a 4.9s the mobile host moved to a new address This is done through the Linux /proc file system. a directory and issued a Migrate SYN, as depicted by the dotted line. Since /proc/net/migrate contains files of the form source ad- the host is no longer attached at its previous address, all of the en- dress: source port->dest address: dest port for each open connec- queued segments at the bottleneck are lost. (The amount of lost data on that has successfully negotiated the Migrate-Permitted option. is bounded by the advertised receive window of the mobile host. a are owned by the user associated with the process that host that moves frequently across low-bandwidth connections may opened the connection. Any process with appropriate permissions wish to advertise a smaller receive window to reduce the number of can then write a new IP address to these files, causing the corre- wasted segments. Finally, at t a 68s the fixed host's SYN/ACK sponding connection to be migrated to the specified address. This passes through the bottleneck, and is aCKed by the fixed host method has the added benefit of being readily accessed by a user RTT later The fixed host does not immediately restart data transmissions It is expected that mobile hosts will run a mobility daemon that because the TCP Migrate options do not change the congestion- racks current points of network attachment, and migrates open con- avoidance or retransmission behavior of TCP. The sender is stil nections based on some policy about the user's preference for cer- waiting for ACKs for the lost segments; as far as it is concerned, tain methods of attachment. For instance, when an 802.11 interface it has only received two(identical ) ACKs--the original ACK, and comes up on a laptop that previously established connections on one duplicate as part of the Migrate SYN three-way handshake

of strong session keys to authenticate ongoing communication. Al￾though we have taken care to ensure the Migrate option does not further decrease the security of TCP connections, the latter are inherently insecure, as IP address spoofing and sequence number guessing are not very difficult. Hence we strongly caution users concerned with connection security to use additional application￾layer cryptographic techniques to authenticate end points and the payload traffic. 5.4 IPsec When used in conjunction with IPsec [4], there are additional is￾sues raised by the use of the Migrate options. IPsec Security As￾sociations (SAs) are established on an IP-address basis. When a connection with an associated SA is migrated, a new SA must be established with the new destination address before communica￾tion is resumed. If the establishment of a this new SA conflicts with existing policy, the connection is dropped. This seemingly unfor￾tunate result is actually appropriate. Since IPsec’s Security Policy Database (SPD) is keyed on IP network address, the policies speci- fied within speak to a belief about the trustworthiness of a particular portion of the network. If a mobile host attaches to a foreign network, any security assump￾tions based on its normal point of attachment are invalid. If the end host itself continues to have sufficient credentials independent of its point of attachment, an end-to-end authentication method should be used, and a secure tunnel established for communication over the untrusted network. A discussion of such techniques is outside of the scope of this document. 6 Implementation We have implemented this architecture in the Linux 2.2.15 kernel, using Bind 8.2.2-P3 as the name server for mobile hosts. The IPv4 TCP stack has been modified to support the Migrate options. Con￾nection migration can be affected through two methods. Applica￾tions with open connections may explicitly request a migration by issuing an ioctl() on the connection’s file descriptor specify￾ing the address to migrate to. Most current applications, however, lack a notification method so the system can inform them the host has moved. Hence we also provide a mechanism for processes to migrate open connections, regardless of whether they have the file descriptor open or not. This is done through the Linux /proc file system. A directory /proc/net/migrate contains files of the form source ad￾dress:source port->dest address:dest port for each open connec￾tion that has successfully negotiated the Migrate-Permitted option. These files are owned by the user associated with the process that opened the connection. Any process with appropriate permissions can then write a new IP address to these files, causing the corre￾sponding connection to be migrated to the specified address. This method has the added benefit of being readily accessed by a user directly through the command line. It is expected that mobile hosts will run a mobility daemon that tracks current points of network attachment, and migrates open con￾nections based on some policy about the user’s preference for cer￾tain methods of attachment. For instance, when an 802.11 interface comes up on a laptop that previously established connections on Fixed Host Fixed Basestation Mobile Location 1 Mobile Location 2 100Mbps Ethernet 19.2Kbps Modem 19.2Kbps Modem Figure 5: Network topology used for migration experiments a CDPD link, it seems likely that the user would opt to migrate most open connections to the address associated with the 802.11 link. Similarly the daemon could watch for address changes on at￾tached interfaces (possibly as a result of DHCP lease expirations and renewals) and migrate connections appropriately. We plan to implement such a daemon in the near future. 6.1 Experiments Figure 5 shows the network topology used to gather the TCP traces shown in figures 6 and 7. The traces were collected at the fixed basestation, which is on the path between the fixed host and both mobile host locations. We conducted TCP bulk transfers from a server on the fixed host to a client on the mobile host. The client initiates the connection from one location, and migrates to another location at some later point. Both mobile host locations use iden￾tical connections, a 19.2Kbps serial link with ≈100ms round-trip latency. The basestation and fixed host are on a 100Mbps Ether￾net segment, hence the link to the mobile host is the connection bottleneck. This topology is intentionally simple in order to isolate the various subtleties of migrating TCP connections, as discussed below. Figure 6 shows the TCP sequence trace of a migrated TCP connec￾tion. At time t ≈ 4.9s the mobile host moved to a new address and issued a Migrate SYN, as depicted by the dotted line. Since the host is no longer attached at its previous address, all of the en￾queued segments at the bottleneck are lost. (The amount of lost data is bounded by the advertised receive window of the mobile host. A host that moves frequently across low-bandwidth connections may wish to advertise a smaller receive window to reduce the number of wasted segments.) Finally, at t ≈ 6.8s the fixed host’s SYN/ACK passes through the bottleneck, and is ACKed by the fixed host a RTT later. The fixed host does not immediately restart data transmissions because the TCP Migrate options do not change the congestion￾avoidance or retransmission behavior of TCP. The sender is still waiting for ACKs for the lost segments; as far as it is concerned, it has only received two (identical) ACKs—the original ACK, and one duplicate as part of the Migrate SYN three-way handshake

BEDOk transmitted. Notice that because SACK prevents the retransmission of the previously-received segments, only those segments lost due to the mobile host s address change are retransmitted and the con- nection continues as before. The success of this trace demonstrates that the Migrate options work well with SACK due to the consis- tency of the sequence space across migrations. 6.2 Performance enhancements 7E000 Several enhancements can be made by implementations to improve 74000 overall connection throughput during connection migration. The most obvious of these is issuing three DUP-ACKs immediately af- ter a migrate request, thereby triggering the fast-retransmit alge rithm and avoiding the timeout seen in the previous example [6] By preempting the timeout, the connection further avoids dropping ime (secs) Figure 6: A TCP connection sequence trace showing the mi Such techniques should be used with care, however, as they assume tion of an open connection the available bandwidth of the new path between mobile and fixed host is on the same order-of-magnitude as the previous path. For able assumption. When moving from local to wide-area technolo- gies, however, there may be order-of-magnitude discrepancies in the available bandwidth. Hence we do not include such speed-ups the TCP Migrate specification, and leave it to particular imple- mentations to responsibly evaluate the circumstances and provide behavior compatible with standard TCP. 7 Deployment Issues As with any scheme for mobility support, there are some deploy ment issues to be addressed By pushing the implementation of mo- bility mechanisms--connection migration in particular-to the end points, our system requires changes to each transport protocol. For ur tCP connection protocol can be generalized to other UDP-based protocols with little difficulty. Significant ex- Figure 7: A TCP Migrate connection (with SACK) sequence mples include streaming protocols such as RTP and proprietary trace with losses just before migrati protocols like Real, Quicktime and Netshow. We note that most of these already have a control channel used for congestion and quality Finally, at t a 7.8s the retransmission timer expires(the inter control, and such applications would likely wish to be informed of val is from the first ACK, sent earlier at t N 4.9s) and the fixed changes due to mobility as well. Furthermore, we argue that not all applications require network-layer mobility, especially those char- host retransmits the first of the lost segments. It is immediately ac- acterized by short transactions where an application-level retry of knowledged by the mobile host, and TCP resumes transmission in the transaction is easy to perform; we therefore make the case using the end-to-end argument that mobility might be best implemented Figure 7 shows the TCP sequence trace of a similar migrate TCP as a higher-level, end-to-end function just like reliability connection. As before. the dashed line indicates the mobile host is- led a migrate request at time t 27 1s. This time, however, there erhaps the biggest limitation of our approach is that both peers cannot move simultaneous/. Because our scheme has no anchor were additional losses on the connection that occurred just before point like Mobile IP's home agent, any IP address change must be the migration, as can be seen at t a 249s. These segments are fast do transmitted, and pass through the bottleneck at t a 28s due to the a serious limitation to the widespread applicability of the protocol DUP-ACKs generated by the remaining SYNs. Unfortunately, this since we are primarily targeting infrastructure-based rather than ad fter the mobile host has migrated, so they, along with all the seg ments addressed to the mobile host s initial address after t2 27 1s hoc network topologies in this work In addition to these two limitations there are several issues that t≈29s,the es it out of the crop up when one considers presently-deployed applications. While the bottleneck, and the mobile host immediately gene it is currently possible for Internet hosts to be re-addressed while ACK. As in the previous example, however, the fixed host "Simultaneously" is defined as whenever the intervals between awaiting ACKs for previously transmitted segments. It is only at address change and the(would-be)reception of the Migrate SYN t a 31s that the timer expires and the missing segments are re- by the corresponding host for both end hosts overlap

70000 72000 74000 76000 78000 80000 82000 84000 86000 0 2 4 6 8 10 12 Sequence Number (bytes) Time (secs) Before: Data ACKs Host Migration After: Data ACKs Figure 6: A TCP connection sequence trace showing the migra￾tion of an open connection 68000 70000 72000 74000 76000 78000 80000 82000 84000 22 24 26 28 30 32 34 Sequence Number (bytes) Time (secs) Before: Data ACKs Host Migration After: Data ACKs Figure 7: A TCP Migrate connection (with SACK) sequence trace with losses just before migration Finally, at t ≈ 7.8s the retransmission timer expires (the inter￾val is from the first ACK, sent earlier at t ≈ 4.9s) and the fixed host retransmits the first of the lost segments. It is immediately ac￾knowledged by the mobile host, and TCP resumes transmission in slow-start after the timeout. Figure 7 shows the TCP sequence trace of a similar migrate TCP connection. As before, the dashed line indicates the mobile host is￾sued a migrate request at time t ≈ 27.1s. This time, however, there were additional losses on the connection that occurred just before the migration, as can be seen at t ≈ 24.9s. These segments are fast￾retransmitted, and pass through the bottleneck at t ≈ 28s due to the DUP-ACKs generated by the remaining SYNs. Unfortunately, this is after the mobile host has migrated, so they, along with all the seg￾ments addressed to the mobile host’s initial address after t ≈ 27.1s, are lost. At t ≈ 29s, the Migrate SYN/ACK makes it out of the queue at the bottleneck, and the mobile host immediately generates an ACK. As in the previous example, however, the fixed host is still awaiting ACKs for previously transmitted segments. It is only at t ≈ 31s that the timer expires and the missing segments are re￾transmitted. Notice that because SACK prevents the retransmission of the previously-received segments, only those segments lost due to the mobile host’s address change are retransmitted, and the con￾nection continues as before. The success of this trace demonstrates that the Migrate options work well with SACK due to the consis￾tency of the sequence space across migrations. 6.2 Performance enhancements Several enhancements can be made by implementations to improve overall connection throughput during connection migration. The most obvious of these is issuing three DUP-ACKs immediately af￾ter a migrate request, thereby triggering the fast-retransmit algo￾rithm and avoiding the timeout seen in the previous example [6]. By preempting the timeout, the connection further avoids dropping into slow-start and congestion avoidance. Such techniques should be used with care, however, as they assume the available bandwidth of the new path between mobile and fixed host is on the same order-of-magnitude as the previous path. For migrations across homogeneous technologies this may be a reason￾able assumption. When moving from local to wide-area technolo￾gies, however, there may be order-of-magnitude discrepancies in the available bandwidth. Hence we do not include such speed-ups in the TCP Migrate specification, and leave it to particular imple￾mentations to responsibly evaluate the circumstances and provide behavior compatible with standard TCP. 7 Deployment Issues As with any scheme for mobility support, there are some deploy￾ment issues to be addressed. By pushing the implementation of mo￾bility mechanisms—connection migration in particular—to the end points, our system requires changes to each transport protocol. For￾tunately, our TCP connection migration protocol can be generalized to other UDP-based protocols with little difficulty. Significant ex￾amples include streaming protocols such as RTP and proprietary protocols like Real, Quicktime and Netshow. We note that most of these already have a control channel used for congestion and quality control, and such applications would likely wish to be informed of changes due to mobility as well. Furthermore, we argue that not all applications require network-layer mobility, especially those char￾acterized by short transactions where an application-level retry of the transaction is easy to perform; we therefore make the case using the end-to-end argument that mobility might be best implemented as a higher-level, end-to-end function just like reliability. Perhaps the biggest limitation of our approach is that both peers cannot move simultaneously. 7 Because our scheme has no anchor point like Mobile IP’s home agent, any IP address change must be completed before the other can proceed. We do not view this as a serious limitation to the widespread applicability of the protocol, since we are primarily targeting infrastructure-based rather than ad￾hoc network topologies in this work. In addition to these two limitations, there are several issues that crop up when one considers presently-deployed applications. While it is currently possible for Internet hosts to be re-addressed while 7 “Simultaneously” is defined as whenever the intervals between address change and the (would-be) reception of the Migrate SYN by the corresponding host for both end hosts overlap