Review: End-to-End Approach to Host Mobility

From: Robert Danek <rdanek_at_sympatico.ca>
Date: Tue, 17 Oct 2006 23:15:02 -0400

Paper: An End-To-End Approach to Host Mobility

Name: Robert Danek.
Course: CS2209, Fall '06.

    More and more mobile hosts are participating in the internet. As a
mobile host moves, its physical point of attachment to the internet
changes. This poses a problem when a connection exists between two hosts
(e.g., a TCP connection), and the appearance of a seamless connection
needs to be maintained as one or both of the hosts moves. Past
solutions, such as Mobile IP, have attacked the problem at the network
layer. Mobile IP has a number of drawbacks, including the necessity of a
"home agent" running in the mobile host's home network, and changing the
IP layer infrastructure. The paper "An End-To-End Approach To Host
Mobility" proposes an alternate means for connection migration that
involves changing the transport layer protocol on the end-hosts, and
doesn't require a third-party "home agent" to be running.

    The authors' mechanism can be described in two parts: the way in
which mobile hosts are located, and the way TCP connection migration works.

    In order to locate a mobile host, hosts use DNS. Whenever the
attachment point of a mobile host changes, it needs to change its
associated mapping in DNS. In order to avoid stale mappings, any updates
are accompanied by a Time-To-Live (TTL) parameter of 0, so that the DNS
entry is uncacheable.

    TCP connection migration works by adding a Migrate Permitted option
inside the SYN packets that are exchanged during initial connection
establishment. As part of the exchange, a secure token can be negotiated
that will identify the connection and later be used if one of the hosts
becomes mobile and needs to migrate the connection. When a host does
move, it initiates the migration by sending a MIGRATE SYN packet that
contains the previously negotiated token.

    The authors go on to describe a number of security issues, including
denial of service, connection hijacking, and key security. The migrate
TCP option that is introduced either does not make dealing with these
issues any more problematic than the situation already is with regular
TCP, or it is not vulnerable to these problems.

    An implementation within Linux is detailed, along with some
experiments. The experiments showed that migration can be done fairly
quickly, and that any packets lost during migration will eventually be
retransmitted.

    Though it's fairly self-evident, the authors could have made a point
of saying that their migration mechanism only makes sense for long-lived
flows. For example, opening HTTP connections using the migrate-permitted
option for downloading relatively small web pages doesn't really make
sense. The authors did detail a number of other associated issues,
though. This includes the inability of their mechanism to handle both
end-hosts moving simultaneously, and staleness issues that occur when
applications cache ip addresses.
Received on Tue Oct 17 2006 - 23:15:14 EDT

This archive was generated by hypermail 2.2.0 : Wed Oct 18 2006 - 02:52:40 EDT