End-to-end approach to host mobility

1. End-to-end approach to host mobility By Alex C. Snoren and Hari Balakrishnan

2. Overview • Why end-to-end approach is better for handling mobility? • Proposed end-to-end architecture for supporting mobility

3. Why end-to-end approach is better for handling mobility? • Advantages and disadvantages of network layer based solution to support mobility (i.e., Mobile IP) • Does not require any changes to the higher layers of the Internet protocol stack • It does require changing the IP substrate • It has the associated problem of triangle routing and possibly quadrilateral routing. • It also requires an authentication protocol so that connections are not hijacked by a malicious third party • This approach to handling mobility is costly, complex and can lead to performance degradation

4. Why end-to-end approach is better for handling mobility? • End-to-end approach takes advantage of the widely deployed domain name system (DNS) and its ability to support secure, dynamic updates for locating mobile hosts as they change their network attachment point • Since most applications resolve host names to an IP address at the beginning of a transaction or connection, this approach is viable for initiating new sessions with MHs • In the end-to-end approach, when a host changes its network attachment point, it sends a secure DNS update to one of the name servers in the home domain updating its current location. The name-to-address mappings for these hosts are uncacheable by other domains, so stale bindings are eliminated. • Good end-to-end architecture can help support many classes of applications such as • Those applications where other hosts originate connections to a mobile host which can benefit from both host location and handoff support (e.g., mobile webserver, mobile telephony) • Those applications where the MH originates all connections which do not require host location services but can benefit from handoff support (e.g., mail readers, web browsers) • Those applications where an application-level retry suffices when the network address changes unexpectedly during a short transaction.

5. Why end-to-end approach is … • Functionality is often best implemented in a higher layer at an end system where it can be done according to application’s specific requirements (Saltzer et al. ACM TOCS, Nov. 1984) • It enables higher layers like TCP and HTTP to learn about mobility and adapt to it (For example, after a network route change, it is a good idea to restart TCP transmissions form slow start or window-halving since the bottleneck might have changed) • It benefits mobility aware applications • End-to-end enhancements such as various TCP options (SACK, MTU path discovery, etc) often meet with less resistance for widespread deployment than changes to the IP substrate. • Unlike Mobile IP, this scheme prevents triangle routing. • Experiments show that end-to-end latency for active connections is better than standard mobile IP and similar to mobile IP with route optimization

6. Challenges in supporting mobility using end-to-end approach • Ability to support continuous communication during periods of mobility without modifying the IP substrate is a more challenging problem • Two communicating peers must securely negotiate a change in the underlying network-layer IP address and then seamlessly continue communication • 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

7. Proposed architecture • The proposed end-to-end architecture for handling mobility has three components • Addressing • Mobile host location • Connection migration

8. Proposed architecture: Addressing • It assumes that the mobile hosts do not change IP addresses more than a few times a minute. • Like Mobile IP, the issues of obtaining an IP address in a foreign domain for locating and seamlessly communicating with mobile host. • Any suitable mechanism for address allocation such as manual assignment, DHCP, or any auto configuration protocol. • 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. • IP address is usually used for specifying security policies at firewalls. So, this approach does not violate this security model and hence unlike Mobile IP, this does not require reverse tunneling.

9. Proposed architecture: Mobile host location • When a mobile host moves to a new location and obtains a new IP address • As a client, when it opens a new connection to a correspondent host, no special location task needs to be performed; just use the existing DNS lookup mechanism • If it has moved to another attachment point during a connection, a new address would be obtained and the current connection would continue seamlessly via a secure negotiation with the communicating peer • If the mobile host were always a client, then no updates need to be made to any third party such as a home agent or DNS. • If the mobile host is a server , then the DNS is used to provide a level of indirection between host’s current location and an invariant end-point identifier. • In mobile IP, a host’s home address is the invariant, but in this approach we can use the DNS name as an invariant. Host name look up is ubiquitously done by most applications that originate communication with a network host and use this name as an invariant.

10. Proposed architecture: Mobile host location… • So, when a mobile host (which acts as a server) changes its point of attachment, it must detect this and change this hostname-to-address mapping in the DNS. This can be done by available secure DNS update protocol (RFCs 2136, 2137) • To prevent the name resolvers from using stale name-mappings from their cache, the TTL field of the DNS A-record is set to 0 for a mobile host. This prevents a name resolver from caching name-mappings corresponding to a mobile host. • A problem with this approach: What happens when a mobile host moves between when a correspondent host receives the result of its DNS query and when it initiates a TCP connection? • Assuming that the MH updates its DNS entry immediately upon reconnection, chances of this happening is small but not 0.

11. Proposed architecture: Mobile host connection migration • A TCP connection is uniquely identified by a 4-tuple (src address, src port, dest address, dest port). • So, packets addressed to a different address, even if successfully delivered, must not be multiplexed to a connection established from a different address • Similarly, packets from a new address are also not associated with a connection established from a previous address

12. Mobile host connection migration… • A new Migrate TCP option is included in the SYN segments that identifies a SYN packet as part of a previously established connection • The Migrate option contains a token that identifies the previously established connection with the same destination (address, port) pair. This token is negotiated during initial connection establishment through the use of Migrate-permitted option. • After successful token negotiation, a connection may be identified by the traditional 4-tuple or a new (src address, src port, token) triple on each host.

13. Security issues • Denial of service (DoS) attacks • SYN flooding is the common form of DoS • Most TCP implementations take care of this by avoiding consumption of unnecessary resources unless three handshake takes place • Connection hijacking • Possibility for this is limited • Key Security • The connection key used is negotiated via Elliptic curve Diffe-Helman protocol and hence makes it difficult to guess for hosts. To guess a key, one has to constantly generate migrate SYNs with guessed keys until gets an ack. It requires 263 SYN packets to successful guess in the worst case. • IPsec • When used in conjunction with IPsec it may not work • This is because IP security associations (SAs) are based on the IP address • When a connection migrates, a new security association with the new IP address must be established. If the new SA conflicts with the existing policy, the connection is dropped

14. Implementation and evaluation and enhancement • The architecture was implemented in Linux and evaluated • Enhancement • Issuing three dup Acks immediately after migrate request can help triggering fast-retransmit which can help increase throughput

15. Deployment issues • Connection migration protocol can be generalized to other UDP-based protocols without much difficulty • A disadvantage is both peers cannot move simultaneously • Address caching • The class of applications that store the IP address within the application won’t work • Older name servers enforce a local TTL minimum of 5 minutes. This could cause problem because the architecture requires it to be set to 0 for mobile hosts which act as servers.