Review - An End-to-End Approach to Host Mobility

Review of An End-to-End Approach to Host Mobility
by Ivan Hernández

The paper presents an end-to-end architecture for host mobility. The
mobility support is achieved by modifying TCP and by using a host
location service (provided by DNS). The authors approach does not
require neither third-party forwarding or layer three support to
perform the migration process. This architecture is an alternative to
Mobile IP that is a layer three solution.

The only external service that requires the architecture is mobile
host location. This service is provided by DNS. Each time a host
changes its IP address, the host updates its A-record on his
corresponding DNS server. The DNS server always answers with the
associated A-record of the mobile device with the TTL field set to
zero. In this way, each time a node wants to get the IP address of
another node, the DNS will answer with the current IP address.

The authors modified TCP in several ways, which are described roughly
next.

First, if A wants to establish a migrateable TCP connection with B,
then A sends B a SYN segment with the Migrate-Permitted option; the
SYN segment takes advantage of the unused timestamp value and echo
reply fields in the TCP header, in this fields the authors add key
exchange information. If B supports TCP migration, then B will answer
with SYN/ACK that will include similar information. With these
information and with each node's sequence numbers, both ends are able
to calculate a connection validation Token that identifies uniquely
this established TCP connection. As we can see, the three way
handshake is the same, the authors only add more information in unused
TCP headers.

When A moves to a new address, it notifies B by sending a SYN packet
from its new address. The SYN packet includes the Migrate option, the
Token that identifies the previous established connection, a Request
that is a hash of several parameters used in the very first A and B
established connection process, and a reqNo that is used to check if
the request is valid in terms of the time. If the token and the
received hash are valid, then B updates the information (A's new IP
address and port) of the the matching connection.

Finally, the authors add a new state MIGRATE_WAIT and its transitions
to the TCP state machine. This new state adds "time tolerance" to a
TCP connection that was established using the Migrate-Permitted
option. The security discussion its clear and I agree with the authors
conclusion the new TCP is at least as secure as the original one.

The paper is good. I think that this is a good solution. The time
suggested by the authors does not look enough to me, when I think in
mobile IP scenarios I identify two commons: (1) Using laptop to
download a large file as I walk roaming between APs and (2) Doing a
ssh connection from from my office to a remote server and then moving
to my place, of course I want to keep my ssh connection. For (1) it
looks like it would work fine, but for (2) the proposed lifetime does
not look enough. The question is: how much is enough? Maybe there
could be a parameter used in the fixed server regarding to the type of
applications that serves.
Received on Wed Oct 18 2006 - 14:38:15 EDT