Towards Secure Mobility Support for IP Networks - CiteSeerX

Towards Secure Mobility Support for IP Networks Stefan Mink1, Frank Pählke1, Günter Schäfer2, Jochen Schiller1 1) Universität Karlsruhe (TH), Institut für Telematik, Zirkel 2, 76128 Karlsruhe, Germany Fax: +49 721 388097, Email: [paehlke|schiller]@telematik.informatik.uni-karlsruhe.de 2) Ecole Nationale Supérieure des Télécommunications, Département INFRES, 46 rue Barrault, 75634 Paris, Cedex 13, France Fax: +33 1 4581-3119, Email: [email protected]

Abstract The upcoming protocol architecture for mobile communications in the Internet, Mobile IP, inhibits various potential vulnerabilities to malicious attacks and, therefore, requires the integration of appropriate security services. This paper analyses the most prominent current approaches for improving the functionality of Mobile IP from a security point of view, focussing on the criteria efficiency, scalability, transparency, and manageability which are crucial for application in real world networks. The three big topics covered are authentication and key management, confidentiality and integrity, and efficient micro-mobility support. The paper concludes with an outlook to ongoing research efforts addressing the problems identified before.

Keywords Mobile Communications, Mobile IP, Security, Authentication, Key Management, Firewalls

1

Introduction

With the advent of protocol architectures supporting mobile terminals, the foundations for ubiquitous availability of modern communication services for personal computing devices are currently being laid. One of the most promising approaches is the specification of new protocols to support terminal mobility in the Internet, currently standardized by the Internet Engineering Task Force (IETF) in the Mobile IP working group [16, 17, 19, 20, 21, 22, 23, 31]. Together with a variety of exciting new applications to mobile data and multimedia communications, a multitude of essential issues concerning the security of mobile communications arise that have to be thoroughly analyzed. These issues include security impli-

cations to a guest network that can be caused by a visiting mobile host (foreign network security, e.g., unauthorized use of services and information disclosure), security implications to the home network when mobile nodes are roaming abroad (home network security, e.g., information disclosure), and security implications to the mobile host itself while visiting a foreign network (mobile node security, e.g., information disclosure as well as anonymity and privacy issues). In more detail, these aspects have to be investigated according to the basic security goals of data confidentiality, data integrity, authorized access to data and services, availability and correct functioning of services, authenticity of communicating entities as well as accountability to actions performed or caused by an entity [5, 9, 27, 29]. This article provides an overview of the security services proposed for the Mobile IP protocol as well as some security implications of extensions to the Mobile IP protocol currently discussed in the IETF working group. Besides provisioning of security services, the approaches will have to meet some additional criteria that are crucial to the suitability and acceptance of mobility protocols for the Internet: • Efficiency: The protocols should induce little overhead and computing requirements. • Scalability: The protocols should also be deployable in big networks with many mobile users and frequent handovers. • Transparency: The protocols should require as little changes as possible to existing systems, especially to mobile nodes and correspondent nodes. • Manageability: In big networks, it is crucial that protocol mechanisms can be efficiently managed. For security protocols, this includes key management, policy management, and access control. The paper is organized as follows: we start with an introduction to the Mobile IP protocol in section 2. In section 3 we give some background on the IPSec security architecture that has been developed as a general purpose security architecture by the IETF and is

envisaged as well for implementing security services for Mobile IP. Section 4 reviews the currently discussed approaches to the fundamental security services of authentication and key management in Mobile IP scenarios. Section 5 discusses firewall interoperability aspects of Mobile IP, together with propositions for realizing integrity and confidentiality, while section 6 discusses security aspects of more elaborate approaches to support micro mobility in the Internet. In section 7 we summarize and compare the various approaches according to the above criteria, and Section 8 concludes the article by giving an outlook to the FATIMA architecture currently developed by the authors, which addresses the deficits which have been pointed out before.

2

Mobile Communications in the Internet Based on Mobile IP

Routing of packets in the Internet is based on IP addresses. Routers check the destination address of incoming packets and forward them to the port assigned to the so-called best prefix. This helps mapping destination addresses with the same prefix into a single routing table entry. Introducing mobile nodes requires several changes or enhancements of the current protocol suite. As mobility should be transparent to most applications, changing the IP address of a node according to its current location is not an option. Neither would most applications continue to work after the address has been changed on-the-fly, nor could any communication partner find the node with the new, unknown address. Furthermore, updating all routers according to the current location of the mobile node is not feasible due to management, security, and scalability reasons. Therefore, an extension to IP for mobile nodes, Mobile IP, has been proposed [19]. Using Mobile IP, a communication partner, the socalled Correspondent Node (CN), sends a packet as usual to the fixed IP address of the Mobile Node (MN). The routers in the Internet forward this packet to the standard location of the MN, called the home network. Within the home network or as router for the home network, the Home Agent (HA) intercepts the packet if the MN is currently not in the home network. As the HA knows the current location of the MN, it tunnels the packet to a Care-of-Address (COA) temporarily assigned to the MN (so-called co-located COA) or to a Foreign Agent (FA) currently responsible for the MN in the foreign network. The COA denotes the tunnel end-point where the packet is decapsulated and forwarded to the MN in case of an FA holding the COA. Typically, tunneling is performed using IP-in-IP encapsulation, i.e., a new IP header is created by the HA with the COA as destination and the HA as source address, and the original packet is used as payload [20]. In standard Mobile IP, the return path is much

simpler as the MN can send packets as usual using the FA as default gateway. Before the MN can send and receive data it has to register its current location with the HA. All agents (HA and FAs) therefore broadcast agent advertisements into the subnet. An MN entering a new network receives these broadcast messages and notices if this network is the home or foreign network. If the latter is true, the MN sends its identification and the address of its HA to the FA which forwards this registration request to the HA. The HA then checks if the MN is authorized to register and, if this is the case, acknowledges the registration. This acknowledgement is again forwarded by the FA to the MN. Both MN and HA can now trust each other, and the HA can start tunneling data to the COA. Several optimizations and enhancements to the standard Mobile IP have been proposed during the last years. One enhancement tries to avoid the so-called triangular routing of packets (CN-HA-FA-MN and back to the CN) by sending binding updates to the CN to inform it of the MN’s current location. After receiving such an update from the HA, a CN can directly send to the MN. However, this requires the ability to update the binding cache in arbitrary CNs and raises several security issues. Furthermore, it was soon discovered that simply sending packets from the MN to a CN via the FA does not work in real networks using firewalls. Sending a packet from the MN located within a foreign network cannot be allowed by a firewall as this looks the same as a typical spoofattack. Such packets with topological incorrect addresses will be filtered out immediately. [17] proposes a reverse tunneling, i.e., the MN sends packets to the FA which tunnels them to the HA. The HA then forwards these packets as if they came from the home network. This solution also solves several problems with multicast communication and the lifetime of packets. However, the additional triangular routing makes the whole approach even more inefficient. Many more details such as registration procedures, additional encapsulation mechanisms, packet formats, and optimizations can be found in [22]. [21] gives an introduction to the extension of Mobile IP to IPv6.

3

The IP Security Architecture

The IP security architecture IPSec, currently being standardized by the IETF [10, 30], aims to secure arbitrary IP communications, including TCP, UDP, as well as application specific transport protocols. With IPSec, security mechanisms are directly applied to IP packets. In order to recognize protected packets and in order to transport security relevant information, additional headers are added to an IP packet. There are two extensions defined to protect IP packets:

• The Authentication Header (AH) is used to protect the authenticity and integrity of an IP packet with a keyed cryptographic hash value. • The Encapsulating Security Payload (ESP) transports encrypted IP packets ensuring confidentiality and optionally authenticity as well as integrity of the packet’s payload. In contrast to AH, the outer IP header is not protected. Both ESP and AH have been defined for use in two different modes: • Transport Mode is intended for use directly by communicating end-systems. In this mode, the AH or ESP header is prepended to the IP payload (i.e., the transport protocol header and payload). • Tunnel Mode has been defined to allow for the realization of encrypted tunnels between endsystems or intermediate systems. In this mode, the appropriate header is prepended to the complete IP packet subject to its protection. In order to form correct IP packets a new IP header is created with the IP address of the tunnel endpoint in the destination address field. In order to use these security mechanisms, some context (e.g., keys, algorithm parameters, etc.) has to be exchanged between two communicating entities. As the connectionless IP does not create any context between two communicating entities, a new concept, the so-called Security Association (SA), is introduced by the IPSec architecture. Security associations are represented through data records stored in the communicating entities that contain parameters for cryptographic algorithms and keys to be applied to (some of the) IP packets exchanged between the communicating entities. They may be set up manually or by a security association and key management protocol (section 3.3). During SA set-up a 32 bit number, the Security Parameter Index (SPI), is determined which is included in AH and ESP in order to identify the SA. SAs are unidirectional, so two SAs have to be set up for secured bi-directional communication. Security associations may be established between two endsystems, an end-system and an intermediate system, or two intermediate systems. This allows for intermediate systems acting as security gateways for endsystems that do not support IPSec or even acting as encrypting firewalls for whole subnets.

3.1

Authentication Header (AH)

Authentication, i.e., ensuring that someone really is the person he or she claims to be, is one of the most fundamental tasks in every security architecture. Without authentication, every attempt to ensure the integrity and/or confidentiality of communication is vulnerable to an attack known as masquerading, where an adversary sets up a seemingly “secure” connection while masquerading as a legal communication

partner. There are two variants of authentication that address fundamentally different needs: • Data Origin Authentication ensures that a message has been created once by a specific entity and that the message has not been modified by some other entity afterwards. • Entity Authentication ensures that an entity in dialog with another entity is really the entity it claims to be. In addition to data origin authentication, it has to be ensured that the messages received by the verifying entity are fresh, because otherwise an attacker could use old messages, registered from a former conversation, to authenticate himself as the original entity. This replay protection can either be achieved by timestamps, requiring synchronized clocks, or by nonces, i.e., freshly generated random values included in the messages. The IPSec Authentication Header [11] realizes data origin authentication. The proof of authenticity is based on the possession of a cryptographic secret used as key to a keyed hash function (message authentication code, MAC) calculated for each IP packet sent. Figure 1 illustrates the placement and the structure of the AH in an IP packet with TCP payload. Transport Mode: IP Header

AH

TCP Header

AH

Old IP Hdr.

TCP Payload

Tunnel Mode: IP Header

TCP Header

TCP Payload

Figure 1: Placement of the Authentication Header (AH) The AH directly follows the IP header and precedes the original payload of the IP packet (transport mode) or the complete original packet (tunnel mode). It contains, among others, a MAC over the contents of the whole packet, including the new IP header. Only the values of the IP header that are subject to change during transmission (time to live, header checksum) are excluded from the computation of the MAC.

3.2

Encapsulating Security Payload (ESP)

The Encapsulating Security Payload [12] can provide authentication and confidentiality for IP packets. Figure 2 shows the ESP placement for a TCP connection. Transport Mode: IP Header

ESP Header

TCP Header

TCP Payload

ESP Trailer

Tunnel Mode: IP Header

ESP Header

Old IP Hdr.

TCP Header

TCP Payload

ESP Trailer

Figure 2: Placement of the Encapsulating Security Payload (ESP) The ESP (except for the ESP header containing the

SPI and a sequence number) is encrypted with a key defined by an already established security association. The ESP trailer optionally contains a MAC ensuring authenticity of the ESP. The new IP header is neither encrypted nor authenticated. It is also possible to use ESP for authentication-only purposes by choosing “NULL” as encryption algorithm.

3.3

Key Management and Security Association Negotiation

In order to establish the keys in the systems that are generating and processing the AH and ESP respectively, two main strategies can be followed: manual setting of the keys or automated key management by a security association negotiation procedure that performs an entity authentication. Since the first method is cumbersome, error prone, and less secure in case of configuration of multiple machines that may need to communicate with each other – one secret key per possible pair of communicating systems has to be configured – it may only be recommended for short term solutions when there is no support for a security negotiation procedure (e.g., no common authentication protocol, no public key infrastructure). During standardization of IPSec a couple of key management protocols have been proposed: SKIP, Photuris, and ISAKMP with IKE/Oakley [6, 8, 14, 16, 18, 24]. These approaches differ mainly in the cryptographic algorithms used as well as in the number of messages exchanged and the format of the messages.

3.4

Access Control

Although not an integral part of IPSec, access control plays an important role in every security architecture and has, therefore, to be considered when deploying IPSec. The task of access control is to ensure that only authorized entities may perform certain actions (e.g., accessing a file, sending data, etc.). In the Internet, an important technique for realizing access control are firewalls which control the flow of IP packets by looking at their transport-layer source and destination. Based on its policy, a firewall decides to block a packet or to let it pass. This task requires that the firewall is able to interpret at least the source and destination IP address as well as the TCP/UDP ports. This requirement conflicts with the requirement of end-toend-confidentiality as end-to-end-encryption prevents the firewall from reading the packets’ contents. The next sections will present currently discussed approaches for integrating security services into Mobile IP networks, dealing with authentication, integrity and confidentiality as well as security aspects of micromobility supporting approaches.

4

Authentication and Key Management for Mobile IP

It is generally relatively easy to install a shared secret between an MN and its HA, because these systems

belong to the same administrative domain. A much more difficult task is to install a secret key between an MN and systems in a foreign domain, e.g., an FA. One solution to these problems is to install a key distribution center (KDC), which can be contacted online in order to obtain the necessary keys. In big networks, each administrative domain could have its own KDC, which must then have pre-configured security associations with the KDCs of all other domains where MNs of this domain should be able to roam. Another option is the use of public-key cryptography, but this approach requires availability of a networkwide public key infrastructure.

4.1

Standard Mobile IP

The Mobile IP standard [19] defines an Authentication Extension (AE) for registration messages, comprising, among others, an SPI referring to some previously defined Mobile Security Association, and an authenticator which is calculated using a keyed hash function (MAC, see section 3.1). As a minimum common standard, the implementation of keyed MD5 in prefix+suffix mode is mandatory, but other MAC algorithms (e.g., the HMAC construction [13]) are allowed as well. Entity authentication is provided by mutually protecting HA and MN against replay attacks either by timestamps or by nonces (section 3.1). The main deficits of the current standard can be summarized as follows: − Manageability: A huge management effort is necessary in order to supply all instances (HA, FA, MN) with shared secrets before they are able to communicate securely. The authentication of an MN (and, to a somewhat smaller extent, of an HA) to systems in a foreign domain (e.g., an FA) is rendered difficult, if not impossible. − Scalability: Since every MN needs separate keys for every FA and HA, the system does not scale to big networks. However, the scheme is appropriate for small, static and administratively closed environments like an intranet. − Security: • Replay protection is only provided for mutually authenticating MN and HA. There is no replay protection between FA and either MN or HA. • There are some objections among cryptographers about the security of keyed hash functions in prefix+suffix mode [27, p. 458].

4.2

Challenge-Response Extensions

The Mobile IP Challenge-Response Extensions [23] provide replay protection for all messages exchanged within the Mobile IP protocol (which, of course, should have been included into standard Mobile IP) by defining two new types of message extensions: A Challenge Extension for FA advertisement messages and a Mobile-Challenge-Response Extension for reg-

istration messages. The mechanisms used are compatible with the PPP-CHAP standard [28].

4.3

Secure Scalable Authentication (SSA)

The goal of Secure Scalable Authentication [7] is to provide Mobile IP with a strong, scalable authentication mechanism based on symmetric or public key cryptography. The SPI field in the Mobile IP Authentication Extension is cut down from 24 bit to 8 bit, and a new field called Auth Type is added which holds an ID of the algorithm used. Additionally, a Certification Extension is defined which holds a certificate chain for a public authentication key. Main advantages and disadvantages of this approach: + Scalability: Public key authentication is scalable to almost arbitrarily large networks. + Manageability: Authentication is possible without an existing security association, which solves the problem of authenticating an MN/HA to systems in a foreign domain. − Efficiency: Public key algorithms are generally slower than symmetric algorithms, especially if a complete certificate chain has to be validated. − Transparency: • The use of certificates requires availability of a network-wide public key infrastructure. • The format of Mobile IP Authentication Extensions is altered.

4.4

HA as KDC

One simple and obvious approach to solving the key distribution problem is to let the HA act as a key distribution center. The HA must now have security associations with each MN in its own domain and with each FA in each foreign domain where these MNs are to roam. This may be practical if the domains involved are affiliated administratively. Main advantages and disadvantages of this approach: + Efficiency: An efficient way of installing a secret key between an MN and an FA is provided. − Scalability: Separate keys are needed between each HA/FA pair, and the HA may become a bottleneck if it has to distribute keys to many mobile nodes. − Security: All FAs are required to trust the HA, which may compromise foreign network security.

4.5

Rapid Authentication

Rapid Authentication [26] is a more sophisticated approach which uses KDCs inside a foreign network. Its main objective is to speed up subsequent authentications by mobile nodes already registered in a foreign domain when moving between different FAs inside that domain. A Foreign Agent Advertisement Extension is used for signaling if an FA supports Rapid Authentication and for providing the address of a KDC in the FA’s domain. Upon entering a foreign domain, an MN first registers with the KDC, optionally using public key

cryptography, thereby obtaining shared secrets which can be used for subsequent authentications. Main advantages and disadvantages of this approach: + Scalability: Public key cryptography can be used for initial authentication. + Efficiency: Subsequent authentications inside a domain require only symmetric cryptography. − Transparency: The MN must know how to handle both initial and subsequent authentications.

4.6

DIAMETER

The DIAMETER protocol [1] is currently being developed as a more flexible successor to the widely deployed RADIUS protocol for authentication, authorization and accounting (AAA). It provides a base protocol for transferring data, error messages and keep-alive messages and for handling server reboots, also defining the message format and some basic data types. AAA functionality is implemented using various protocol extensions, including an extension for dealing with Mobile IP [2]. DIAMETER includes support for a whole hierarchy of servers and proxy servers as well as for so-called brokers transferring AAA data between different network providers. The DIAMETER Mobile IP extensions [2] provide authentication of an MN to an FA, authorization of an FA to grant access to MNs and distribution of symmetric authentication keys. Main advantages and disadvantages of this approach: + Security: The foreign network is provided with authorization and accounting functionality. + Scalability: Hierarchical servers, brokers, and public key cryptography are supported. + Manageability: The protocol is flexible, extensible, and requires relatively few pre-installed keys. − Transparency: Both home and foreign network infrastructure must support DIAMETER.

5

Aspects of Confidentiality, Integrity, and Firewalls in Mobile IP

In Mobile IP, a tunnel is built up from an HA to the MN’s COA. This tunnel generally traverses both the home and foreign networks’ firewalls. Like, e.g., dialin servers, the tunnel endpoints have to be administered carefully with regard to security. This decentralization of security-critical administration tasks is undermining the main benefit of a firewall, which is the concentration of those tasks to relatively few centrally administered systems. Thus, network operators are not likely to accept any tunnels through their firewalls. In order to protect the foreign network, its firewall must keep a list of all currently registered mobile nodes. Since this information is normally only available to foreign agents, additional communication between the FAs and the firewall is required in order to dynamically reconfigure the firewall’s ruleset, which increases network load and is inherently dangerous.

Additionally, the firewall has to inspect both outer and inner header of tunneled packets to ensure the packets are delivered only if their “real” destination address is the home address of a registered MN, which may cause efficiency problems. Since an MN abroad is logically still a part of its home network, security associations providing at least data origin authentication are necessary between each MN and some system in the home network (e.g., an HA or a firewall). Data encryption (e.g., an ESP tunnel) is required to keep confidential data transmitted to the MN as secure as it would be inside the home network. On the other hand, an encrypted tunnel between the home network and an MN completely inhibits analysis of transmitted packets by the foreign network’s firewall. It is thus always necessary to find a trade-off between home and foreign network security. Another problem regarding Mobile IP and firewalls is the use of topologically incorrect source addresses for packets sent by an MN in order to avoid reverse tunneling. Few firewalls will allow such packets to exit a foreign network, or to enter the MN’s home network if the destination address is located there.

− Transparency: All mobile nodes must support SKIP and use a co-located COA. Every MN can have at most one mobility binding, which inhibits soft handovers. Firewall-protected foreign networks are not supported.

5.1

Cellular IP [3] provides fast local handovers inside a domain by installing a single Cellular IP Gateway (CIPGW) which acts to the outside world as a foreign agent. Inside the domain, all nodes collect routing information for accessing MNs based on the origin of packets sent by the MNs towards the CIPGW. Soft handovers are achieved by allowing simultaneous forwarding of packets destined for an MN along multiple paths. An MN moving between adjacent cells will thus temporarily be able to receive packets via both old and new base stations. Main advantages and disadvantages of this approach: + Manageability: Cellular IP is mostly selfconfiguring, and integration of the CIPGW into a firewall would facilitate administration of mobility-related functionality. This is, however, not explicitly specified in [3]. − Efficiency: Additional network load is induced by forwarding packets on multiple paths. − Transparency: Changes to MNs are required. − Security: Routing tables are changed based on messages sent by mobile nodes. Additionally, all systems in the network can easily obtain a copy of all packets destined for an MN by sending packets with the MN’s source address to the CIPGW.

ESP tunnel management

As stated above, it may be required to set up IPSec tunnels between any of the three involved instances (HA, FA, MN) to provide integrity and confidentiality. In [31], Mobile IP registration messages are extended by a mechanism for negotiating the setup of ESP tunnels. The extension comprises six flags defining which of six possible unidirectional tunnels (HA→FA, HA→MN, MN→FA, and vice versa) should be established. The actual tunnel establishment has to be done by an appropriate protocol (e.g., ISAKMP). Main advantages and disadvantages of this approach: + Efficiency: The required overhead is minimal. − Manageability: The protocol is quite inflexible and cannot be extended to support e.g. proxy agents.

5.2

SKIP Firewall Traversal for Mobile IP

In [16], a scheme of combining Mobile IP and IPSec tunnels is proposed which can protect the home network when mobile nodes are roaming abroad. Protection of foreign networks is not discussed. An IPSec AH+ESP tunnel is installed between the home firewall and the MN, which has to obtain a co-located COA. A Mobile IP tunnel between HA and MN is then installed inside this IPSec tunnel. An additional SKIP header comprises a “key ID” which can be used by the home firewall as filter criterion. Main advantages of this approach: + Security: No system outside the home network needs to know an MN’s care-of address. + Manageability: Most functionality is concentrated in the home network’s firewall.

6

Security Aspects of MicroMobility Supporting Approaches

There are several ongoing research projects focussing on better micro-mobility support for Mobile IP, i.e., efficient handling of handovers between adjacent FAs belonging to the same administrative domain. For example, one could imagine the underlying network being a cellular network (e.g., GSM, CDPD, UMTS), where fast handovers between adjacent cells should be possible locally, without contacting the home agent. All of the following approaches require a trade-off regarding scalability: In order to reduce signaling traffic, the foreign domain should be as big as possible, but the number of MNs inside a foreign domain is limited because the domain’s infrastructure must store routing entries for individual MNs.

6.1

6.2

Cellular IP

HAWAII

HAWAII [25] (Handoff-Aware Wireless Access Internet Infrastructure) tries to keep micro-mobility support as transparent as possible for MNs (which have to support route optimization, though). Its goals are performance and reliability improvements and support for quality of service (QoS) mechanisms. Upon entering an HAWAII domain, an MN obtains a

Authentication and Key Management

Scalability

Manageability

Efficiency

Transparency

Security

N/A + − + − ο

− − + ο ο +

Secure Firewall Traversal

7.3

Scalability

Efficiency ο ο

− −

Manageability

ο ο

Transparency

ESP-TM SKIP-FW

+ −

− ο

Micro-Mobility Support

8

− ο −

ο + ο

+ + +

Manageability

Cellular IP HAWAII HMIP

Transparency

The following table compares the approaches mentioned in section 6: Cellular IP, HAWAII, and Hierarchical Mobile IP (HMIP). All approaches have severe problems related to security issues which make them not very attractive for company networks. Scalability to frequent handovers is improved over basic Mobile IP, but the size of mobility domains remains limited.

Comparison of Existing Approaches Focussing on Mobility

The following table compares the approaches mentioned in section 4: Basic Mobile IP, Mobile IP with Challenge/Response Extensions (C/R Ext.), Secure Scalable Authentication (SSA), HA as KDC, Rapid Authentication (RA), and DIAMETER. Transparency does not apply to basic Mobile IP because all approaches are evaluated relatively to this basic proto-

− − + − + +

The following table compares the approaches mentioned in section 5: ESP Tunnel Management (ESPTM) and SKIP Firewall Traversal (SKIP-FW). Note that protocol efficiency is always degraded to a certain extent by installing additional tunnels. Both approaches provide home network and MN security at the expense of foreign network security. Improving the poor scalability of basic Mobile IP is beyond the scope of either protocol.

The following tables give a concise overview over the contents of the previous sections by evaluating each approach in respect to each criterion given in section 1 using a three-stage evaluation scheme (+, ο, −).

7.1

ο ο ο + + +

Scalability

7

7.2

− + + ο + +

Efficiency

Hierarchical Mobile IP

Hierarchical Mobile IP [4] provides micro-mobility support by installing a hierarchy of mobility agents and assigning a “virtual” COA on each hierarchy level. When an MN moves locally, only those mobility agents directly affected by the move must be notified. The HA (and the CNs in case of route optimization) has to be notified only if the MN moves between the domains of different top-level mobility agents. Main advantages and disadvantages of this approach: + Security: MNs can have (limited) location privacy because lower level COAs are hidden. − Transparency: Additional infrastructure and changes to the MN protocol stack are required. − Efficiency: In case of handover, all hierarchy levels have to be reconfigured by the MN, which may be connected to the network by a slow wireless link. − Security: Routing tables are changed based on messages sent by mobile nodes, and there are no provisions for control message authentication.

Basic Mobile IP C/R Ext. SSA HA as KDC RA DIAMETER

Security

6.3

col. One problem of the approaches is obviously the trade-off between scalability and transparency. To gain scalability quite often special enhancements have to be implemented on the systems.

Security

co-located COA. Additionally, when moving to a new cell inside the foreign domain, the MN sends a registration request to the new base station (BS) as to a foreign agent, which mixes the concepts of co-located COA and foreign agent COA. The BS intercepts the registration request and creates a handoff update message which reconfigures all routers on the paths from the old and new BS to the so-called crossover router. When routing has been reconfigured successfully, the BS sends a registration reply to the mobile node, again as if it were a foreign agent. Main advantages and disadvantages of this approach: + Security: Challenge-response extensions (section 4.2) are made mandatory. In contrast to Cellular IP, routing changes are always initiated by the foreign domain’s infrastructure. + Transparency: HAWAII is mostly transparent to mobile nodes. − Security: There are no provisions regarding the setup of IPSec tunnels.

− ο −

+ ο ο

Conclusion and Outlook to Ongoing Research

This paper analyzed Mobile IP and several current extensions from a security point of view. From this comparison, one can identify several desired properties of a secure and transparent IP mobility support: • Security-critical functionality like registration processing should be centrally administered.

•

Dynamic reconfiguration of, e.g., routers should be controlled by trusted infrastructure components (e.g., foreign agents) and not by mobile nodes. • Extensions to the Mobile IP standard should be limited to infrastructure components and internal interfaces. Changes to external interfaces to mobile nodes or to standard Mobile IP infrastructures in remote networks should be kept to a minimum. • All entities should be able to authenticate each other. In order to achieve this goal, flexible interfaces to supporting infrastructures (e.g., publickey or AAA infrastructures) should be provided. The authors of this paper have developed an architecture for mobility support in IP networks, called FATIMA (Firewall-Aware Transparent Internet Mobility Architecture, see [15]), which addresses the issues raised above. The key design principle of FATIMA is the integration of mobility-supporting functionality into a gateway system located inside the network’s firewall where it can be centrally administered. Home and foreign agents are replaced by considerably simpler entities which provide the same interface to mobile nodes as standard Mobile IP agents, but which delegate most of their functionality to the gateway system. Currently, a prototypical implementation of FATIMA is being developed which will provide a base for evaluation of performance aspects in a simulation environment.

REFERENCES 1. P. R. Calhoun, A. C. Rubens, H. Akhtar, E. Guttman. DIAMETER Base Protocol. draft-calhoundiameter-13.txt (work in progress), March 2000. 2. P. R. Calhoun, C. E. Perkins. DIAMETER Mobile IP Extensions. draft-calhoun-diameter-mobileip06.txt (work in progress), March 2000. 3. A. Campbell, J. Gomez, C.-Y. Wan, S. Kim, Z. Turanyi, A. Valko. Cellular IP. draft-ietfcellularip-00.txt (work in progress), January 2000. 4. C. Castelluccia. A Hierarchical Mobile IPv6 Proposal. INRIA Rapport Technique, 1998. 5. W. Ford. Computer Communications Security – Principles, Standard Protocols and Techniques. Prentice-Hall, 1994 6. D. Harkins, D. Carrel. The Internet Key Exchange (IKE). RFC 2409, November 1998. 7. S. Jacobs. Mobile IP Public Key Based Authentication. draft-jacobs-mobileip-pki-auth-02.txt (expired), March 1999. 8. P. Karn, W. Simpson. Photuris: Session-Key Management Protocol. RFC 2522, March 1999. 9. C. Kaufman, R. Perlman und M. Speciner. Network Security – Private Communication in a Public World. Prentice Hall, 1995. 10. S. Kent, R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401, November 1998.

11. S. Kent, R. Atkinson. IP Authentication Header. RFC 2402, November 1998. 12. S. Kent, R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, November 1998. 13. H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. 14. D. Maughan, M. Schertler, M. Schneider, J. Turner. Internet Security Association and Key Management Protocol (ISAKMP). RFC 2408, November 1998. 15. S. Mink, F. Pählke, G. Schäfer, J. Schiller. FATIMA: A Firewall-Aware Transparent Internet Mobility Architecture. Proceedings of ISCC 2000, Antibes, France, July 2000. 16. G. Montenegro, V. Gupta. Sun’s SKIP Firewall Traversal for Mobile IP. RFC 2356, June 1998. 17. G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 1998. 18. H. Orman. The OAKLEY Key Determination Protocol. RFC 2412, November 1998. 19. C. Perkins. IP Mobility Support. RFC 2002, October 1996. 20. C. Perkins. IP Encapsulation within IP. RFC 2003, October 1996. 21. C. Perkins, D. B. Johnson. Mobility support in IPv6. Proceedings of ACM Mobicom 96, November 1996. 22. C. Perkins. Mobile IP: Design Principles and Practice. Addison Wesley Longman Publishing Company, Reading, Massachusetts, USA, 1997. 23. C. E. Perkins, P. R. Calhoun. Mobile IP Challenge/Response Extensions. draft-ietf-mobileipchallenge-09.txt (work in progress), Feb. 2000. 24. D. Piper. The Internet IP Security Domain of Interpretation for ISAKMP. RFC 2407, Nov. 1998. 25. R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli. IP micro-mobility support using HAWAII. draft-ietf-mobileip-hawaii-00.txt (expired), June 1999. 26. L. A. Sanchez, G. D. Troxel. Rapid Authentication for Mobile IP. draft-ietf-mobileip-ra-00.txt (expired), November 1997. 27. B. Schneier. Applied Cryptography Second Edition: Protocols, Algorithms and Source Code in C. John Wiley & Sons, 1996. 28. W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP). RFC 1994, August 1996. 29. W. Stallings. Cryptography and Network Security: Principles and Practice. Second Edition. Prentice Hall, 1998. 30. R. Thayer, N. Doraswamy, R. Glenn. IP Security Document Roadmap. RFC 2411, November 1998. 31. J. K. Zao, M. Condell. Use of IPSec in Mobile IP. draft-ietf-mobileip-ipsec-use-00.txt (expired), November 1997.