Review: TCP migration

From: Di Niu <dniu_at_eecg.toronto.edu>
Date: Wed, 18 Oct 2006 23:05:17 -0400

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

Reviewer: Di Niu

While this paper is by no means extremely exciting in my view, the
work done here is foundational, important and complete. Before this
work, the most well-known solution to Internet host mobility is
Mobile IP implemented in the network layer. Mobile IP deploys a home
agent that intercepts packets destined for a host currently away from
its home network, and delivers it to the mobile host via a foreign
network. However, in order to reduce cost and to provide better
service differentiation, the paper proposes TCP migration, an end-to-
end architecture for Internet host mobility using dynamic updates to
the DNS to track host location. In a very high level, the wisdom of
TCP migration is that it goes back to the end-to-end argument, which
observes that functionality is often better implemented in a higher
layer. Because unlike Mobile-IP, TCP migration modifies transport
protocols at the end hosts without changing the IP substrate, it
achieves significant flexibility and is adaptive to different
applications and mobility modes.

The architecture of TCP migration consists of three important
components: addressing, mobile host location, and connection
migration. While the host location service is provided by DNS, any
other control is managed by end-hosts themselves. Addressing is
separated from location, and any suitable mechanism for address
allocation may be employed such as Dynamic Host Configuration
Protocol (DHCP).

As far as we are concerned with locating a mobile host, the paper
discusses about two cases. One is when a mobile host is always a
client, the other is when it is a mobile server. For mobile servers,
which is the major concern in practice, the paper uses DNS to provide
a level of indirection between a host's current location and an
invariant end-point identifier. The nice thing for using the DNS name
as the invariant is that a readily achievable technology, namely DNS
lookup, could be utilized to replace the routing between home and
foreign agents in Mobile IP. Specifically, DNS lookup can be done by
using a user-level daemon and the secure DNS update protocol.
Furthermore, in order to avoid a stale mapping in DNS, time-to-live
(TTL) field for the A-record of the name of the mobile host is set to
small-to-zero values.

TCP connection migration is a key component in this new end-to-end
approach to host mobility. The paper proposes a migrate option that
contains a token identifying a perviously established connection on
the same destination <address, port> pair. The migrate TCP option is
included in SYN segments. A mobile host can restart a previously-
established TCP connection from a new address by sending a special
Migrate SYN packet that contains this token. A TCP migration is
performed in the following way. A connection is started through three-
way handshake with two SYN messages and one ACK message. When the
mobile host moves to a new address, it notifies the fixed server by
sending a SYN. This SYN includes migrate option which contains the
connection token as part of migration request. The sequence number of
this Migrate SYN is the same as the last byte of transmitted data.
And the server responds, also using the sequence number of its last
transmitted byte of data. The ACK, however, is from the same sequence
space as the previous connection. As migrate-permitted option is
concerned, it comes in two variants-the insecure version, of length
3, and the secure version, with length 20. The secure variant of the
Migrate-Permitted option also requires the use of the Timestamp
option in order to store up to 200 bits of ECDH keying material.
SHA-1 is also adopted to compute a connection validation token.

The paper further discussed about security issues. This is a good
supplement, which makes the work complete. Several kinds of security
concerns are analyzed. It is shown that none of them poses threat to
TCP migration. Denial of Service (DOS) is not a problem. This is
because, if a RST message is generated if either the token or the
request is invalid, an attacker has no way to identify when it has
found a valid token. Connection hijacking is not a problem either,
because the window of opportunity when the previous connection token
can be used is quite small. Moreover, it is almost impossible to
guess the key as the Migrate option is negotiated via Elliptic Curve
Diffie-Hellman. The implementation of this TCP migration architecture
was done in the Linux 2.2.15 kernel, using Bind 8.2.2-P3 as the name
server for mobile hosts.

Although the work done in this paper is certainly foundational, I
don't i find it quite exciting, just because it is too complete. The
paper tries to exhaust the whole spectrum of this newly proposed TCP
migration. While this is obviously impossible, the paper came with a
cost of being extremely hairy at some point (e.g., section 4.4 and
4.5).
Received on Wed Oct 18 2006 - 23:06:42 EDT

This archive was generated by hypermail 2.2.0 : Thu Oct 19 2006 - 10:18:52 EDT