One document matched: draft-bpatil-mobileip-sec-guide-01.txt
Differences from draft-bpatil-mobileip-sec-guide-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 05:39:56 |