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 handshakeof 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