End-to-End Architectures for the Internet Host Mobility: An Overview

Transcription

1 Page 1 of 7 End-to-End Architectures for the Internet Host Mobility: An Overview Bilal Farooq Lahore University of Management Sciences Department of Computer Science bilalf@lums.edu.pk April 7 th, 2003 Abstract: With the emergence of mobile portable computing devices and establishment of Internet as a swift global communication medium, the need for mobility support on Internet is becoming louder and louder. In recent years a lot of effort has been made towards achieving mobility on Internet. This effort has resulted in two different types of architectures: Network-layer based architecture and End-to-End architecture. This paper explores end-to-end architectures and compares it with its counterpart. 1. Introduction: Use of mobile portable devices (e.g. laptops, handheld computers, and cellular phones) to access Internet is becoming more and more common nowadays. These portable devices have introduced the need of high degree of mobility on the Internet. Internet was never designed to support mobility. To achieve transparent host mobility on the Internet, researchers around the world, are now concentrating on two basic approaches: The network-layer mobility scheme and the end-to-end mobility scheme. In network-layer mobility scheme, host mobility is handled in the network structure. Whereas, in end-toend mobility scheme, mobility is handled at a higher level in the end host [10]. Mobile IP, PPTP, and L2TP use IP tunneling techniques to achieve network-layer transparent mobility [10]. End-to-end architecture uses straight-line unicast routing instead of a triangular approach, adopted in network-layer architectures [10, 14]. Due to this fact end-to-end architecture performs better than the network-layer architecture. Moreover, network-layer architecture requires wide-scale changes in the network structure and on the other hand, end-to-end architecture requires changes only in the end hosts. Thus end-to-end approach is easy and fast to deploy in the current internet infrastructure. 2. Related work: IP v4, the most widely used network-level protocol on Internet, works on the assumption that a 2.1 Mobile IP: Mobile IP is a network-layer mobility scheme, which needs infrastructure changes at network layer Foreign agent intercepts all the packets destined to its advertised care-of IP addresses, and finds if the des Home Agent Foreign Agent CommH Mobile Node

2 Page 2 of 7 Figure 2.1 Communication route in Mobile IP Problem with Mobile IP is that it needs major changes in the current infrastructure of Internet. In Mobile Perkins and Johnson [9] suggested that the correspondent host could cache the care-of address of mobile 2.2 Multicast-based Architecture, MSM-IP: Mysore and Bharghavan introduced the idea of using multicast addresses to achieve mobility. Myso 2.3 MSOCKS: MSOCKS is a transport-layer based solution to mobility of the host on Internet. Whenever a mobile It is not feasible that every mobile host could have its own proxy. Mobile hosts have to share the proxy. T 3. End-to-End Architecture overview: Saltzer, Reed and Clark in their classic paper on end-to-end argument, wrote: If the same functionality can be logically implemented in two layers in a layered system then it is advisable to implement that functionality at the higher layer [13]. End-to-End Architecture follows the same argument. Providing mobility support at end points enables higher layers to know about the changes and adjust themselves to the changes in a manner that best fits their needs. Unlike Mobile IP end-to-end approach does not require any change in current infrastructure of Internet. End-to-End architecture ensures that the communication between two hosts remain unaffected by mobility. Generally there are four components of an end-to-end architecture for the host mobility on Internet: addressing, mobile host location announcement, seamless communication, and session layer connection management. 4. Addressing: Like Mobile IP, in End-to-End architecture issue of obtaining IP address in new network is kept separate from location announcement and seamless communication. Dynamic Host Configuration Protocol (DHCP) [2], Autoconfiguration Protocol [19], or manual assignment can be used as an addressing scheme. 5. Location Announcement: Once the IP address of a mobile host changes, its new host name/ip address mapping must be communicated to correspondent nodes. If the mobile host were always a client, then it was no need to communicate the new mapping but in case of servers and other applications running on the mobile host announcement of the new mapping is necessary. Snoeren and Hari in their work [14] proposed that widely deployed DNS can be used for propagating mapping updates over the Internet. Currently all the End-to-End architectures use widely employed DNS system to announce the new host name/ip address mapping. Mobile host detects its change in the point of attachment by user level daemon and then sends the new host name/ip address mapping using secure DNS dynamic update protocol [3] with the TTL value of 0 (so that the update is not cached). Due to the distributed nature of DNS, protocol assumes that data in the system will be updated very slowly [6]. This may cause the correspondent node to send packets to the mobile host s old location, which results packet loss and thus retransmissions. Snoeren, Hari and Kaashoek in their work [15] argued that binding mobility-handling with naming system unnecessarily restricts the mobility services, and restricts the ability to leverage advances in name resolution techniques. By removing this binding, applications can use name resolution system which best suits them. Another issue in using DNS

3 Page 3 of 7 dynamic update is the danger of hijacking of DNS dynamic updates. 6. Seamless Communication: In case of new connection the DNS update is enough for a correspondent host to connect to mobile host at its new location but preserving an already established connection requires additional consideration. A major problem in seamless mobility of a host in Internet is the fact that the TCP connection is associated with a particular IP address and port number. A TCP connection is uniquely identified by a 4-tuple: <source IP address, source port, destination IP address, destination port>. Even if a packet reaches a TCP connection with a source IP address other than the one in the 4-tuple of that TCP connection, it is dropped. To keep the TCP connection intact even if mobile host s IP address changes, Snoeren and Hari [14, 16] proposed a set of TCP options to migrate connection from one IP address to another, thereby permitting on-the-fly re-addressing of end-hosts. TCP at mobile host sends the correspondent host a variable-length [3] Migrate-Permitted option (figure 6.1) during the three-way initial SYN handshake. Migrate- Permitted option comes in two variants: the insecure version of length 3 bytes and the secure version of 20 bytes. The secure version consists of 1 byte Curve Name and a 17 bytes Elliptical Curve Deffie- Hellman Public Key fragment, and is used to negotiate a secret key connection. Migrate-Permitted negotiates a shared connection token which is used to identify the connection in case of migration. When a TCP connection at Mobile host becomes aware that its IP address/port pair is about to change, it pauses transmission of all buffered TCP packets and if possible, sends duplicate ACKs, advertising a receiver window size of zero to suppress further transmission from the fixed host. When mobile host gets its new IP address, it sends TCP migrate option (figure 6.2) to the correspondent host. Migrate option consists of an 8 bytes token and an 8 bytes request. Token consists of authentication information exchanged earlier in migrate-permitted option and is used to secure migration. Correspondent host on receiving migrate request authenticates the request by comparing the token sent by the mobile host. If the request is authenticated, correspondent host sends a SYN/ACK with the ACK field set to the acknowledgement of the last packet acknowledged on the previous connection. It also resets the congestion-related state of the connection to initial values. This is done because of the fact that the congestion state in the new network might not be the same as it was in the previous network. Upon receipt of SYN/ACK, the mobile host sends an ACK with sequence number of the last packet sent. When correspondent host receives that ACK, the migration process is completed and the connection continues as before. Length: Curve ECDH Kind: 15 3/20 Name PK Figure 1.1 TCP Migrate Permitted Option Kind: 16 Length: 19 Req No Token Token (cont.) Request Request (cont.) Figure 6.2 TCP Migrate Option If the address allocation policy at mobile host s old network reassigns the old IP address before migrate request of mobile host could reach the correspondent node, the new node obtaining that old IP will send RST if it receives packets for the mobile host. To overcome this problem Snoeren and Hari modified the traditional TCP state machine to include MIGRATE_WAIT state. Figure 6.3 shows the original and figure 6.4 shows the modified TCP state diagram. Due to this change the RST receipt does not terminates the connection but the connection goes into MIGRATE_WAIT state and waits for the migration request. If the time out occurs only then the connection is closed. The resulting TCP connection can thus identified by either traditional 4-tuple or by new triple: <source address, source port, token>. Fundamentally, the Migrate option allows the corresponding hosts to synchronize two separate TCP connections such that the context is identical [16].

4 Page 4 of 7 Figure 6.1: Partial TCP state transition diagram[18] Figure 6.1: Partial TCP state transition diagram with Migrate transitions [16] 7. Migrate Project: Migrate project provides mobility services at session layer of the end host. Session layer provides a unified abstraction to the application to handle mobility: a session. Session caters for the changes in transport, network and even other session layer protocol states. Session provides check-pointing and resumption facilities for periods of disconnection, enabling comprehensive, session-based state

5 Page 5 of 7 management for mobile-aware applications [17]. 8. End-to-End Architecture: A Step Further: Hari and Snoeren in their work assume that both end points of the connection are not simultaneously mobile. This is a significant drawback which not only limits the mobility but in many cases fails to provide mobility e.g. in case of ad hoc networks where all nodes are mobile. Tilak and Abu-Ghazaleh [20] in their work proposed further changes in the TCP state diagram, which enables concurrent peer migration. Figure 8.1 shows the further modified TCP state machine. Figure 8.1 Partial TCP state transition diagram Proposed by Tilak and Abu-Ghazaleh Following situations could occur in case of any migration: 8.1 Only one mobile host moved to new network (one-way migration): This is the case, which is already handled in Snoeren and Hari s work and does not need any additional consideration. 8.2 First a single mobile host moved to new network. The other peer moved to its new network after receiving the migrate request from first mobile host: Here if the other peer sent SYN/ACK before moving to new network, then its the same case as two one-way migrations and can be handled in the same manner as 8.1. If the other peer didn t send a SYN/ACK before it moved, then once the peer gets new address in the new network, it sends SYN/Migrate and move to SYN-SENT state. First peer on receiving SYN/Migrate sends SYN/ACK and moves to SYN/RECEIVED state. 8.3 Both peers moved at the same time. Thus no one has received any migrate request. In this case both peers go to SYN/SENT state after sending SYN/Migrate. As the location of both peers have changed thus these messages gets lost. Both peers assume it to be due to network congestion or error. So they retransmit SYN/Migrate several times but will not get any reply. Tilak and Abu-Ghazaleh proposed that after k failures the mobile node should move to ADDRESS- RESOLVE state. In ADDRESS-RESOLVE state, mobile host contacts DNS server for the new address resolution of its peer. The value of k can be any value depending on previous congestion behaviors or it may be any static value. This scheme also takes care of losses due to congestion, errors or temporary

6 Page 6 of 7 disconnection. The DNS lookup in those cases will return the peer s old address and retransmissions will occur. Tilak and Abu-Ghazaleh in their work claims that this approach has no additional security considerations and has the same level of security as the Hari and Snoeren s scheme. Moreover it adds minimal overhead to the previous approach. But this approach has not been implemented and tested yet. 9. Conclusions and open problems: End-to-end architectures are more flexible and efficient solutions to the host mobility on Internet. They do not require changes in the network infrastructure but do require changes in the transport and higher layers of the end hosts. End-to-end architectures ensure a secure, seamless connection to an application, with a minimum overhead. Current end-to-end architectures rely on DNS updates, which force all applications to use same single naming system. Different applications have different requirements thus requiring a different naming system to expresses those requirements. Restricting these applications to a single naming system results in a significant overhead and performance degradation [17]. Moreover, DNS does not have any explicit support for mobility. More mobility specific naming systems like Intentional Naming System INS [1], Universal Plug and Play UPNP, and JINI should also be tested for location announcement in end-to-end architecture. End-to-end architecture is only designed, implemented and tested on TCP protocol. Its performance on UDP protocol is also required to be studied extensively. Tilak and Abu-Ghazaleh proposed a solution for concurrent host mobility but this approach is never implemented and tested. Only after implementation and testing of their approach we will be able to analyze it. References: [1] ADJIE-WINOTO, W., SCHWARTZ, E., BALAKRISHNAN, H., AND LILLEY, J. The design and implementation of an intentional naming system, ACM SOSP Operating System Review, Volume 34, No 5: Pg , Dec [2] DROMS, R., Dynamic Host Configuration Protocol, RFC 2131, IETF, Mar [3] EASTLAKE, D., 3 rd., Secure Domain Name System Dynamic Update, RFC 2137, IETF, Apr [4] FERGUSON, P., Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, RFC 2267, IETF, Jan [5] MALTZ, D., AND BHAGWAT, P., MSOCKS: An architecture of transport layer mobility, In Proc. IEEE In [6] MOCKAPETRIS, P., Domain Concepts and Facilities, RFC 1034, IETF, Nov [7] MOCKAPETRIS, P., Domain Names- Implementation and Specification, RFC 1035, IETF, Nov [8] MONTENEGRO, G., Reverse Tunneling for Mobile IP, RFC 2344, IETF, May [9] PERKINS, CHARLES E., AND JOHNSON, D. B., Route optimization in mobile IP, Internet Draft, IETF, O [10] PERKINS, CHARLES E., Mobile Networking Through Mobile IP, Sun Microsystems, [11] PERKINS, CHARLES. E., IP Mobility Support, RFC 2002, IETF, Oct [12] POSTEL, J., Domain Name System Structure and Delegation, RFC 1591, IETF, Mar [13] SALTZER, J., REED, D., AND CLARK, D. End-to-end arguments in system design, ACM Transactions on Computer Systems 2, 4, Nov [14] SNOEREN, Alex C., AND BALAKRISHNAN, H. An End-to-End Approach to Host Mobility, ACM/IEEE [15] SNOEREN, Alex C., BALAKRISHNAN, H., AND KAASHOEK, M. FRANS. Reconsidering Internet Mobi

7 Page 7 of 7 [16] SNOEREN, Alex C., AND BALAKRISHNAN, H. TCP Connection Migration, Internet Draft, IETF, Nov [17] SNOEREN, Alex C., BALAKRISHNAN, H., AND KAASHOEK, M. FRANS. The Migrate Approach to Internet Mobility, Proc. Student Oxygen Workshop '01, July [18] STEVEN, W. R., TCP/IP Illustrated, Volume 1: The Protocols, Addison Wesley, Reading, Massachusetts, 1 [19] THOMSON, S., AND NARTEN, T., Ipv6 stateless address autoconfiguration, RFC 2462, IETF, Dec [20] TILAK, SAMEER, AND ABU-GHAZALEH B., NAEL, An Extension to the DNS-based End-to-End Mobil [21] VIXIE, P., Dynamic Updates in the Domain Name System (DNS UPDATES), RFC 2136, IETF, Apr [1] Home/foreign agents advertise their presence via Agent Advertisement messages. Mobile host detects network change by listening these messages or by sending solicitation message to learn about the agent. [2] Registration is made secure against replay attacks. [3] Author assumes that the reader has knowledge of how a traditional TCP works