idnits 2.17.1 draft-bpatil-mobileip-sec-guide-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '... It is inapp...' == Line 190 has weird spacing: '...SA3 may be op...' == Line 236 has weird spacing: '...oviders withi...' == Line 437 has weird spacing: '... in the servi...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2002' on line 81 -- Looks like a reference, but probably isn't: 'CN' on line 196 -- Looks like a reference, but probably isn't: 'MN' on line 200 -- Looks like a reference, but probably isn't: 'FA' on line 200 -- Looks like a reference, but probably isn't: 'MCMGF' on line 200 -- Looks like a reference, but probably isn't: 'HA' on line 200 -- Looks like a reference, but probably isn't: 'Undefined' on line 442 == Unused Reference: '1' is defined on line 508, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 514, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 516, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 525, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 529, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 532, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 536, but no explicit reference was found in the text -- No information found for draft-ietf-mobilep-ipsec-use - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2002 (ref. '3') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. '6') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-02 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 11 errors (**), 0 flaws (~~), 18 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Basavaraj Patil 3 INTERNET-DRAFT Nokia 4 Emad Qaddoura 5 Date: May, 2000 Raja Narayanan 6 Expires: November, 2000 Nortel Networks 8 Security Requirements/Implementation Guidelines for Mobile IP using IP Security 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The IP Security protocol is now well established and is being 35 deployed in the global Internet. The security characteristics of 36 IPSec can be used in Mobile IP networks to enable Mobile IP 37 deployment on a wide area basis and in large networks. Mobile IP 38 should leverage off of the developments of IP Security and Internet 39 Key Exchange (IKE) rather than developing it's own security 40 mechanisms. 42 This draft proposes some concepts on how IP Security can be used to 43 provide an alternative security framework for Mobile IP 44 communications. It is intended to be an implementation guideline. 46 Table Of Contents 48 1 Introduction............................................2 50 2 Terminology.............................................3 52 3 Specification Language..................................4 54 4 Security in Mobile IP Networks..........................4 56 4.1 Virtual Private Network(VPN) with SLA's...............6 58 5 Mobile Node - Foreign Agent Security Association........8 60 6 Mobile Node - Home Agent Security.......................9 62 7 End-to-End Security between MN and CN...................10 64 8 Security Associations with the use of Brokers...........10 66 9 Changes to Mobile IP....................................11 68 10 Security and IPv6 Considerations.......................12 70 11 Summary................................................12 72 12 Acknowledgements.......................................12 74 13 References.............................................13 76 14 Authors' Addresses.....................................14 78 1. Introduction 80 Security is a major concern in today's networks. Mobile IP 81 [RFC2002] enables a user to change his network point of attachment 82 while maintaining network connectivity. Mobility introduces it's 83 own set of security requirements to protect the mobile node from 84 various forms of attack including: 86 1. Session hijacking - A hostile node can steal a session from a 87 mobile node by having packets redirected to it 89 2. Spoofing of identity to obtain access to the network and 90 3. Eavesdropping and stealing of data during sessions 92 This draft proposes a security solution using IP Security(IPSec) 93 for deployment of a Mobile IP network. The security characteristics 94 of IPSec such as connectionless integrity, data origin 95 authentication, anti replay protection and confidentiality can be 96 applied to Mobile IP for securing the data both in the control 97 plane and the data plane. 99 The advantages of such an approach lie in: 101 - Making use of a well defined security protocol and the ease in 102 managing the set of security associations that are established as 103 a virtue of having a service level agreement (SLA) with a 104 network/service provider. 106 - There is a single security association between the visited domain 107 and the home domain for all control plane messages, rather than 108 having a security association between every Foreign Agent and 109 Home Agent in these domains. 111 The draft proposes a complete solution for securing all the links 112 used in mobile IP communications. 114 2. Terminology 116 This document uses the following terminology: 118 Mobile-Node A host that changes its point of attachment 119 from one network or subnetwork to another. A 120 mobile node may change its location without 121 changing its IP address; it may continue to 122 communicate with other Internet nodes at any 123 location using its (constant) IP address, 124 assuming link-layer connectivity to a point of 125 attachment is available. 127 Correspondent-Node A peer with which a mobile node is 128 communicating. A correspondent node may be 129 either mobile or stationary. 131 Home-Agent A router on a mobile node's home network which 132 tunnels datagrams for delivery to the mobile 133 node when it is away from home, and maintains 134 current location information for the mobile 135 node. 137 Foreign-Agent A router on a mobile node's visited network 138 which provides routing services to the mobile 139 node while registered. The foreign agent 140 detunnels and delivers datagrams to the mobile 141 node that were tunneled by the mobile node's 142 home agent. For datagrams sent by a mobile 143 node, the foreign agent may serve as a default 144 router for registered mobile nodes. 146 Home-Domain The home domain is the network with which a 147 mobile user has primary subscription with. 149 Foreign-Domain A network in which the mobile node may be 150 roaming in that does not have knowledge about 151 this user. 153 Security-Association(SA) 154 A Security Association (SA) is a "connection" 155 that affords security services to the traffic 156 carried by it. 158 3. Specification Language 160 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 162 this document are to be interpreted as described in RFC 2119 [2]. 164 4. Security in Mobile IP Networks 166 Mobile IP defines a set of control plane messages that enable a 167 mobile node(MN) to roam between networks and achieve IP mobility. 168 Unlike a conventional telephone network where control plane 169 messages are normally transmitted over a separate control plane 170 link such as SS7, mobile IP messages traverse the same IP network 171 that is publicly accessible (in the case of interdomain roaming). 172 No separate secure network, analogous to the SS7 network, is used 173 by Mobile IP for it's control plane. It is necessary to protect the 174 data in both the control plane and the data plane in order to 175 prevent security attacks on the mobile user. 177 The following four security associations (SAs) shown in Figure (1) 178 are identified for securing Mobile IP communication: 180 1. SA1 - Between the Mobility Control Message Gateway Function 181 (MCMGF) server in the visited/foreign domain and the MCMGF 182 server in the home domain. 184 2. SA2 - Between the MN and the serving FA in the visited domain. 186 3. SA3 - Between the MN and the HA. 188 4. SA4 - Between the MN and the CN for end-to-end security. 190 SA3 may be optional if there exists some other link layer security 191 mechanism between the MN and the FA. SA4 is optional and is 192 established only if policies at the MN require it. 194 SA4 195 |-----------------------------------| 196 | [CN] 197 | Visited/Foreign Ntwk. Home Ntwk. 198 | |--------------| |--------------| 199 | | | |---| | | 200 [MN] | [FA][MCMGF]|-----| |-------|[MCMGF][HA] | 201 | | | | | |---| | | | | 202 | |----|-----|---| Internet |---|-----|----| 203 | SA2 | |-------------------------| | 204 |------------| SA1 | 205 |--------------------------------------------------| 206 SA3 208 Figure (1) Security Associations (SAs) 210 The visited/foreign domain may have a Service Level Agreement (SLA) 211 with the home domain of the mobile user. In that case there should 212 exist an IPsec secure tunnel between the foreign domain and the 213 home domain. Since the foreign domain may have multiple FA's that 214 can be assigned to a MN and similarly there may be multiple HA's 215 that can potentially serve the MN in it's home network it is not 216 practical to have Security Associations (SA's) between every FA and 217 every HA. This kind of a model becomes a management nightmare from 218 a scalability perspective. 220 This draft introduces the concept of a Mobility Control Message 221 Gateway Function (MCMGF). The MGMCF is an entity in the network 222 through which all control plane messages flow. Hence if a network 223 has multiple Foreign Agent's then the control messages from all 224 these FA's directed to HA's in some other network(s) are routed 225 through the MCMGF. The protocol used for communication between the 226 MCMGFs can be DIAMETER or any other protocol. A security 227 association MUST exist between the MCMGF in the visited/foreign 228 domain and the home domain for securing the traffic carried between 229 them. With this configuration there would exist a single SA between 230 the MCMGF's and avoid the "fully meshed" SA configuration that 231 would otherwise have to be setup. 233 4.1. Virtual Private Network(VPN) with SLA's 235 A Mobile IP service provider may establish SLAs with multiple 236 networks and service providers within which subscribers may roam 237 and access the network. 239 - When SLAs are established between the foreign domain networks and 240 the service providers home network, the MCMGF servers in the 241 networks can be configured with the appropriate policies to 242 create secure IPsec tunnels between these networks. 244 - In effect a VPN is created between the foreign domain networks 245 and the home domain network of the mobile user. 247 This is shown in figure 2 below: 249 ------------------------ 250 | | 251 | [FA]--- | 252 | | ---------| 253 | ------| || 254 | | || 255 | [FA]--------| MCMGF |------ 256 | | || | 257 | ------| || | ------------------------ 258 | | ---------| | | | 259 | [FA]--- | | | ---HA] | 260 | | | |-------- | | 261 ------------------------ |-|-------| || |----- | 262 Visited Network A | |-------|----| | | 263 ------------------------ | | || MCMGF|-------[HA] | 264 | | | |-------|----| | | 265 | [FA]--- | |-|-------| || |----- | 266 | | ---------| |Internet |-------- | | 267 | ------| || | | ---HA] | 268 | | || | | | 269 | [FA]--------| MCMGF || | ------------------------ 270 | | |------ Home Network 271 | ------| || 272 | | ---------| 273 | [FA]--- | 274 | | 275 ------------------------ 276 Visited Network B 278 Figure(2) VPN with SLAs 280 The MCMGF servers in this configuration play the role of a security 281 gateway (for control plane messages) and control plane message 282 concentrator. The FA's and HA's in a network are aware of the local 283 MCMGF server and should route the Mobile IP control plane messages 284 through them. It is beyond the scope of this document to specify 285 how the FA's and HA's learn of or are configured with the address 286 of local MCMGF server. 288 - Policies configured at the FA's or the MCMGF server may indicate 289 that MNs who belong to the domain of service provider 'x', will 290 use these secure tunnels for mobile IP control plane messages. 292 - The Network Access Identifier (NAI) of the MN sent in a 293 registration request allows an FA to determine the home domain of 294 the MN. 296 - The secure tunnels between the MCMGF servers are pre-established 297 and remain in place as long as the SLA's are valid. MCMGF servers 298 in the foreign domain's network and the home domain network are 299 configured with the appropriate security policies which aid in 300 the establishment of this SA. Secure tunnels between the MCMGF 301 servers are mainly based on Encapsulated Security Payload (ESP) 302 in tunnel mode of IPSec. 304 This type of a VPN solution takes care of providing security for 305 control plane messages between different administrative domains as 306 the mobile node roams. It is assumed that the internal security of 307 the private network which is owned by the foreign domain is 308 sufficient for messages between the FA and the local MCMGF server 309 in the network. 311 5. Mobile Node - Foreign Agent Security Association 313 Mobile IP uses the MN-FA Auth Extension in order to establish 314 secure communication between the MN and the FA. If an FA is capable 315 of establishing an IPSec SA then the agent advertisement can be 316 expanded to indicate this to the MN. The MN can initiate 317 establishment of an IPSec based SA with the the FA. It is 318 recommended that the Aggressive mode of IKE in phase I be used in 319 order to reduce the number of messages exchanged between the MN and 320 the FA. 322 When the MN moves and as a result is in a different administrative 323 domain which causes the MN to register with a new FA, it needs to 324 re-establish the security association by IKE negotiations with the 325 new FA (assuming that the new FA is IPSec capable). By having an 326 IPSec SA between the MN and the FA the MN does not have to be 327 concerned if link layer security mechanisms exist. In wireless 328 networks where link layer security is normally provided for 329 communications over the air interface this adds an additional layer 330 of security to the communications between the MN and the FA. Also 331 the link layer security is between the MN and the base station in 332 the cellular network that is currently serving it. The MN may move 333 and change base stations many times within a single administrative 334 domain of a network but may still be served by the same FA. In the 335 case of wireless networks the delay introduced by the IKE message 336 exchanges in setting up an SA may be unacceptable especially in the 337 case of an active session when the MN moves and a handoff to a new 338 FA occurs which requires the MN to establish an SA with the new FA. 339 An optimized mechanism for key exchange between the MN and the FA 340 for setting up the IPSec SA between these two entities is required, 341 which would be more efficient than IKE. 343 So when does the MN establish the IPSec SA with the FA? 345 - Once the MN has sent a registration request and the HA has 346 responded with an affirmative registration response message and 347 the response message has been received by the MN. 349 - After the MN has successfully registered it should initiate an 350 IKE negotiation with the serving FA to setup an IPSec SA. 352 This implies that the initial registration request message and 353 response message are in the clear but this is not expected to be a 354 security threat even in the case where there could be malicious 355 nodes eavesdropping on the link. In the case where the FA is also 356 the default router for the MN then this SA also provides security 357 for the data plane in addition to the control plane messages 358 between the MN and the FA. The message flow sequence in the figure 359 below illustrates the establishment of the IPSec SA. 361 MN FA MCMGF-Serving MCMGF-Home HA 362 -- -- ------------- ---------- -- 363 Reg_Req 364 --------------> Reg_Req 365 ---------------> Reg_Req 366 --------------> Reg_Req 367 --------------> 368 Reg_Resp 369 Reg_Resp <-------------- 370 Reg_Resp <------------- 371 Reg_Resp <--------------- 372 <------------- 373 IKE (Aggressive mode) 374 <-------------> 375 Quick Mode (SA setup) 376 <-------------> 378 Figure (3) 380 6. Mobile Node - Home Agent Security 382 Mobile IP provides a security mechanism for authenticating a MN to 383 the HA in the form of the MN-HA Auth extension. 385 In the scenario where there exists an IPSec Security Association 386 between the MN and the FA and another IPSec SA between the domain 387 of the FA and the domain of the HA through the MCMGF servers, it 388 may not be necessary to have an SA between the MN and the HA. 389 However if the MN deems it a requirement for data that is 390 redirected from the HA as a result of triangle routing or when the 391 MN has a co-located care of address and has to do reverse tunneling 392 to the HA because of ingress filtering in the visited domain then 393 the MN may negotiate an IPSec SA with the HA. 395 7. End-to-End Security between Mobile Node and Correspondent Nodes 397 In the case where fine grain security is deemed a requirement and 398 end-to-end communication between the MN and the CN for the data 399 plane is desired then the MN and the CN can establish an IPSec SA 400 either in tunnel mode ESP or just using Authentication Header in 401 transport mode. The choice depends on the kind of security desired 402 and hence this SA can be considered optional. This type of an SA is 403 possible if the nodes are both configured with the appropriate 404 security policies. 406 This solution has limitations where the address of the MN belongs 407 to a private address space. Other solutions using the NAT in a 408 different manner may be possible. 410 8. Security Associations with the use of Brokers 412 Establishing SLA's with multiple service providers and networks 413 becomes a complex task from a management perspective. Also it is 414 not possible for a network to be able to establish SLAs with every 415 other network in order to provide roaming on a large scale. Service 416 brokers may exist in the network whose main responsibility would be 417 to establish SLAs with different networks. The service broker hence 418 becomes a consortium of networks and service providers with 419 agreements to allow roaming of their users in each others networks. 420 By joining in an SLA with a service broker, a network gains instant 421 roaming capabilities with other networks that are part of the 422 consortium. In this case, only one SLA need exist between the home 423 network and the service brokers network. 425 In the case of Mobile IP where a service provider belongs to a 426 service brokers consortium the following text describes how mobile 427 users would be able to roam in other networks and how a secure link 428 would be established for control plane messages: 430 - When a mobile node sends a registration request message to a(n) 431 FA in a different administrative domain with which the MNs home 432 network does not have an SLA then the FA forwards the message to 433 the local MCMGF server. 435 - The MCMGF server looks at the NAI of the MN and realizes that it 436 does not have an SLA with the MN's home network. Hence it may 437 decide to consult with the MCMGF server in the service broker's 438 network via a request message[Undefined], if the network 439 associated with the domain of the MN is a part of the service 440 broker's consortium. 442 - The service broker sends a response message[Undefined] to the 443 MCMGF server in the foreign agent's network which contains a 444 session key that is generated for the establishment of a session 445 between the foreign domain and the home domain of the MN while at 446 the same time sending the same session key to the MCMGF server in 447 the home domain of the MN in a different message[undefined]. 449 - It is assumed that there already exists an IPSec security 450 association between the foreign agent's network and the service 451 broker's network, and the MN's home domain network and the 452 service broker's network. Hence this key which will be shared 453 between the two networks is transferred securely over these 454 links. 456 - The MCMGF server in the foreign agent's network is also passed 457 the IP address of the MCMGF server in the home domain of the MN 458 in the response message. 460 - The MCMGF server initiates an IKE negotiation with the MCMGF 461 server in the MN's home network and uses the key given by the 462 service broker for authentication purposes. 464 Once the SA is setup the mobile IP control plane messages are 465 transmitted over this link. 467 With this approach the number of SLAs that a network needs to 468 establish in order to achieve large scale roaming for it's users is 469 very small and easy to maintain. 471 9. Changes to Mobile IP 473 The solution proposed in this draft would require the following 474 changes to Mobile IP(IPv4): 476 1. The agent advertisement from the FA needs to be enhanced to 477 indicate to a MN if the FA is capable of IPSec and IKE. 479 2. All the mobility related messages (control plane) between the 480 FA and the HA would have to be redirected through their local 481 MCMGF servers. 483 10. Security and IPv6 Considerations 485 This draft deals with security for Mobile IP. Mobile IP for IPv6 486 uses IP Security for it's security solution. 488 11. Summary 490 With the introduction of mobility into the network security becomes 491 a much more complex task and opens up possibilities for active and 492 passive attacks on the communications. With IPSec now being 493 accepted in networks on a larger scale it is possible to use the 494 security features of IPSec to enable secure Mobile IP 495 communication. In this draft we have discussed the different Mobile 496 IP links that need to be secured and suggested ways to accomplish 497 this using IPSec. Further work on this draft would be in the 498 direction of defining the actual extensions that would have to be 499 done to Mobile IP messages to make this solution viable. 501 12. Acknowledgements 503 The authors wish to thank Charles Lo and Serge Manning for their 504 input on this draft. 506 13. References 508 [1] Zao, Condell, "Use of IPSec in Mobile IP", Internet Draft, 509 draft-ietf-mobilep-ipsec-use-00.txt, November 1997 511 [2] Bradner S., "Key words for use in RFCs to Indicate Requirement 512 Levels", RFC 2119, March 1997. 514 [3] C. Perkins, "IP Mobility Support", RFC 2002, October 1996 516 [4] Solomon James, "Mobile IP The Internet Unplugged", Prentice 517 Hall publication 519 [5] Harkins, Carrel, "The Internet Key Exchange (IKE)", RFC 2409, 520 November 1998 522 [6] Kent, Atkinson, "Security Architecture for the Internet 523 Protocol", RFC 2401, November 1998 525 [7] Maughan, Schertler, Schneider, Turner, "Internet Security 526 Association and Key Management Protocol (ISAKMP)", RFC 2408, 527 November 1998 529 [8] B. Aboba and M. Beadles, RFC 2486: The Network Access 530 Identifier, January 1999. Status: PROPOSED STANDARD 532 [9] P. Calhoun and C. Perkins, "Mobile IP Network Access 533 Identifier Extension", draft-ietf-mobileip-mn-nai-02.txt, May 534 1999 536 [10] C. Becker, B.Patil, E. Qaddoura, "IP Mobility Architecture 537 Framework", draft-ietf-mobileip-ipm-arch-00.txt, Feb 1999 539 14. Authors' Addresses 541 Questions about this document can be directed to: 543 Basavaraj Patil Emad Qaddoura 544 Nokia Nortel Networks Inc. 545 6000 Connection Drive 2201 Lakeside Blvd 546 Irving, TX 75039 Richardson, TX 75082-4399 548 Phone: +1 972 894-6709 Phone: +1 972 684-2705 549 E-mail: Basavaraj.Patil@nokia.com E-mail: emadq@nortelnetworks.com 551 Raja Narayanan 552 Nortel Networks Inc. 553 2201 Lakeside Blvd 554 Richardson, TX 75082-4399 556 Phone: +1 972 684-5707 557 E-mail: raja@nortelnetworks.com