Internet Engineering Task Force Basavaraj Patil INTERNET-DRAFT Nokia <draft-bpatil-mobileip-sec-guide-01.txt> Emad Qaddoura Date: May, 2000 Raja Narayanan Expires: November, 2000 Nortel Networks Security Requirements/Implementation Guidelines for Mobile IP using IP Security Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The IP Security protocol is now well established and is being deployed in the global Internet. The security characteristics of IPSec can be used in Mobile IP networks to enable Mobile IP deployment on a wide area basis and in large networks. Mobile IP should leverage off of the developments of IP Security and Internet Key Exchange (IKE) rather than developing it's own security mechanisms. This draft proposes some concepts on how IP Security can be used to provide an alternative security framework for Mobile IP communications. It is intended to be an implementation guideline. Patil, et al. Expires November 2000 [Page 1]
Internet-Draft Securing MIP with IPSec 23 May 2000 Table Of Contents 1 Introduction............................................2 2 Terminology.............................................3 3 Specification Language..................................4 4 Security in Mobile IP Networks..........................4 4.1 Virtual Private Network(VPN) with SLA's...............6 5 Mobile Node - Foreign Agent Security Association........8 6 Mobile Node - Home Agent Security.......................9 7 End-to-End Security between MN and CN...................10 8 Security Associations with the use of Brokers...........10 9 Changes to Mobile IP....................................11 10 Security and IPv6 Considerations.......................12 11 Summary................................................12 12 Acknowledgements.......................................12 13 References.............................................13 14 Authors' Addresses.....................................14 1. Introduction Security is a major concern in today's networks. Mobile IP [RFC2002] enables a user to change his network point of attachment while maintaining network connectivity. Mobility introduces it's own set of security requirements to protect the mobile node from various forms of attack including: 1. Session hijacking - A hostile node can steal a session from a mobile node by having packets redirected to it 2. Spoofing of identity to obtain access to the network and Patil, et al. Expires November 2000 [Page 2]
Internet-Draft Securing MIP with IPSec 23 May 2000 3. Eavesdropping and stealing of data during sessions This draft proposes a security solution using IP Security(IPSec) for deployment of a Mobile IP network. The security characteristics of IPSec such as connectionless integrity, data origin authentication, anti replay protection and confidentiality can be applied to Mobile IP for securing the data both in the control plane and the data plane. The advantages of such an approach lie in: - Making use of a well defined security protocol and the ease in managing the set of security associations that are established as a virtue of having a service level agreement (SLA) with a network/service provider. - There is a single security association between the visited domain and the home domain for all control plane messages, rather than having a security association between every Foreign Agent and Home Agent in these domains. The draft proposes a complete solution for securing all the links used in mobile IP communications. 2. Terminology This document uses the following terminology: Mobile-Node A host that changes its point of attachment from one network or subnetwork to another. A mobile node may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its (constant) IP address, assuming link-layer connectivity to a point of attachment is available. Correspondent-Node A peer with which a mobile node is communicating. A correspondent node may be either mobile or stationary. Home-Agent A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile Patil, et al. Expires November 2000 [Page 3]
Internet-Draft Securing MIP with IPSec 23 May 2000 node. Foreign-Agent A router on a mobile node's visited network which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. Home-Domain The home domain is the network with which a mobile user has primary subscription with. Foreign-Domain A network in which the mobile node may be roaming in that does not have knowledge about this user. Security-Association(SA) A Security Association (SA) is a "connection" that affords security services to the traffic carried by it. 3. Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 4. Security in Mobile IP Networks Mobile IP defines a set of control plane messages that enable a mobile node(MN) to roam between networks and achieve IP mobility. Unlike a conventional telephone network where control plane messages are normally transmitted over a separate control plane link such as SS7, mobile IP messages traverse the same IP network that is publicly accessible (in the case of interdomain roaming). No separate secure network, analogous to the SS7 network, is used by Mobile IP for it's control plane. It is necessary to protect the data in both the control plane and the data plane in order to prevent security attacks on the mobile user. Patil, et al. Expires November 2000 [Page 4]
Internet-Draft Securing MIP with IPSec 23 May 2000 The following four security associations (SAs) shown in Figure (1) are identified for securing Mobile IP communication: 1. SA1 - Between the Mobility Control Message Gateway Function (MCMGF) server in the visited/foreign domain and the MCMGF server in the home domain. 2. SA2 - Between the MN and the serving FA in the visited domain. 3. SA3 - Between the MN and the HA. 4. SA4 - Between the MN and the CN for end-to-end security. SA3 may be optional if there exists some other link layer security mechanism between the MN and the FA. SA4 is optional and is established only if policies at the MN require it. SA4 |-----------------------------------| | [CN] | Visited/Foreign Ntwk. Home Ntwk. | |--------------| |--------------| | | | |---| | | [MN] | [FA][MCMGF]|-----| |-------|[MCMGF][HA] | | | | | | |---| | | | | | |----|-----|---| Internet |---|-----|----| | SA2 | |-------------------------| | |------------| SA1 | |--------------------------------------------------| SA3 Figure (1) Security Associations (SAs) The visited/foreign domain may have a Service Level Agreement (SLA) with the home domain of the mobile user. In that case there should exist an IPsec secure tunnel between the foreign domain and the home domain. Since the foreign domain may have multiple FA's that can be assigned to a MN and similarly there may be multiple HA's that can potentially serve the MN in it's home network it is not practical to have Security Associations (SA's) between every FA and every HA. This kind of a model becomes a management nightmare from a scalability perspective. This draft introduces the concept of a Mobility Control Message Patil, et al. Expires November 2000 [Page 5]
Internet-Draft Securing MIP with IPSec 23 May 2000 Gateway Function (MCMGF). The MGMCF is an entity in the network through which all control plane messages flow. Hence if a network has multiple Foreign Agent's then the control messages from all these FA's directed to HA's in some other network(s) are routed through the MCMGF. The protocol used for communication between the MCMGFs can be DIAMETER or any other protocol. A security association MUST exist between the MCMGF in the visited/foreign domain and the home domain for securing the traffic carried between them. With this configuration there would exist a single SA between the MCMGF's and avoid the "fully meshed" SA configuration that would otherwise have to be setup. 4.1. Virtual Private Network(VPN) with SLA's A Mobile IP service provider may establish SLAs with multiple networks and service providers within which subscribers may roam and access the network. - When SLAs are established between the foreign domain networks and the service providers home network, the MCMGF servers in the networks can be configured with the appropriate policies to create secure IPsec tunnels between these networks. - In effect a VPN is created between the foreign domain networks and the home domain network of the mobile user. This is shown in figure 2 below: Patil, et al. Expires November 2000 [Page 6]
Internet-Draft Securing MIP with IPSec 23 May 2000 ------------------------ | | | [FA]--- | | | ---------| | ------| || | | || | [FA]--------| MCMGF |------ | | || | | ------| || | ------------------------ | | ---------| | | | | [FA]--- | | | ---HA] | | | | |-------- | | ------------------------ |-|-------| || |----- | Visited Network A | |-------|----| | | ------------------------ | | || MCMGF|-------[HA] | | | | |-------|----| | | | [FA]--- | |-|-------| || |----- | | | ---------| |Internet |-------- | | | ------| || | | ---HA] | | | || | | | | [FA]--------| MCMGF || | ------------------------ | | |------ Home Network | ------| || | | ---------| | [FA]--- | | | ------------------------ Visited Network B Figure(2) VPN with SLAs The MCMGF servers in this configuration play the role of a security gateway (for control plane messages) and control plane message concentrator. The FA's and HA's in a network are aware of the local MCMGF server and should route the Mobile IP control plane messages through them. It is beyond the scope of this document to specify how the FA's and HA's learn of or are configured with the address of local MCMGF server. - Policies configured at the FA's or the MCMGF server may indicate that MNs who belong to the domain of service provider 'x', will use these secure tunnels for mobile IP control plane messages. - The Network Access Identifier (NAI) of the MN sent in a Patil, et al. Expires November 2000 [Page 7]
Internet-Draft Securing MIP with IPSec 23 May 2000 registration request allows an FA to determine the home domain of the MN. - The secure tunnels between the MCMGF servers are pre-established and remain in place as long as the SLA's are valid. MCMGF servers in the foreign domain's network and the home domain network are configured with the appropriate security policies which aid in the establishment of this SA. Secure tunnels between the MCMGF servers are mainly based on Encapsulated Security Payload (ESP) in tunnel mode of IPSec. This type of a VPN solution takes care of providing security for control plane messages between different administrative domains as the mobile node roams. It is assumed that the internal security of the private network which is owned by the foreign domain is sufficient for messages between the FA and the local MCMGF server in the network. 5. Mobile Node - Foreign Agent Security Association Mobile IP uses the MN-FA Auth Extension in order to establish secure communication between the MN and the FA. If an FA is capable of establishing an IPSec SA then the agent advertisement can be expanded to indicate this to the MN. The MN can initiate establishment of an IPSec based SA with the the FA. It is recommended that the Aggressive mode of IKE in phase I be used in order to reduce the number of messages exchanged between the MN and the FA. When the MN moves and as a result is in a different administrative domain which causes the MN to register with a new FA, it needs to re-establish the security association by IKE negotiations with the new FA (assuming that the new FA is IPSec capable). By having an IPSec SA between the MN and the FA the MN does not have to be concerned if link layer security mechanisms exist. In wireless networks where link layer security is normally provided for communications over the air interface this adds an additional layer of security to the communications between the MN and the FA. Also the link layer security is between the MN and the base station in the cellular network that is currently serving it. The MN may move and change base stations many times within a single administrative domain of a network but may still be served by the same FA. In the case of wireless networks the delay introduced by the IKE message exchanges in setting up an SA may be unacceptable especially in the case of an active session when the MN moves and a handoff to a new FA occurs which requires the MN to establish an SA with the new FA. An optimized mechanism for key exchange between the MN and the FA Patil, et al. Expires November 2000 [Page 8]
Internet-Draft Securing MIP with IPSec 23 May 2000 for setting up the IPSec SA between these two entities is required, which would be more efficient than IKE. So when does the MN establish the IPSec SA with the FA? - Once the MN has sent a registration request and the HA has responded with an affirmative registration response message and the response message has been received by the MN. - After the MN has successfully registered it should initiate an IKE negotiation with the serving FA to setup an IPSec SA. This implies that the initial registration request message and response message are in the clear but this is not expected to be a security threat even in the case where there could be malicious nodes eavesdropping on the link. In the case where the FA is also the default router for the MN then this SA also provides security for the data plane in addition to the control plane messages between the MN and the FA. The message flow sequence in the figure below illustrates the establishment of the IPSec SA. MN FA MCMGF-Serving MCMGF-Home HA -- -- ------------- ---------- -- Reg_Req --------------> Reg_Req ---------------> Reg_Req --------------> Reg_Req --------------> Reg_Resp Reg_Resp <-------------- Reg_Resp <------------- Reg_Resp <--------------- <------------- IKE (Aggressive mode) <-------------> Quick Mode (SA setup) <-------------> Figure (3) 6. Mobile Node - Home Agent Security Mobile IP provides a security mechanism for authenticating a MN to Patil, et al. Expires November 2000 [Page 9]
Internet-Draft Securing MIP with IPSec 23 May 2000 the HA in the form of the MN-HA Auth extension. In the scenario where there exists an IPSec Security Association between the MN and the FA and another IPSec SA between the domain of the FA and the domain of the HA through the MCMGF servers, it may not be necessary to have an SA between the MN and the HA. However if the MN deems it a requirement for data that is redirected from the HA as a result of triangle routing or when the MN has a co-located care of address and has to do reverse tunneling to the HA because of ingress filtering in the visited domain then the MN may negotiate an IPSec SA with the HA. 7. End-to-End Security between Mobile Node and Correspondent Nodes In the case where fine grain security is deemed a requirement and end-to-end communication between the MN and the CN for the data plane is desired then the MN and the CN can establish an IPSec SA either in tunnel mode ESP or just using Authentication Header in transport mode. The choice depends on the kind of security desired and hence this SA can be considered optional. This type of an SA is possible if the nodes are both configured with the appropriate security policies. This solution has limitations where the address of the MN belongs to a private address space. Other solutions using the NAT in a different manner may be possible. 8. Security Associations with the use of Brokers Establishing SLA's with multiple service providers and networks becomes a complex task from a management perspective. Also it is not possible for a network to be able to establish SLAs with every other network in order to provide roaming on a large scale. Service brokers may exist in the network whose main responsibility would be to establish SLAs with different networks. The service broker hence becomes a consortium of networks and service providers with agreements to allow roaming of their users in each others networks. By joining in an SLA with a service broker, a network gains instant roaming capabilities with other networks that are part of the consortium. In this case, only one SLA need exist between the home network and the service brokers network. In the case of Mobile IP where a service provider belongs to a service brokers consortium the following text describes how mobile users would be able to roam in other networks and how a secure link would be established for control plane messages: Patil, et al. Expires November 2000 [Page 10]
Internet-Draft Securing MIP with IPSec 23 May 2000 - When a mobile node sends a registration request message to a(n) FA in a different administrative domain with which the MNs home network does not have an SLA then the FA forwards the message to the local MCMGF server. - The MCMGF server looks at the NAI of the MN and realizes that it does not have an SLA with the MN's home network. Hence it may decide to consult with the MCMGF server in the service broker's network via a request message[Undefined], if the network associated with the domain of the MN is a part of the service broker's consortium. - The service broker sends a response message[Undefined] to the MCMGF server in the foreign agent's network which contains a session key that is generated for the establishment of a session between the foreign domain and the home domain of the MN while at the same time sending the same session key to the MCMGF server in the home domain of the MN in a different message[undefined]. - It is assumed that there already exists an IPSec security association between the foreign agent's network and the service broker's network, and the MN's home domain network and the service broker's network. Hence this key which will be shared between the two networks is transferred securely over these links. - The MCMGF server in the foreign agent's network is also passed the IP address of the MCMGF server in the home domain of the MN in the response message. - The MCMGF server initiates an IKE negotiation with the MCMGF server in the MN's home network and uses the key given by the service broker for authentication purposes. Once the SA is setup the mobile IP control plane messages are transmitted over this link. With this approach the number of SLAs that a network needs to establish in order to achieve large scale roaming for it's users is very small and easy to maintain. 9. Changes to Mobile IP The solution proposed in this draft would require the following changes to Mobile IP(IPv4): Patil, et al. Expires November 2000 [Page 11]
Internet-Draft Securing MIP with IPSec 23 May 2000 1. The agent advertisement from the FA needs to be enhanced to indicate to a MN if the FA is capable of IPSec and IKE. 2. All the mobility related messages (control plane) between the FA and the HA would have to be redirected through their local MCMGF servers. 10. Security and IPv6 Considerations This draft deals with security for Mobile IP. Mobile IP for IPv6 uses IP Security for it's security solution. 11. Summary With the introduction of mobility into the network security becomes a much more complex task and opens up possibilities for active and passive attacks on the communications. With IPSec now being accepted in networks on a larger scale it is possible to use the security features of IPSec to enable secure Mobile IP communication. In this draft we have discussed the different Mobile IP links that need to be secured and suggested ways to accomplish this using IPSec. Further work on this draft would be in the direction of defining the actual extensions that would have to be done to Mobile IP messages to make this solution viable. 12. Acknowledgements The authors wish to thank Charles Lo and Serge Manning for their input on this draft. Patil, et al. Expires November 2000 [Page 12]
Internet-Draft Securing MIP with IPSec 23 May 2000 13. References [1] Zao, Condell, "Use of IPSec in Mobile IP", Internet Draft, draft-ietf-mobilep-ipsec-use-00.txt, November 1997 [2] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] C. Perkins, "IP Mobility Support", RFC 2002, October 1996 [4] Solomon James, "Mobile IP The Internet Unplugged", Prentice Hall publication [5] Harkins, Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998 [6] Kent, Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [7] Maughan, Schertler, Schneider, Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998 [8] B. Aboba and M. Beadles, RFC 2486: The Network Access Identifier, January 1999. Status: PROPOSED STANDARD [9] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier Extension", draft-ietf-mobileip-mn-nai-02.txt, May 1999 [10] C. Becker, B.Patil, E. Qaddoura, "IP Mobility Architecture Framework", draft-ietf-mobileip-ipm-arch-00.txt, Feb 1999 Patil, et al. Expires November 2000 [Page 13]
Internet-Draft Securing MIP with IPSec 23 May 2000 14. Authors' Addresses Questions about this document can be directed to: Basavaraj Patil Emad Qaddoura Nokia Nortel Networks Inc. 6000 Connection Drive 2201 Lakeside Blvd Irving, TX 75039 Richardson, TX 75082-4399 Phone: +1 972 894-6709 Phone: +1 972 684-2705 E-mail: Basavaraj.Patil@nokia.com E-mail: emadq@nortelnetworks.com Raja Narayanan Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-5707 E-mail: raja@nortelnetworks.com Patil, et al. Expires November 2000 [Page 14]