IEEE
JOURNAL
ON SELECTED
AREAS
IN COMMUNICATIONS,
VOL.
13,
NO.
5.
JUNE
1995
839
A
Mobile Host Protocol Supporting
Route Optimization and Authentication
Andrew Myles,
David
B.
Johnson,
and
Charles Perkins,
Member,
IEEE
Abstract- Host mobility is becoming an important issue due
to the recent proliferation of notebook and palmtop computers,
the development of wireless network interfaces, and the growth
in global internetworking. This paper describes the design and
implementation of a mobile host protocol, called the Internet
Mobile Host Protocol (IMHP), that is compatible with the TCPDP
protocol suite, and allows a mobile host to move around the Inter-
net without changing its identity. In particular, IMHP provides
host mobility over both the local and wide area, while remaining
transparent to the user and to other hosts communicating with
the mobile host. IMHP features route optimization and integrated
authentication of all management packets. Route optimization
allows a node to cache the location of a mobile host and to send
future packets directly to that mobile host. By authenticating
all management packets, IMHP guards against possible attacks
on packet routing to mobile hosts, including the interception
or
redirection of arbitrary packets within the network.
A
simple new
authentication mechanism is introduced that preserves the level
of security found in the Internet today, while accommodating the
transition to stronger authentication based on public key cryptog-
raphy
or
shared keys that may either be manually administered
or provided by a future Internet key management protocol.
I. INTRODUCTION
N
recent years, computers have become increasingly com-
I
pact and very powerful. At the same time, connectivity to
the global network is becoming widespread, and with the re-
cent introductions of commercial wireless network interfaces,
users now have a real opportunity for continuous network
connectivity wherever they may happen to be working.
Unfortunately, existing internetwork protocols do not easily
accommodate mobile hosts. Host movement today, even if
only between local subnets, involves slow, manual, error prone
host and network reconfiguration procedures that a typical user
does not have the skills or desire to carry out. Moreover,
even when this movement process is successfully performed,
the mobile host loses its former identity in terms of its host
network address, and any network applications on the mobile
host and on other hosts communicating with it must usually
be restarted.
Manuscript received April 29, 1994; revised September 29, 1994. This
paper
was presented in part at INET’94, the Annual Conference of the
Internet Society, held in conjunction with the 5th Joint European Networking
Conference, in Prague, Czech Republic, in
June
1994.
A.
Myles is with the Department of Electronics, Macquarie University 2109,
Sydney, NSW, Australia.
D.
B.
Johnson is with the Computer Science Department, Carnegie Mellon
University. Pittsburgh,
PA
15213
USA.
C.
Perkins is with the IBM T. J. Watson Research Center, Hawthorne, NY
10532
USA.
IEEE Log Number 9409624.
A number of mobile host protocol proposals that are com-
patible with the TCP/IP protocol suite have been proposed
[4]-[81, [12]-[14], 1191-[22]. These proposals each retain the
home
IP
address of a mobile host for use in identifying
it at the network level, but also in some way associate a
second IP address with the mobile host to indicate the mobile
host’s current location. Each of the proposals has a number of
advantages and disadvantages, some of which are discussed in
[lo], [l
11.
Proposals have also been made for supporting host
mobility in an
OS1
environment [2].
Many
of
these mobile host protocols provide some form of
route optimization that allows other nodes (hosts
or
routers)
to learn the current location of a mobile host, either from
management packets
or
from an IP option attached to data
packets. Nodes learning the location of a mobile host in this
way can cache this location and then send later packets for
the mobile host directly to that location. However, none of
these proposals (except [4],
[5])
provide a mechanism for the
node learning a mobile host’s current location to authenticate
it. The result is that a malicious host anywhere in the Internet
could easily send forged management or data packets in order
to
intercept or redirect packets destined to a mobile host. In
today’s Internet, only hosts connected to the normal packet
routing path can cause similar disruption
111.
The only previous mobile host protocol proposal that pro-
vides for extensions to guard against this type of attack
141, [5] compromises its wide area operation to maintain its
authentication mechanisms. The protocol does not support
route optimization in the wide area, but rather normally forces
all packets addressed to a mobile host connected away from
its home network to pass through the mobile host’s home
network before being forwarded to the mobile host at its
current location. This nonoptimal routing results in reduced
pegormance
transparent-y
to the user as a result of increased
network overhead for packets sent to the mobile host.
This paper describes the design and implementation of a
new mobile host protocol, called the Internet Mobile Host
Protocol (IMHP), that features both route optimization and
integrated authentication of all management packets. IMHP
operates equally well in both the local and the wide area,
and provides
pe$ormance transparenc-y
and
operational trans-
parency
to the user. IMHP introduces an optional new mech-
anism for providing simple authentication of management
packets that preserves the level of security found in today’s
Internet [l], and is designed to accommodate stronger au-
thentication based on public key cryptography
or
on shared
keys that may either be manually administered
or
provided
0733-8716/95$04.00
0
1995 IEEE
840
IEEE
JOURNAL
ON
SELECTED
AREAS
IN
COMMUNICATIONS,
VOL.
13,
NO.
5,
JUNE
1995
by a future Internet key management protocol. IMHP thus
provides effective authentication today, while providing a good
migration path to stronger authentication when available. A
more detailed specification of IMHP is found in
[9].
Section 11 of this paper describes the necessary IMHP
infrastructure. Section
111
discusses the IMHP authentication
procedures and their operation in the protocol. In Section IV,
the rules used by each node when forwarding packets are
presented, and in Section V, the means by which nodes learn
and cache the location of mobile hosts are described. Section
VI discusses additional features
of
the protocol, and Section
VI1 details a number of examples of the operation of the
protocol. Section VI11 describes an implementation of IMHP,
and Section IX presents conclusions.
11. IMHP INFRASTRUCTURE
The IMHP architecture includes four functional entities:
mo-
bile hosts, local agents, cache agents,
and
home agents.
This
section defines each entity and describes its basic operation.
Although defined separately, the functionality of several of
these entities may be combined within a single node.
A.
Mobile Host
A
mobile host
is a normal host with additional software that
allows it to move through the network in a manner transparent
to the user and to software above the network routing layer
within the host. A mobile host is assigned a constant, unique
home address
that belongs to a
home network
in the same
way as any other host.
Correspondent hosts
(either mobile
or
stationary) use the home address of a mobile host in sending
packets to the mobile host regardless of the mobile host’s
current location.
B.
Local Agent
When a mobile host connects to the network, it must be able
to determine that it has moved to a new network and must
identify a
local agent
connected to the new local network
with which to register. The first function may be performed
with network data link layer support, if available, or may use
an
advertisement and solicitation protocol
that is defined by
IMHP. Registration is performed using a
registration protocol
that is defined by IMHP.
Each local agent maintains a
visitor list
identifying all
mobile hosts currently registered with this local agent. A
local agent uses the visitor list to forward packets it receives
addressed to these mobile hosts to the local network to which
the mobile host is connected. A local agent times out the visitor
list entry for a mobile host after a lifetime period negotiated
with the mobile host during the registration process; once a
visitor list entry times out, it is deleted by the local agent. In
order to maintain unintermpted service from its current local
agent, a mobile host must reregister with its local agent within
this lifetime period.
A local agent, during the registration process, provides the
mobile host with a
care-of address,
which is generally the local
agent’s own address, that defines the location of the mobile
host. The combination of a mobile host’s home address and
care-of address is known as a
binding.
If the care-of address
and home address elements of a binding are the same, then the
mobile host is assumed to be connected to its home network.
Whenever a mobile host registers with a local agent, the
mobile host must arrange to reliably notify any previous local
agents that might still have a visitor list entry for it that
this mobile host has moved. Each previous local agent uses
this notification to delete any visitor list entry held for the
mobile host, ensuring that the local agent does not continue
to forward packets to a local network when the mobile host
has moved elsewhere in the network. The notification to a
previoiis local agent must be periodically retransmitted (with
a back-off mechanism) either until it is acknowledged or until
the previous local agent would have timed out the visitor list
entry it held for the mobile host.
A mobile host will typically use the local agent with which
it is currently registered as a default router. However,
‘f
the
mobile host is connected to a local network, such as its
home network, for which it is able to obtain better routing
information, it may use any local router.
C.
Cache Agent
A
cache agent
is the functionality within any node that
maintains a
location cache
containing the binding of one or
more mobile hosts that it has learned through IMHP’s
binding
management protocol.
When sending any packet, if a cache
agent has a binding in its location cache for the destination
address of the packet, the cache agent routes the packet directly
to that mobile host at its current location by
tunneling
the
packet to the mobile host’s care-of address as indicated in
the cached binding. Otherwise, the cache agent sends the
packet using normal Internet routing, causing the packet to
be delivered eventually to the mobile host’s home network.
Although in principle, any tunneling protocol could be used,
an IMHP tunneling protocol has been designed to minimize the
processing and space overhead added to each packet tunneled.
To tunnel a packet, a small IMHP tunneling header is added to
the packet between the packet’s IP header and any transport-
level header in the packet, such as TCP or UDP, as illustrated
in Fig.
1.
The IP header of the packet is modified
so
that the
packet appears to be a normal IP packet addressed from the
cache agent to the mobile host’s current local agent, and the
original values of the modified IP header fields are copied into
the new IMHP tunneling header. The packet then uses only
normal IP routing to reach the local agent, which removes
the added header and restores the packet’s original IP header
before delivering the packet to the mobile host. The IMHP
tunneling protocol adds only
8
or 12 bytes of overhead to
each packet being tunneled.
A cache agent times out a location cache entry and deletes it
after a lifetime specified by the binding management protocol
when
the
location cache entry is established or according to
a local cache use policy. If a cache agent wants to provide
continued service for packets addressed to a particular mobile
host, it may attempt to reconfirm the mobile host’s binding
and thus update the corresponding location cache entry before
the location cache entry times out. A cache agent also deletes
MYLES
et
al.:
A
MOBILE
HOST PROTOCOL
84
1
I
IPHeader
I
.->
Transport
Header
LA\
Transport
Data
I
“’
I\
IMHP
Header
Transport
Header
Transport
Data
Fig.
1.
Adding
the
IMHP
tunneling
header
to
a
packet.
a location cache entry if it receives a new binding for that
mobile host indicating that its care-of address is the same as
the mobile host’s home address, meaning that it is connected
normally to its home network. Such a location cache entry
need not be stored, since this is the default routing for packets
for that mobile host in the absence of any binding.
Any node that wants to optimize its own communication
with mobile hosts should function as a cache agent, allowing
it to route packets directly to each correspondent mobile host’s
current location. Many local agents will also be capable of
functioning as cache agents. If such a local agent is notified
that a mobile host it previously served has moved, then
the local agent may, subject to certain authentication related
restrictions discussed later, create a location cache entry for
the mobile host indicating the new binding, after deleting
the corresponding visitor list entry. This feature ensures fast
redirection of packets to the mobile host’s current location
when a mobile host moves.
D. Home Agent
Each mobile host must have a
home agent
that is attached
to its home network. A home agent maintains a
home
list
identifying all mobile hosts that it is configured to serve. The
home agent must also serve as a cache agent for at least these
mobile hosts. It may serve as a local agent for these or other
mobile hosts as well.
When registering with a new local agent, a mobile host
must also register with its home agent,
so
that the home agent
always knows the current binding of the mobile hosts it serves.
The home agent normally creates a location cache entry for
the mobile host, with a binding indicating the mobile host’s
current care-of address given in the registration. However, if
the mobile host’s home agent is also functioning as a local
agent, the mobile host may register directly with its home
agent. In this case, if the home agent is a router connected to
more than one network, and if the mobile host is registering
on a network other than the mobile host’s home network, then
the home agent (as a local agent) creates only a visitor list
entry for the mobile host. On the other hand, if the mobile
host is registering on its home network with its home agent,
then no location cache entry or visitor list entry is created; the
mobile host is then said to be
at home.
Any location cache entry
or
visitor list entry that is created
is timed out after a lifetime negotiated by the mobile host and
its home agent. The mobile host thus must reregister with its
home agent before the lifetime expires if it wants to maintain
continued service from its home agent. Typically, the home
agent registration lifetime will be greater than the local agent
registration lifetime, and
so
fewer reregistrations are required
with the home agent than with the local agent. The home agent
assumes that the mobile host is at home if it does not have a
valid binding for the mobile host. This will happen if either
its visitor list entry or location cache entry for the mobile host
times out before the mobile host reregisters.
If a mobile host is registered away from home, then its home
agent must arrange to intercept (for example, through proxy
ARP
[
171)
any packets on the home network that are addressed
to the mobile host’s home address, including packets that have
been forwarded to the home network from elsewhere in the
network using normal routing algorithms. If the mobile host
is registered directly with its home agent (as a local agent) on
a local network other than its home network (the home agent
has a visitor list entry for the mobile host), then the home
agent delivers each intercepted packet to the mobile host on
the local network indicated by the visitor list entry. Otherwise,
the home agent tunnels each intercepted packet
to
the mobile
host’s current care-of address using the location cache entry it
holds (as a cache agent) for the mobile host.
111.
AUTHENTICATION
A limitation of previous mobile host protocol proposals is
that they do not provide a method for nodes to authenticate a
binding that they receive for a mobile host. Without authen-
tication, providing route optimization exposes the network to
significant security risks.
A
malicious node could send forged
management packets, giving incorrect information on a mobile
host’s location, and could thus misdirect or intercept packets
addressed to that mobile host. The only alternative to this risk
among previous mobile host protocols
[4],
[5]
has been to force
all packets addressed to a mobile host to be routed through
the mobile host’s home network. Such an alternative reduces
performance transparency and places additional overhead on
the network.
Adding authentication features to a mobile host protocol
supporting route optimization is complicated by the need for
any node to be able to authenticate a binding received for
any mobile host. In general, such authentication requires a
key distribution infrastructure which, in the Internet, is par-
ticularly difficult to provide since each organization manages
its own nodes, including its own mobile hosts. The required
key distribution infrastructure does not generally exist in the
Internet, and due to patent and international export restrictions,
may not exist throughout the Internet for some time.
IMHP is defined to make use of strong authentication based
on such an infrastructure or based on manually configured
keys, but also introduces an optional set of simple new
authentication procedures that can be used when no keys are
available, yet which preserve the level of security found in
today’s Internet
[
11.
In the current Internet, security attacks
based on the misuse of ARP
[
151
or
ICMP
Redirect messages
[16],
for example, allow any node connected to one of the
physical networks on the normal routing path of a packet
to intercept
or
redirect that packet, but such attacks are not
possible for nodes not on this path; nodes elsewhere in the
842
IEEE JOURN.
Strongly authenticated request
message based
on
a
shared
secret
>
Homeagent
Mobile
n
63l
Svonelv
authenticated
=DIY
_.
..
message based
on
a shared secret
(a)
Notification
from
another node that
this node needs to
acquire binding
Request for binding with
random authenticator
>
Homeagent
I
Node
Reply including binding
(b)
Establish shared secret Local agent
with local agent
Mobile
hosa
*FE2
After moving, strongly aulhenticated
*
notification based
on
shared secret
Previous local
agent
(c)
Fig.
2.
Simple authentication procedures. (a) Home agentlmobile host au-
thentication.
(b)
General binding authentication. (c) Previous local agent
authentication.
Internet can neither interfere with the packet nor change the
routing within the Internet to place themselves on the normal
routing path between this source and destination. Based on this
assumption, IMHP uses secure cryptographic checksums and a
challenge-response mechanism using one-time authenticators
to maximize the level of authentication provided when no keys
are
available. Although these simple authentication procedures
are
open to some possible attacks, only nodes already in a
position to utilize the existing security holes in TCP/IP can
utilize these attacks.
This section describes the authentication procedures defined
in IMHP and discusses the extension of these procedures to
stronger authentication when the necessary infrastructure is
available. Note that IMHP makes no attempt to address end
to end security or privacy issues, nor does it address the
additional privacy issues related to the use of wireless links.
A. Mobile Host to Home Agent Authentication
When a mobile host in a home agent’s home list attempts
to register, the home agent must be able to authenticate the
binding it receives for the mobile host. Registration with the
home agent is a particularly important transaction, because
the home agent in the IMHP architecture must always know
the current binding of each mobile hosts in its home list.
Similarly, a mobile host must be able to authenticate a reply
or other management packet it receives from its home agent.
This authentication is achieved in IMHP by including an
authenticator based on a shared secret in all management
protocol messages between a mobile host and its home agent
(Fig. 2(a)).
This shared secret allows a strong degree of authentication
between the mobile host and its home agent. The base level
AL
ON
SELECTED
AREAS IN COMMUNICATIONS,
VOL.
13,
NO.
5,
JUNE
1995
of authentication defined by IMHP in this case involves per-
forming a checksum of the important fields in the registration
packet (or reply) and the shared secret, using the MD5 one-
way cryptographic hash function
[
181.
The resulting checksum
is
sent as the authenticator in registration messages between
the mobile host and its home agent. The possibility of replay
attacks is minimized by including a monotonically increasing
sequence number in registration and reply packets.
Administration of a shared secret between a mobile host and
its home agent does not require any network key management
infrastructure, since the mobile host and its home agent are
both generally owned by the same organization (they are both
assigned home addresses within the same IP network owned
by that organization). The shared secret may be set manually,
for example, when the mobile host is at home, at the same
time as other configuration of the mobile host and home agent
is being performed.
B.
General Authentication Procedures
In general, a node will not share a secret with any particular
mobile host or with the mobile host’s home agent, and thus will
not be able to authenticate IMHP management messages in the
same way as a mobile host and the mobile host’s home agent
can authenticate management messages between themselves.
However, such a node can still obtain an authenticated
binding for a mobile host using the simple authentication
procedure defined by IMHP, under the assumptions of today’s
level of Internet security. To obtain an authenticated binding
in this way, the node sends a request for the mobile host’s
binding to the mobile host or to the mobile host’s home agent,
and includes in the request a random number to be used as an
authenticator. If the reply to the binding request contains the
same authenticator value, the node may believe the binding
contained in the reply (Fig. 2(b)), and may store the binding
in its location cache for future use. This random number acts
as a one-time disclosing authenticator and is used to guard
against a forged reply being sent by some attacker shortly
after the request is sent. Only nodes connected to one of the
physical networks on the normal routing path taken by the
request or reply packet can intercept one of these packets and
thus learn the correct authenticator value necessary to forge a
reply. Since nodes along these paths must already be implicitly
trusted in the current Internet, no new attacks are afforded by
this simple authentication mechanism. Other nodes not on the
message path are not able to send a successful forged reply
because they cannot discover the correct authenticator value.
Any node will normally not know the address of an arbitrary
mobile host’s home agent,
so
the IMHP management protocol
provides a method by which a packet may be forwarded only
to the mobile host’s home agent or to the mobile host itself if
it is at home. By setting a
routejug
in a management packet
addressed to a mobile host, IMHP entities may be instructed
to use only normal
IP
routing in the forwarding of that packet.
The management packet thus may not be forwarded using
location cache or visitor list entries in intermediate nodes, and
the packet will therefore reach the mobile host’s home network
(and will be intercepted by the home agent if the mobile host
MYLES
et
al.: A
MOBILE
HOST
PROTOCOL
843
is not at home). If the route flag is set in a packet intercepted
by the home agent, the home agent processes the packet on
behalf of the mobile host.
If a suitable key management infrastructure is available or
a manual key distribution system is used, then a mobile host’s
binding may be strongly authenticated. The node requesting
the binding simply has to confirm that the binding it receives
in reply to its request is signed by either a mobile host or its
home agent using a cryptographically strong digital signature
such as one based on keyed MD5. If the binding is signed by
the mobile host’s home agent then the node must also be able
to confirm the identity of the mobile host’s home agent in a
strongly authenticated manner, or the home agent must sign
the binding on behalf of the mobile host.
C.
Authenticating a Visitor List
Entry
A cache agent establishes a location cache entry for a mobile
host only when it obtains an authenticated binding for the host.
Thus, a location cache entry for a mobile host may always be
used to forward packets to that host. In contrast, a local agent
may create a visitor list entry for a mobile host as soon as the
mobile host registers with it. However, a visitor list entry may
not be used to forward packets unless they were tunneled to
the local agent, until after the local agent has authenticated the
identity of the registered mobile host. This restriction reduces
the possibility of packets being delivered incorrectly by a
local agent to a malicious host. An unauthenticated visitor
list entry may be used to forward packets tunneled to the local
agent, as the source of the tunnel may be assumed to have an
authenticated binding for the mobile host, since otherwise the
source would not have tunneled the packet. This mechanism
ensures that existing connections may continue, still using a
close to optimal route, as soon as a mobile host registers with
a new local agent and notifies its previous local agents.
A
local agent authenticates a visitor list entry by confirming
that the mobile host’s home agent has a binding indicating
that the mobile host is registered with this local agent. This
authentication can be done using the mechanisms previously
described. When the lifetime indicated with this binding
expires, the visitor list entry must be reauthenticated. The
visitor list entry may also be authenticated as part of the regis-
tration process by combining the same type of authentication
mechanism into the registration request and reply messages as
is used in the general procedure for obtaining an authenticated
binding.
The assumption that a local agent may use an unauthenti-
cated visitor list entry to forward a tunneled packet introduces
a minor security risk. Suppose a cache agent has a location
cache entry that indicates that a mobile host is registered with
a particular local agent but, in fact, the mobile host is located
elsewhere or has disappeared from the network entirely. Also,
assume that a malicious host pretends to be the mobile host
and registers with the local agent. Any packets the cache agent
tunnels to the local agent will be forwarded to the malicious
host. Fortunately, this risk is limited in duration, in the worst
case, by the lifetime of the location cache entry in the cache
agent.
D.
Previous Local Agent Authentication
When a mobile host registers with a new local agent, the
mobile host arranges that each of its previous local agents that
might still have a visitor list entry for the mobile host are noti-
fied of the movement. Each previous local agent can authenti-
cate a received notification using the same general authentica-
tion procedure previously described, which generally requires
a management packet exchange to be carried out with the
mobile host’s home agent. If the home network is far away or
only accessible by a slow or unreliable link, the authentication
delay might reduce the performance transparency to the user.
IMHP thus defines an alternative mechanism that may be
used for fast simple authentication of notifications to previous
local agents. When a mobile host registers with a local agent,
the mobile host provides a random number
to
the local agent
for use as an authenticator, thus essentially establishing a
shared secret with this local agent for the duration of this
registration. Based on this shared secret, the mobile host later
uses a strong authentication function, such as keyed MD5,
to authenticate any notification it sends to that local agent
indicating that the mobile host has moved. The local agent
authenticates the notification and any binding contained in it
in the same way as other IMHP management messages using
strong authentication (Fig. 2(c)). The establishment of the
shared secret is subject to attack from other nodes connected
to the same physical network as the mobile host during
registration, but such nodes can already exploit similar attacks
in the current Internet. Whereas the shared secret is established
using the assumptions of simple authentication over the single
hop between the mobile host and its local agent, the longer
path between the mobile host and its previous local agent is
able to use strong authentication.
An authenticated notification is used to delete a visitor list
entry that the previous local agent holds for a mobile host.
It may also be used to create a location cache entry for the
mobile host if the local agent is also capable of functioning
as a cache agent. However, a notification to a previous local
agent should only be used to create a location cache entry if
the current visitor list entry has been authenticated. A location
cache entry created in this way must be marked to time out
after a period no greater than timeout on the original visitor list
entry to stop a malicious host on the local network that gained
access to the temporary shared secret forcing the creation of
a long lasting false location cache entry. The potential risk is
thus limited to be no worse than the effect of any malicious
host using the today’s Internet protocols.
As with other IMHP authentication procedures, if a suitable
key management infrastructure is available or a manual key
distribution system is used, then a mobile host’s notification to
its previous local agent may be strongly authenticated (using
no assumptions of simple authentication). The mobile host
receiving such a notification simply has to confirm that
the
binding it receives is signed by the mobile host using a strong
authentication function such as keyed
MD5.
E.
Transition
to
Strong Authentication
It is important that a simple authentication mechanism
already in existence when strong authentication mechanisms