A Mobile Host Protocol Supporting Route Optimization and Authentication:
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 TCP/IP protocol
suite, and allows a mobile host to move around the Internet 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 cryptography or shared keys that
may either be manually administered or provided by a future Internet key management protocol.
1. Introduction
In recent years, computers have become increasingly compact and very powerful. At the same time,
connectivity to the global network is becoming widespread, and with the recent introductions of commercial wireless network interfaces, users nowhave 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.
A number of mobile host protocol proposals that are compatible with the TCP/IP protocol suite have
been proposed [1, 2, 3, 4, 5, 6, 7, 8, 9, 16, 19, 20]. 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 [10, 11]. Proposals have also been made for supporting host mobility in an OSI environment [12].
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 [6, 7]) 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 [18].
The only previous mobile host protocol proposal that provides for extensions to guard against this type of attack [6, 7] 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 non-optimal routing results in reduced
performance transparency 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
performance transparency and operational transparency to the user. IMHP introduces an optional new
mechanism for providing simple authentication of management packets that preserves the level of security found in today’s Internet [18], and is designed to accommodate stronger authentication based on public key cryptography or on shared keys that may either be manually administered or provided 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 [15].
Section 2 of this paper describes the necessary IMHP infrastructure. Section 3 discusses the IMHP
authentication procedures and their operation in the protocol. In Section 4, the rules used by each node when forwarding packets are presented, and in Section 5, the means by which nodes learn and cache the location of mobile hosts are described. Section 6 discusses additional features of the protocol, and Section 7 details a number of examples of the operation of the protocol. Section 8 describes an implementation of IMHP, and Section 9 presents conclusions.
2. IMHP Infrastructure
The IMHP architecture includes four functional entities: mobile 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.
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.
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 uninterrupted service from its current local agent, a mobile host must re-register 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 previous 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, if 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.
.
.
.
.
.
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 (Figure 2 (a)).
This shared secret allows a strong degree of authentication between the mobile host and its home
agent. The base level of authentication defined by IMHP in this case involves performing a checksum
of the important fields in the registration packet (or reply) and the shared secret, using the MD5 one way cryptographic hash function [17]. 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.
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 re-authenticated. The visitor list entry may also be authenticated as part of the registration 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 unauthenticated 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.
9. Conclusion
This paper has described the main features, operations, and implementation of a new mobile host protocol, called the Internet Mobile Host Protocol (IMHP), which achieves transparent mobility featuring route
optimization and integrated authentication of all management packets. IMHP is designed to take advantage of strong authentication mechanisms when the necessary infrastructure becomes available in the Internet and yet provides a simple authentication mechanism that can be used today that preserves the current level of security in the Internet.
In the short term, IMHP can provide a valuable service to the majority of users on the Internet who either do not have the need for strong authentication mechanisms beyond that provided by the Internet today or are unwilling to pay the price of less than optimal routing in the meantime in the absence of a key distribution infrastructure. In the long term, as key management systems become available, IMHP can provide route optimization for all packets from any correspondent host to any mobile host, regardless of a mobile host’s location, in a manner that will satisfy future authentication requirements.
DOWNLOAD LINK:
CLICK ME
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 TCP/IP protocol
suite, and allows a mobile host to move around the Internet 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 cryptography or shared keys that
may either be manually administered or provided by a future Internet key management protocol.
1. Introduction
In recent years, computers have become increasingly compact and very powerful. At the same time,
connectivity to the global network is becoming widespread, and with the recent introductions of commercial wireless network interfaces, users nowhave 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.
A number of mobile host protocol proposals that are compatible with the TCP/IP protocol suite have
been proposed [1, 2, 3, 4, 5, 6, 7, 8, 9, 16, 19, 20]. 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 [10, 11]. Proposals have also been made for supporting host mobility in an OSI environment [12].
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 [6, 7]) 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 [18].
The only previous mobile host protocol proposal that provides for extensions to guard against this type of attack [6, 7] 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 non-optimal routing results in reduced
performance transparency 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
performance transparency and operational transparency to the user. IMHP introduces an optional new
mechanism for providing simple authentication of management packets that preserves the level of security found in today’s Internet [18], and is designed to accommodate stronger authentication based on public key cryptography or on shared keys that may either be manually administered or provided 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 [15].
Section 2 of this paper describes the necessary IMHP infrastructure. Section 3 discusses the IMHP
authentication procedures and their operation in the protocol. In Section 4, the rules used by each node when forwarding packets are presented, and in Section 5, the means by which nodes learn and cache the location of mobile hosts are described. Section 6 discusses additional features of the protocol, and Section 7 details a number of examples of the operation of the protocol. Section 8 describes an implementation of IMHP, and Section 9 presents conclusions.
2. IMHP Infrastructure
The IMHP architecture includes four functional entities: mobile 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.
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.
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 uninterrupted service from its current local agent, a mobile host must re-register 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 previous 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, if 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.
.
.
.
.
.
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 (Figure 2 (a)).
This shared secret allows a strong degree of authentication between the mobile host and its home
agent. The base level of authentication defined by IMHP in this case involves performing a checksum
of the important fields in the registration packet (or reply) and the shared secret, using the MD5 one way cryptographic hash function [17]. 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.
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 re-authenticated. The visitor list entry may also be authenticated as part of the registration 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 unauthenticated 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.
9. Conclusion
This paper has described the main features, operations, and implementation of a new mobile host protocol, called the Internet Mobile Host Protocol (IMHP), which achieves transparent mobility featuring route
optimization and integrated authentication of all management packets. IMHP is designed to take advantage of strong authentication mechanisms when the necessary infrastructure becomes available in the Internet and yet provides a simple authentication mechanism that can be used today that preserves the current level of security in the Internet.
In the short term, IMHP can provide a valuable service to the majority of users on the Internet who either do not have the need for strong authentication mechanisms beyond that provided by the Internet today or are unwilling to pay the price of less than optimal routing in the meantime in the absence of a key distribution infrastructure. In the long term, as key management systems become available, IMHP can provide route optimization for all packets from any correspondent host to any mobile host, regardless of a mobile host’s location, in a manner that will satisfy future authentication requirements.
DOWNLOAD LINK:
CLICK ME
No comments:
Post a Comment