April 25, 2000
Harri Hansén
Department of Computer Science and Engineering
Helsinki University of Technology
harri.hansen@vtt.fi
http://www.vtt.fi/tte/staff3/hansen/
Traditional IP routing is based on the fact that the IP address specifies unambiguously a node's point of attachment to the Internet. Mobile IP allows a mobile node to move between different subnetworks while retaining its own IP address and established connections. Mobile IP is specified in RFC 2002 [2] and further improvements are introduced in RFC 2344 [4] and in some other RFCs.
Wireless access to the network cannot be restricted physically, and cryptographical methods have to be used to protect the transmitted data and network elements. Also the use of IP-based infrastructure introduces similar need. Aspects that should be considered are data confidentiality, data authenticity, and service availability. The current standards offer some complementary mechanisms for creating secure data communication with optional data packet authentication and encryption over the wireless link: IPsec [6] and IEEE 802.11 [20] Wired Equivalent Privacy (WEP). Chapter 2 of this presentation focuses on IPsec. The WEP secures only the radio link (between the mobile station and the access point) and the RC4-40 encryption can be broken with reasonable effort.
Chapter 2 of this paper gives an overview of the IP security, while the chapter 3 focuses on mobility issues. A short status update about the next generation mobile systems and the scenario is presented in Chapter 4 and an analysis is carried out in Chapter 5.
IPsec extends the basic IP functionality with security functions for Authentication, Integrity checks, and Confidentiality. For two nodes to be able to secure the communications between them they have to establish a Security Association (SA). In practice this means that they agree on the used security algorithms and share common security keys. The establishment and updating of the variables of the security association is the responsibility of a key management protocol. ISAKMP [10] provides a framework for authentication and key exchange but does not define them. Any protocol fulfilling the ISAKMP requirements can be used (e.g., IKE [11]). The establishment of a SA is seen on the IP layer as an exchange of IP-packets. IKE is seen as the strongest candidate for the establishment of the IPsec security association. The use of IKE and other similar protocols inflicts considerable delay; they require the exchange of multiple messages, and the use of public key encryption requires heavy computation.
When a SA exists between two communication nodes the traffic can be protected. An IP-packet can have two security headers: the Authentication Header (AH) and the Encapsulated Security Payload (ESP). AH is used for Authentication and Integrity, while the ESP provides message Confidentiality and Integrity [9].
First the payload of the packet is encrypted using the parameters and methods agreed in the SA. An ESP field is created to indicate the identity of the SA used and to carry additional information needed for the decoding of the payload of this packet. Next an AH field is created using the content of the packet (in this case both payload and ESP) and the parameters agreed in the SA.
A good overview of the different IPsec aspects is available in [7]. Security is an integral part of the IPv6 specifications. The above description of the IPv4 version of the IPsec is also valid for IPv6 [1].
The IPv4 version of Mobile IP is presented. In IPv6 Mobility support is an integral part of the specification [18]. The major difference between the IPv4 Mobile IP and IPv6 mobility is that the latter does not have Foreign Agents. In this respect it is similar to the co-located care-of address operations of the IPv4 of Mobile IP.
In the first approach foreign agents (routers in IPv6) advertise periodically their existence in the IP subnetwork. The broadcasted agent advertisement is an ICMP router advertisement that includes a mobility agent advertisement extension. When the mobile node discovers a new care-of address from the agent advertisement extension, it sends a registration request to the foreign agent (directly to HA in IPv6). There are two algorithms which the MN can use to notice the need for a new advertisement; expiry of the old advertisement and the discovery of a new subnetwork prefix by the MN. The security related fields in the registration request are the identification field and the mobile-home authentication extension. See RFC 2002 [2] for details. The foreign agent receives the registration request, inspects it, and if all parameters are valid, relays it to the home agent (after message identification and mobile node authentication). The foreign agent can optionally append any number of extensions to the request before relaying it to the home agent. One possible extension defined by [2] is the foreign-home authentication extension, similar to the mobile-home authentication extension, to allow the HA to identify the FA.
It is also possible that the mobile node does not receive any agent advertisements, but discovers that its own IP address has changed. This change might have happened automatically by DHCP client daemon or by user intervention. In this case the mobile node registers the new IP address (called a co-located care-of address) straight to the home agent. Thus a mobile node can also roam a network that does not offer foreign agent services. The HA authenticates the MN, this case directly. The roaming to GPRS networks could be implemented using co-located care-of addresses (mobile terminal gets an IP-address when it associates to the GPRS network).
A registration has a maximum lifetime. The mobile node must send a new registration request before the lifetime of the original registration runs out. A handover happens when the mobile node moves from one network to another. During the handover the mobile node does not receive any packets for a short period of time. The mobility support of IPv6 can be used for softer handovers, and also the MIPv4 has an extension for smooth handovers. However, it should be kept in mind that most of the handover problems are at layer 2.
When a registration request arrives to the home agent the message identification field and the home-mobile (and the optional foreign-home) authentication extension are checked for validity.
Firewalls do not typically pass packets that seem to originate from a wrong subnetwork. This is a problem for mobile IP as the packets from roaming users carry the home address as the source address [5]. The mobile IP could be modified to allow the use of address of the visited subnetwork but this would compromise location confidentiality as mobile terminals could be tracked by the source address of the packets they send (IP hosts can be made to send IP packets as responses to different kind of requests). The home-address option of IPv6 can be useful for this. The level of user privacy required depends on the nature of the service (public systems vs. Internet). The constitution and different laws (e.g., henkilötietolaki, julkisuuslaki) of Finland define the principles of privacy.
Reverse tunneling is likely to be needed when a firewall exists or IPsec tunneling is used between the mobile user and the correspondent node [6].
Outgoing packets from mobile nodes are normally sent directly towards the correspondent node. The destination address in the IP header is the real destination address and the source address is the mobile node's home address. A correspondent node receiving the packet sees it as coming from the mobile node and sends any replies to the mobile node's home address. The use of the real destination address introduces problems with firewalls and IPsec. Mobile IP does not include data encryption, so IPsec (or IPv6 security) should be used for end-to-end encryption of all sensitive traffic.
The identification field in registration requests and replies is required by RFC 2002 [2]. Two methods for constructing the identification value are specified, timestamps and nonces. Timestamps is a mandatory method, nonces is optional. The mobile node and the home agent must agree in advance what method will be used. Message identification protects against registration replay attacks and out-of-order arriving registration requests. If everything is valid, a granting registration reply is sent to the mobile node. The home agent also updates the link level addressing in its subnetwork with a so called gratuitous ARP request in order to receive all traffic to the mobile node.
Security in mobile IP is accomplished with identification and authentication of the registration requests and replies. Only the mobile-home authentication is required by RFC 2002 [2]. The RFC however allows additional mobile-foreign and foreign-home authentication. The authentication extension protects the message body and all preceding extensions from unwanted modification. Thus the authentication extension is placed after all other extensions.
RFC 2002 [2] specifies three different authentication extensions: mobile-home, mobile-foreign and foreign-home authentication extensions. All three extensions have the same format, only the value of the type field differs. All registration requests and replies are protected against unwanted modification. The RFC specifies keyed-MD5 in prefix+suffix mode, with a key size of 128 bits, as the default algorithm for calculating the authenticator. Other algorithms may also be supported.
The evolution from the 2nd Generation mobile system GSM to the 3rd Generation Mobile System UMTS (Universal Mobile Telecommunication System) is specified by an organization called the Third Generation Partnership Project (3GPP) [12]. The first release of the UMTS system, called the Release-99 [13] is almost ready and part of the 3GPP work is focusing on defining an "All-IP" architecture based UMTS core network [15]. In this architecture the connection oriented GSM core network will be replaced by IP based infrastructure. That is, the 3G MSC:s are replaced by evolved 3G GPRS nodes and new nodes implementing the MSC functions (call control, mobility management). The mobile IP ad hoc group of 3GPP- TSG SA has made a proposal for the use of mobile IP in UMTS [16]. Please note that the "ad hoc" in the name of the groups doesn't refer to Ad Hoc computing, but to the temporary nature of this group. The UMTS security is defined by 3GPP Security working group [17]. The security architecture of UMTS is very similar to that of GSM; it is based on symmetric keys stored on a smart card (UMTS SIM) and is focused to the radio interface security of the system. Therefore additional end-to-end authentication and encryption is likely to be required.
The UMTS and GSM, like all telecom systems, allow Lawful Interception for authorized Law and Enforcement agencies. The Internet users have traditionally very negative attitudes towards monitoring of their communications, and this issue can become at least an imago problem for the new IP services of the Telecom systems. International roaming bring out another problem; which countries' Law and Enforcement Agencies do you trust not to exploit your business secrets?
The IPv6 mobility support architecture does not have the foreign agent entity. The functionality of the FA is taken care by routers in the foreign network and the mobile node (IP address generation, registration directly to the HA, end of the "IP-tunnel"). Typically a IPv6 MN generates its own care-of address (stateless address autoconfiguration) and capsulates/decapsulates the traffic it sends or receives.
Mobility becomes visible to the IP routing when the Point of Attachment (PoA) is changed. Mobile IP is assumed to be used for the routing of data packets to roaming users as shown in Figure 1.
In scenario shown in Figure 1 GPRS (i.e., UMTS packet switched) network has specialized mobility management that is based on the use of GSM MAP and GPRS tunneling protocol (GTP). This solution hides the mobility from observer outside the GPRS network; all GPRS/UMTS users seem to be located at the GGSN. Mobile IP can be used in the other networks (shown yellow) .
The scenario assumes that UMTS users can roam into the company intranets, and the intranet users can roam to the UMTS networks (where the PDP is equivalent to a care-of address). The users of each network have their own home agent which is used while roaming other networks. For example an UMTS (mobile node) roaming in the network B has his Home Agent in the operators network (close or integrated to the GGSN). The traffic from the correspondent node, shown in the public internet, arrives to the HA and is forwarded to the FA in network B (in IPv6 the traffic would be forwarded directly to the mobile node). In IPv6 the traffic could also be send directly from the CN to MN. The mobile node can respond directly to the correspondent node (dotted line) or via the HA (reverse tunneling). The routing of the traffic can be optimized by the mobile node informing the correspondent node about the currently used subnetwork.
Figure 1. Use of mobile IP for intersystem mobility management
Smarts cards and strong public key based key generation (like IKE) are required for easy-to-use and secure roaming between terminals and networks. One specific roaming problem relates to the network firewalls; how to map the destination IP address to a firewall IP address? When mobile IP is used the destination IP can have different Firewall IP addresses. Also, the roaming user should not be assumed to trust the firewall of an visited network. Is IPsec in transport mode between the mobile host and the "home" firewall only solution while roaming?
The roaming mechanisms used in the current telecommunication networks requires trust between the operators. A set of bilateral contracts is needed to establish this web of trust. The amount of bureaucracy increases very rapidly as the number of operators grows. Also the risk that untrustworthy operators exploit the roaming mechanisms in dubious manner increases.
A perfect Ad Hoc roaming method:
The Internet has two key technologies to implement Ad Hoc roaming; certificates and electronic payment methods. Electronic transactions can be used for creating a charging infrastructure which is independent from the operators. The roaming user would be shown access providers' login page which lists the available payment methods. The user would pay for the access by clicking the links and possibly giving the passwords or other authentication methods required by the chosen payment method. In the electronic payment methods the transactions, charging contracts and end user billing are handled by a third party which is typically a bank, credit card company, or a specialized e-commerce company.
Public key of the authenticated party is required for the authentication process. Certificates allow parties willing to authenticating each other to securely obtain other party's public key. Certificates are typically obtained from a trusted Certificate Authority (CA). CAs can be commercial companies or governmental authorities. The most commonly used certificate standard is the X.509 specified by ITU-T. There are, however, also other standards. For example interesting SPKI certificate research is currently carried out in the TeSSa-project of HUT [21]. The certificates and especially the secret key related to a certificate has to be stored securely; preferable on a smart card. Also the UMTS and WLAN keys should be in the same certificate hierarchy with user level certificates used e.g., in today's WWW browsers. This would provide easy and secure access of required certificates.
There are various roles in the scenario and each of them can be the origin of a threat. The roles considered during the analysis where:
Mobile Node - Visited Network: On the radio interface the traffic can be protected with the with the 802.11 WEP (e.g., 40 bit key) or the GSM or GPRS radio interface encryption (A5 with effective key length of 54 bits). Intercepting specific data on the radio interface is difficult. The resulting level of security can be considered relatively safe for most of the data, but not safe enough to withstand a determined attack. The UMTS will have a longer 128 bit key. The mobile networks can have unprotected radio links between the base stations and base station controllers.
Inside visited network: It is very demanding to make IP based network secure at the times of faulty TCP/IP protocols/applications and the Internet full of wannabe hackers. The need for additional encryption depends on the level of trust the roaming user has for the visited network's ability and motivation to secure the network. Authenticated home networks should be considered safe (if considered unsafe also fixed hosts should use encryption). If the roamed network is authenticated to be operated by a public network operators it is likely to be relative safe. Unauthenticated networks should not be trusted.
Between the visited and home network: The level of security on this part of the route is very difficult to define. In practice IPsec tunneling should be used.
Inside the home network: In client-server applications and when reverse tunneling is used the route of the packets goes to the home network of the roaming user. The HA in the home network has to be considered safe.
As a conclusion, all sensitive traffic should encrypted end-to-end (MN to CN) or from the MN to the firewall of the home network.
A malicious host might try to register to the HA as a roaming mobile host. This is protected by the mandatory authentication of the register message (IPv4) and Binding update (IPv6). The scenario where a HA in a secure networks accepts mobile-IP registrations originating outside the secure IP-network places very strict requirements on the authentication algorithm and the key management. Smarts cards and a strong public key based key generation (like IKE) are useful for this.
The authentication of the mobile node by the FA is not mandatory in IPv4 Mobile-IP. A malicious host might try to register to the FA as an roaming mobile host. This could allow traffic stealing if the real host is roaming the same visited network. This could also be used for bypassing the charging if the access is charged.
Malicious FAs might try to attack the HA. Possible attack types against mobile IP could be replay attacks and attacks that lead to false authentication. The mobile-IP protocol offers sufficient protection against these in the form of identification and authentication extensions. Replay attacks are prevented by the identification field and the whole message is protected by the authentication extension. The algorithm typically used in IPv4 mobile-IP, keyed MD5, is considered a strong algorithm, so the security of mobile IP registration messages depends on the secrecy of the shared secret.
Reverse tunneling introduces additional threats: when using reverse tunneling the traffic seems to originate from the safe side of the firewall, i.e., from the home agent. The legitimate use of Mobile IP can introduce problems with firewalls and IPSec Security Gateways; reverse tunneling can be used to avoid these problems (with a price of unoptimised routing). Reverse tunneling can also be used for enforcing location confidentiality.
As a conclusion, the authentication between the mobile node and the HA is critical. The optional mobile-IPv4 authentication between HA and FA, as well as between FA and mobile host is needed.
Information related to service availability can be found in [22]. Denial of service attacks cannot be made impossible, but they can be made more difficult to implement by using sophisticated firewalls, good network design, etc. With redundancy servers and links the system can be made faster to recover from a Denial of service attack.
Location confidentiality can be compromised by the optimized routing. A policy for route optimization is needed. In addition the registration and route optimization messages could be encrypted.
The header information of the IP-packets can be used for tracking the mobile host, unless IPsec is used in tunneling mode. This is another good reason for IPsec tunneling all data through unsecured parts of the communication path.
In IPv6 the globally unique MAC identifier (EUI-64) of the WLAN or LAN card is typically used for the host portion of the IPv6 address. Network Access Identifier (NAI) should be allocated so that they do not identify the host. These could be used for tracking the mobile host.
Advanced security policies and firewalls are required if volume based charging is applied on the downlink. The aim is to prevent the transmission of downlink packets not requested by the subscriber. This applies to both UMTS and WLANs.
One solution is to allow only certain trusted servers to send traffic to the mobile user. This might require the servers to be authenticated and the transmission between the servers and the wireless network to be protected. In practice WWW and WAP browsing could be supported using a limited number of trusted proxy servers. Similarly the access to E-mail accounts could be allowed only to trusted mails servers. Which servers should be trusted would mainly depend on the organization managing the servers; in principle authenticated servers of other operators, ISPs, and large companies could be considered safe enough.
If unknown servers are allowed to send traffic to the mobile subscribers the firewalls should be able to detect a likely attack and react by blocking the traffic. If the malicious server manages to inflict considerable charge on the subscriber the billing system should be able to compensate the subscriber's account to prevent the loss of trust towards the wireless system.
It is also worth of noticing that, assuming pure volume based charging, the user might be charged for unsuccessful VoIP and multimedia calls. This would be a problem at least for the case where an R99 terminal is requesting a (connection oriented) voice telephony service from the UTMS all-IP network.
The system is separated from VTT's intranet, and can be accessed from the Internet trough the Mediapoli network in Otaniemi. Mobile-IP, IPsec, IPv6 and other protocols are being tested and developed in the system. The network serves also as a test bed for various research projects.
During the year 2000 the main aim is to study WLAN user roaming. We have studied configurable firewall functions for roaming users. This kind of system could be used for managing the access rights of visitors in company premises. For example, all visitors could use the printers up to 100 pages, but a Netmeeting session would need to be enabled by the host of the meeting using a web based user interface. Similarly the download of a specific file from a server would need to be allowed by the host. More information is available at [23].
A multisystem environment based on ad hoc roaming was presented. The use of unlicensed wireless systems for public service provision and ad hoc roaming methods will create new operator markets. Security of charging is critical for public systems and advanced security policies and firewalls are required if volume based charging is applied on the downlink. User's privacy should not be compromised.
Different attacks against the IP mobility in a multisystem environment were analyzed in chapter 5. No weaknesses that would prevent the use of Mobile-IP were found. However, Mobile-IP is an attractive target for an attacker outside of firewalls as it could allow connection hijacking from inside the firewalls. Making an IP based system secure requires sophisticated network design and maintenance. Denial of service attacks cannot be made impossible, but they can be made difficult.
Mobile IP, IPsec, and Firewalls have some interoperability problems. Some of these can be solved with the reverse tunneling mode of mobile-IP, but this causes inefficient routing.
| [1] | RFC 1688: IPng Mobility Considerations (an early IPv6 mobility RFC)
<http://www.ietf.org/rfc/rfc1688.txt> |
| [2] | RFC 2002: IP mobility support (IPv4)
< http://www.ietf.org/rfc/rfc2002.txt> |
| [3] | RFC 2005: Applicability Statement for IP Mobility Support (IPv4)
< http://www.ietf.org/rfc/rfc2005.txt> |
| [4] | RFC 2344: Reverse Tunneling for Mobile IP, May 1998
< http://www.ietf.org/rfc/rfc2344.txt> |
| [5] | RFC 2356: Sun's SKIP Firewall Traversal for Mobile IP
<http://www.ietf.org/rfc/rfc2356.txt > |
| [6] | RFC 2401: Security Architecture for the Internet Protocol , November
1998
< http://www.ietf.org/rfc/rfc2401.txt> |
| [7] | RFC 2411: IP Security Document Roadmap, November 1998
< http://www.ietf.org/rfc/rfc2411.txt> |
| [8] | RFC 2402: IP Authentication Header, November 1998
< http://www.ietf.org/rfc/rfc2402.txt> |
| [9] | RFC 2406: IP Encapsulating Security Payload (ESP), November 1998
< http://www.ietf.org/rfc/rfc2406.txt> |
| [10] | RFC 2408: Internet Security Association and Key Management Protocol
(ISAKMP), November 1998
< http://www.ietf.org/rfc2408.txt> |
| [11] | RFC 2409: The Internet Key Exchange (IKE), November 1998
< http://www.ietf.org/rfc2409.txt> |
| [12] | 3rd Generation Partnership Project (3GPP, UMTS specification)
< http://www.3gpp.org/ > |
| [13] | Status of GSM & UMTS specification, Release-99 (R99)
< http://www.3gpp.org/TSG/Dec99_status_list.htm > |
| [14] | 3GPP Services and System Aspects (TSG SA)
< http://www.3gpp.org/TSG/SA.htm > |
| [15] | 3GPP - TSG SA - Architecture working group
< ftp://ftp.3gpp.org/TSG_SA/WG2_Arch/> |
| [16] | 3GPP - TSG SA - Mobile IP ad hoc group
< ftp://ftp.3gpp.org/TSG_SA/WG2_Arch/S2_ad-hocs/ > |
| [17] | 3GPP - TSG SA - Security working group
< ftp://ftp.3gpp.org/TSG_SA/WG3_Security/ > |
| [18] | Mobility Support in IPv6, <draft-ietf-mobileip-ipv6-10.txt>, February
2000
< http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-10.txt> |
| [19] | Policy Framework for IP Security <draft-ietf-ipsec-policy-framework-00.txt>,
February 1999
< http://www.ietf.org/internet-drafts/draft-ietf-ipsec-policy-framework-00.txt > |
| [20] | Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications,
June 1997
IEEE Std 802.11-1997, LAN MAN Standards Committee of the IEEE Computer Society |
| [21] | TeSSa: Telecommunications Software Security Architecture, Helsinki
University of Technology.
< http://www.tcm.hut.fi/Research/TeSSA/Papers/ > |
| [22] | Root Shell - Web site
< http://rootshell.com/ > |
| [23] | VTT Information Technology - Trial Network
< http://st1-051.vtt.mediapoli.com/ > |
| Nokia IP security solutions
< http://www.nokia-ipsecurity.com/ > |
| Nokia IP mobility
< http://www.nokia.com/corporate/ipmobility/ > |
| C. Perkins, D. Johnson, 1996, Mobility support in IPv6, Proceedings
of the second annual international conference on Mobile computing and networking,
Pages 27 - 37
< http://www.acm.org/pubs/citations/proceedings/comm/236387/p27-perkins/> |
| Xinhua Zhao, et.al, 1998, Flexible network support for mobility;
The fourth annual ACM/IEEE international conference on Mobile computing
and networking , 1998, Pages 145 - 156
< http://www.acm.org/pubs/citations/proceedings/comm/288235/p145-zhao/> |
| Rolf Oppliger, 1997, Internet security: firewalls and beyond,
Commun. ACM 40, 5 (May. 1997), Pages 92 - 102
< http://www.acm.org/pubs/citations/journals/cacm/1997-40-5/p92-oppliger/ > |
| V. Gupta, G. Montenegro, 1998 Secure and mobile networking, ACM
Mobile Networks and Applications, Volume 3, No. 2 (Aug. 1998), pp 381 -
390.
<http://playground.sun.com/pub/mobile-ip/secure-mip.pdf> |
| Mobile IP for Solaris/Linux: Sunlabs Mobile IP
< http://playground.sun.com/pub/mobile-ip/> |
| The HUT Dynamics mobile IP home page
< http://www.cs.hut.fi/Research/Dynamics/ > |
| Mobile IP Resources
< http://www.public.neda.com/dataCom/mobileIpSurvey/one/index.html > |