idnits 2.17.1 draft-ietf-mip4-mobike-connectivity-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 656. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Whenever the mobile node attaches to a new link, it may encounter a foreign agent. The mobile node MUST not use the foreign agent care-of address with the i-HA when attached to an untrusted access network. The default behavior for the mobile node is to always configure an address from the access link using DHCP. The mobile node then checks if it is attached to a trusted access network by sending a registration request to the i-HA in the co-located care-of address mode. If the mobile node discovers that it is attached to a trusted access network, then it MAY start using foreign agent care-of address with the i-HA. In order to do this, the mobile node has to perform a new registration with the i-HA. -- 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.) -- The document date (March 2, 2007) is 6264 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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: 'R' on line 223 -- Looks like a reference, but probably isn't: 'DHCP' on line 223 ** Obsolete normative reference: RFC 3344 (ref. '2') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-ietf-mip4-vpn-problem-solution-02 == Outdated reference: A later version (-03) exists of draft-meghana-mip4-mobike-optimizations-01 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '13') (Obsoleted by RFC 4306) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group V. Devarapalli 3 Internet-Draft Azaire Networks 4 Intended status: Best Current P. Eronen 5 Practice Nokia 6 Expires: September 3, 2007 March 2, 2007 8 Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE 9 draft-ietf-mip4-mobike-connectivity-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 3, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Enterprise users require mobility and secure connectivity when they 43 roam and connect to the services offered in the enterprise. Secure 44 connectivity is required when the user connects to the enterprise 45 from an untrusted network. Mobility is beneficial when the user 46 moves, either inside or outside the enterprise network, and acquires 47 a new IP address. This document describes a solution using Mobile 48 IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure 49 connectivity and mobility. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.1. Access mode: 'h' . . . . . . . . . . . . . . . . . . . 7 58 3.1.2. Access mode: 'c' . . . . . . . . . . . . . . . . . . . 7 59 3.1.3. Access mode: 'f' . . . . . . . . . . . . . . . . . . . 7 60 3.1.4. Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7 61 3.2. Mobility within the enterprise . . . . . . . . . . . . . . 8 62 3.3. Mobility when outside the enterprise . . . . . . . . . . . 8 63 3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 8 64 3.4.1. Operation when moving from an untrusted network . . . 9 65 3.4.2. Operation when moving from a trusted network . . . . . 10 66 4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Appendix A. Applicability to a Mobile Operator Network . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 75 Intellectual Property and Copyright Statements . . . . . . . . . . 15 77 1. Introduction 79 A typical enterprise network consists of users connecting to the 80 services from a trusted network (intranet), and from an untrusted 81 network (Internet). The trusted and untrusted networks are typically 82 separated by a demilitarized zone (DMZ). Access to the intranet is 83 controlled by a firewall and a VPN gateway in the DMZ. 85 Enterprise users, when roaming on untrusted networks, most often have 86 to authenticate themselves to the VPN gateway and set up a secure 87 tunnel in order to access the intranet. The use of IPsec VPNs is 88 very common to enable such secure connectivity to the intranet. When 89 the user is on the trusted network, VPNs are not used. However, the 90 users benefit tremendously when session mobility between subnets, 91 through the use of Mobile IPv4, is available. 93 There has been some work done on using Mobile IPv4 and IPsec VPNs to 94 provide roaming and secure connectivity to an enterprise [6] [7]. 95 The solution described in [6] was designed with certain restrictions, 96 including requiring no modifications to the VPN gateways and involves 97 the use of two layers of MIPv4, with one home agent inside the 98 intranet and one in the Internet or in the DMZ before the VPN 99 gateway. The per-packet overhead is very high in this solution. It 100 is also challenging to implement and have two instances of MIPv4 101 active at the same time on a mobile node. However, the solution 102 described here is only applicable when IKEv2 IPsec VPNs are used. 104 This document describes an alternate solution that does not require 105 two layers of MIPv4. The solution described in this document uses 106 Mobile IPv4 when the mobile node is on the trusted network and MOBIKE 107 capable IPsec VPNs when mobile node is on the untrusted network. The 108 mobile node uses the tunnel inner address (TIA) given out by the 109 IPsec VPN gateway as the co-located CoA for MIPv4 registration. This 110 eliminates the need for using an external MIPv4 home agent and the 111 need for encapsulating the VPN tunnel inside a MIPv4 tunnel. 113 The following assumptions are made for the solution described in this 114 document. 116 o IKEv2 [4] and IPsec [5] are used to set up the VPN tunnels between 117 the mobile node and the VPN gateway. 118 o The VPN gateway and the mobile node support MOBIKE extensions as 119 defined in [3]. 120 o When the mobile node is on the trusted network, traffic should not 121 go through the DMZ. Current deployments of firewalls and DMZs 122 consider the scenario where only a small amount of the total 123 enterprise traffic goes through the DMZ. Routing through the DMZ 124 typically involves stateful inspection of each packet by the 125 firewalls in the DMZ. Moreover, the DMZ architecture assumes that 126 the DMZ is less secure than the internal network. Therefore the 127 DMZ based architecture allows the least amount of traffic to 128 traverse the DMZ, that is, only traffic between the trusted 129 network and the external network. Requiring all normal traffic to 130 the mobile nodes to traverse the DMZ would negate this 131 architecture. 132 o When the mobile node is on the trusted network and uses a wireless 133 access technology, confidentiality protection of the data traffic 134 is provided by the particular access technology. In some 135 networks, confidentiality protection MAY be available between the 136 mobile node and the first hop access router, in which case it is 137 not required at layer 2. 139 This document also presents a solution for the mobile node to detect 140 when it is on a trusted network, so that the IPsec tunnel can be 141 dropped and the mobile node can use Mobile IP in the intranet. 143 IPsec VPN gateways that use IKEv1 [13] are not addressed in this 144 document. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [1]. 152 Many of the following terms are defined in [6], but are repeated here 153 to make this document self-contained. 155 FA: Mobile IPv4 foreign agent 157 CCoA: co-located Care-of address 159 FA-CoA: Foreign Agent Care-of address 161 FW: Firewall 163 i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet) 164 network 166 i-HA: Mobile IPv4 home agent residing in the trusted (intranet) 167 network 169 i-MIP: The mobile node uses the home agent in the internal network 171 VPN TIA: VPN tunnel inner address. This address is given out by the 172 VPN gateway during IKE negotiation and is routable in the trusted 173 network 175 mVPN: VPN with MOBIKE functionality 177 The following access modes are used in explaining the protocol. The 178 access modes are explained in more detail in [6]. 179 f: i-MIP with FA-CoA 180 c: i-MIP with CCoA 181 mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA 183 3. Solution Overview 185 The mobile node is configured with a home address that remains the 186 same irrespective of whether the mobile node is inside or outside the 187 enterprise network. The mobile node is also reachable at the same 188 home address irrespective of its current point of attachment. When 189 the mobile node is connected to the intranet directly, it uses Mobile 190 IP for internal mobility. 192 When the mobile node roams and connects to an untrusted network 193 outside the enterprise, it sets up a VPN tunnel to the VPN gateway. 194 However, it still maintains a valid binding cache entry at the i-HA. 195 It uses the VPN TIA, allocated by the VPN gateway, as the co-located 196 CoA for registration with the i-HA. If the VPN TIA changes or if the 197 mobile node moves and connects to another VPN gateway, then it sends 198 a Registration Request to the i-HA using the new co-located CoA. 200 If the mobile node moves while outside the enterprise and its access 201 network changes, it uses the MOBIKE protocol to update the VPN 202 gateway of its current address. The internal home agent is not aware 203 of the mobile node's movement as long as the mobile node is attached 204 to the same VPN gateway and the TIA remains the same. 206 Figure 1 depicts the network topology assumed for the solution. It 207 also shows the possible mobile node locations and access modes. 209 {h} (MN) [i-HA] 210 \ / 211 .-+---+-. 212 ( ) 213 [mVPN] `--+----' 214 ! ! 215 .--+--. [R] 216 ( DMZ ) ! 217 .-+-------+--. `--+--' .-----+------. 218 ( ) ! ( ) 219 ( external net +---[R]----[FW]----[R]--+ internal net ) 220 ( ) ( ) 221 `--+---------' `---+---+----' 222 / / \ 223 [DHCP] [R] [DHCP] [R] [R] [i-FA] 224 \ / \ / \ / 225 .+--+---. .-+-+--. .--+--+-. 226 ( ) ( ) ( ) 227 `---+---' `--+---' `---+---' 228 ! ! ! 229 (MN) {mc} (MN) {c} (MN) {f} 231 Figure 1: Network Topology using MIPv4 and MOBIKE 233 The solution described above results in a Mobile IP tunnel inside an 234 IPsec tunnel. The Mobile IP tunnel is between the mobile node and 235 the home agent and the IPsec tunnel is between the MN and the mVPN 236 gateway. The mobile node MUST reverse tunnel through the home agent 237 [8] when the Mobile IP tunnel is inside an IPsec tunnel. 239 The overhead of running a Mobile IP tunnel inside an IPsec tunnel can 240 be avoided by having the Mobile IP foreign agent functionality on the 241 VPN gateway. This is out of scope for this document and is further 242 described in [9]. 244 Whenever the mobile node attaches to a new link, it may encounter a 245 foreign agent. The mobile node MUST not use the foreign agent 246 care-of address with the i-HA when attached to an untrusted access 247 network. The default behavior for the mobile node is to always 248 configure an address from the access link using DHCP. The mobile 249 node then checks if it is attached to a trusted access network by 250 sending a registration request to the i-HA in the co-located care-of 251 address mode. If the mobile node discovers that it is attached to a 252 trusted access network, then it MAY start using foreign agent care-of 253 address with the i-HA. In order to do this, the mobile node has to 254 perform a new registration with the i-HA. 256 The mobile node can use a foreign agent on a untrusted access 257 network, if there is an external home agent that the mobile node is 258 able to use. The use of an external home agent in the untrusted 259 access network and a home agent in the trusted access network at the 260 same time is described in detail in [6]. 262 Some IPsec VPN implementations allow a host to send traffic directly 263 to the Internet when attached to an untrusted network. This traffic 264 bypasses the IPsec tunnel with the VPN gateway. This document does 265 not prevent such traffic from being sent out from the host, but there 266 will be no mobility or session continuity for the traffic. Any data 267 traffic that is sent through the Mobile IP tunnel with the home agent 268 is always sent through the VPN gateway. 270 3.1. Access modes 272 The following access modes are used in the solution described in this 273 document. 275 3.1.1. Access mode: 'h' 277 This access mode is standard Mobile IPv4 [2] when the mobile node is 278 attached to its home link. The mobile node must detect that it is 279 connected to home link before using this mode. 281 3.1.2. Access mode: 'c' 283 This access mode is standard Mobile IPv4 [2] with a co-located 284 care-of address. The mobile node must detect that it is connected to 285 an internal trusted network before using this mode. The co-located 286 care-of address is assigned by the access network to which the mobile 287 node is attached to. 289 3.1.3. Access mode: 'f' 291 This access mode is standard Mobile IPv4 [2] with a foreign agent 292 care-of address. The mobile node can use this mode only when it 293 detects that it is connected to an internal trusted network and also 294 detects a foreign agent on the access network. 296 3.1.4. Access mode: 'mc' 298 This access mode involves using both Mobile IPv4 and a MOBIKE enabled 299 IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec 300 tunnel. The mobile node uses the VPN TIA as the co-located CoA for 301 registering with the home agent. This mode is used only when the 302 mobile node is attached to an untrusted network and is required to 303 set up an IPsec tunnel with a VPN gateway to gain access to the 304 trusted network. 306 3.2. Mobility within the enterprise 308 When the mobile node is inside the enterprise network and attached to 309 the intranet, it uses Mobile IPv4 [2] for subnet mobility. The 310 mobile node always configures a care-of address address through DHCP 311 on the access link and uses it as the co-located care-of address. 312 The mobile node MAY use a foreign agent care-of address, if a foreign 313 agent is available. However, the foreign agent care-of address is 314 used only when the mobile node is attached to the trusted access 315 network. The mobile node attempts Foreign Agent discovery and CoA 316 address acquisition through DHCP simultaneously in order to avoid the 317 delay in discovering a foreign agent when there is no foreign agent 318 available. The mobile node maintains a valid binding cache entry at 319 all times at the home agent mapping the the home address to the 320 current CoA. Whenever the mobile node moves, it sends a Registration 321 Request to update the binding cache entry. 323 The Mobile IP signaling messages between the mobile node and the home 324 agent are authenticated as described in [2]. 326 The mobile node maintains a valid binding cache entry at the home 327 agent even when it is outside the enterprise network. 329 3.3. Mobility when outside the enterprise 331 When the mobile node is attached to an untrusted network, it sets up 332 an IPsec VPN tunnel with the VPN gateway to gain access to the 333 enterprise network. If the mobile node moves and its IP address 334 changes, it initiates the MOBIKE protocol [3] to update the address 335 on the VPN gateway. 337 The mobile node maintains a binding at the home agent even when it is 338 outside the enterprise network. If the TIA changes due to the mobile 339 node re-connecting to the VPN gateway or attaching to a different VPN 340 gateway, the mobile node should send a Registration Request to its 341 home agent to update the binding cache with the new TIA. 343 3.4. Crossing Security Boundaries 345 Security boundary detection is based on the reachability of the i-HA 346 from the mobile node's current point of attachment. Whenever the 347 mobile node detects a change in network connectivity, it sends a 348 Registration Request to the i-HA without any VPN encapsulation. If 349 the mobile node receives a Registration Reply, then it assumes that 350 it is on a trusted network. The mobile node MUST check that the 351 Registration Reply is integrity protected using the mobile node-home 352 agent mobility security association before concluding it is attached 353 to a trusted network. This security boundary detection is based on 354 the mechanism described in [6] to detect attachment to the internal 355 trusted network. The mobile node should re-transmit the Registration 356 Request if it does not receive the Registration Reply within a 357 timeout period. The number of times the mobile node should re- 358 transmit the Registration Request and the timeout period for 359 receiving the Registration Reply are configurable on the mobile node. 361 When the mobile node is attached to an untrusted network and is using 362 an IPsec VPN to the enterprise network, the ability to send a 363 Registration Request to the i-HA without VPN encapsulation would 364 require some interaction between the IPsec and MIPv4 modules on the 365 mobile node. This is local to the mobile node and out of scope for 366 this document. 368 If the mobile node has an existing VPN tunnel to its VPN gateway, it 369 MUST send a MOBIKE message at the same time as the registration 370 request to the i-HA whenever the IP address changes. If the mobile 371 node receives a response from the VPN gateway, but not from the i-HA, 372 it assumes it is outside the enterprise network. If it receives a 373 response from the i-HA, then it assumes it is inside the enterprise 374 network. 376 There could also be some out-of-band mechanisms that involve 377 configuring the wireless access points with some information which 378 the mobile node can recognize as access points that belong to the 379 trusted network in an enterprise network. Such mechanisms are beyond 380 the scope of this document. 382 The mobile node should not send any normal traffic while it is trying 383 to detect whether it is attached to the trusted or untrusted network. 384 This is described in more detail in [6]. 386 3.4.1. Operation when moving from an untrusted network 388 When the mobile node is outside the enterprise network and attached 389 to an untrusted network, it has an IPsec VPN tunnel with its mobility 390 aware VPN gateway, and a valid registration with a home agent on the 391 intranet with the VPN TIA as the care-of address. 393 If the mobile nodes moves and its IP address changes, it performs the 394 following steps: 396 1a. Initiate an IKE mobility exchange to update the VPN gateway with 397 the current address. If the new network is also untrusted, this 398 will be enough for setting up the connectivity. If the new 399 network is trusted, and if the VPN gateway is reachable, this 400 exchange will allow the mobile node to keep the VPN state alive 401 while on the trusted side. If the VPN gateway is not reachable 402 from inside, then this exchange will fail. 403 1b. At the same time as step 1, send a Mobile IPv4 Registration 404 Request to the internal home agent without VPN encapsulation. 405 2. If the mobile node receives a Registration Reply to the request 406 sent in step 1b, then the current subnet is a trusted subnet, and 407 the mobile node can communicate without VPN tunneling. The mobile 408 node MAY tear down the VPN tunnel. 410 3.4.2. Operation when moving from a trusted network 412 When the mobile node is inside the enterprise and attached to the 413 intranet, it does not use a VPN tunnel for data traffic. It has a 414 valid binding cache entry at its home agent. If the VPN gateway is 415 reachable from the trusted network, the mobile node MAY have valid 416 IKEv2 security associations with its VPN gateway. The IPsec security 417 associations can be created when required. The mobile node may have 418 to re-negotiate the IKEv2 security associations to prevent them from 419 expiring. 421 If the mobile node moves and its IP address changes, it performs the 422 following steps: 424 1. Initiate an IKE mobility exchange to update the VPN gateway with 425 the current address, or if there is no VPN connection, then 426 establish a VPN tunnel with the gateway from the new local IP 427 address. If the new network is trusted, and if the VPN gateway 428 is reachable, this exchange will allow the mobile node to keep 429 the VPN state alive, while in the trusted side. If the new 430 network is trusted and if the VPN gateway is not reachable from 431 inside, then this exchange will fail. 432 2. At the same time as step 1, send a Mobile IPv4 Registration 433 Request to the internal home agent without VPN encapsulation. 434 3. If the mobile node receives a Registration Reply to the request 435 sent in step 2, then the current subnet is a trusted subnet, and 436 the mobile node can communicate without VPN tunneling, using only 437 Mobile IP with the new care-of address. 438 4. If the mobile node didn't receive the response in step 3, and if 439 the VPN tunnel is successfully established and registered in step 440 1, then the mobile node sends a Registration Request over the VPN 441 tunnel to the internal home agent. After receiving a 442 Registration Reply from the home agent, the mobile node can start 443 communicating over the VPN tunnel with the Mobile IP home 444 address. 446 4. NAT Traversal 448 There could be a NAT device between the mobile node and the home 449 agent in any of the access modes, 'c', 'f' and 'mc', and between the 450 mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 451 NAT traversal, as described in [10] should be used by the mobile node 452 and the home agent in access modes 'c' or 'f', when there is a NAT 453 device present. When using access mode, 'mc', IPsec NAT traversal 454 [11] [12] should be used by the mobile node and the VPN gateway, if 455 there is a NAT device present. Typically, the TIA would be a 456 routable address inside the enterprise network. But in some cases, 457 the TIA could be from a private address space associated with the VPN 458 gateway. In such a case, Mobile IPv4 NAT traversal should be used in 459 addition to IPsec NAT traversal in the 'mc' mode. 461 5. Security Considerations 463 Enterprise connectivity typically requires very strong security, and 464 the solution described in this document was designed keeping this in 465 mind. 467 Security concerns related to the mobile node detecting that it is on 468 a trusted network and thereafter dropping the VPN tunnel are 469 described in [6]. 471 When the mobile node sends a registration request to the i-HA from an 472 untrusted network that does not go through the IPsec tunnel, it will 473 reveal the i-HA's address, its own identity including the NAI and the 474 home address, and the Authenticator value in the authentication 475 extensions to the untrusted network. This may be a concern in some 476 deployments. 478 Please see [3] for MOBIKE-related security considerations, and [10], 479 [11] for security concerns related to the use of NAT traversal 480 mechanisms for Mobile IPv4 and IPsec. 482 6. IANA Considerations 484 This document requires no action from IANA. 486 7. Acknowledgments 488 The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval 489 Shah and John Cruz for their participation in developing this 490 solution. 492 The authors would also like to thank Henrik Levkowetz, Jari Arkko, TJ 493 Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni 494 Korhonen and Sami Vaarala for reviewing the document. 496 8. References 498 8.1. Normative References 500 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 501 Levels", BCP 14, RFC 2119, March 1997. 503 [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 504 August 2002. 506 [3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 507 RFC 4555, June 2006. 509 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 510 RFC 4306, December 2005. 512 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 513 Protocol", RFC 4301, December 2005. 515 [6] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across 516 IPsec-based VPN Gateways", 517 draft-ietf-mip4-vpn-problem-solution-02 (work in progress), 518 November 2005. 520 8.2. Informative References 522 [7] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 523 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, 524 August 2005. 526 [8] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", 527 RFC 3024, January 2001. 529 [9] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure 530 Connectivity and Mobility", 531 draft-meghana-mip4-mobike-optimizations-01 (work in progress), 532 October 2006. 534 [10] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network 535 Address Translation (NAT) Devices", RFC 3519, May 2003. 537 [11] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 538 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 539 January 2005. 541 [12] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 542 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, 543 January 2005. 545 [13] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 546 RFC 2409, November 1998. 548 Appendix A. Applicability to a Mobile Operator Network 550 The solution described in this document can also be applied to a 551 Mobile Operator's network when the Operator deploys heterogeneous 552 access networks and some of the access networks are considered as 553 trusted networks and others as untrusted networks. Figure 2 554 illustrates such a network topology. 556 +----------------------+ 557 | +----+ | 558 +----------------+ | |i-HA| | 559 | | | +----+ | 560 (MN)----+ trusted +---+ | 561 | access network | | internal network | 562 +----------------+ | | 563 | | 564 +----------+-----------+ 565 | 566 | 567 | 568 [mVPN] 569 +----------------+ | 570 | | | 571 (MN)----+ untrusted +--------------+ 572 {mc} | access network | 573 +----------------+ 575 Figure 2: Network Topology of a Mobile Operator with trusted and 576 untrusted networks 578 An IPsec VPN gateway provides secure connectivity to the Operator's 579 internal network for mobile nodes attached to an untrusted access 580 network. The VPN gateway supports MOBIKE extensions so that the 581 IPsec tunnels survive any IP address change when the mobile node 582 moves while attached to the untrusted access networks. 584 When the mobile node is attached to the trusted access network it 585 uses Mobile IP with the i-HA. It uses the IP address obtained from 586 the trusted access network as the co-located care-of address to 587 register with the i-HA. If a foreign agent is available in the 588 trusted access network, the mobile node may use foreign agent care-of 589 address. If the mobile node moves and attaches to an untrusted 590 access network, it sets up an IPsec tunnel with the VPN gateway to 591 access the Operator's internal network. It uses the IPsec TIA as the 592 co-located care-of address to register with the i-HA thereby creating 593 a Mobile IP tunnel inside an IPsec tunnel. 595 When the mobile node is attached to the trusted access network, it 596 can either by attached to a foreign link in the trusted network or to 597 the home link directly. This document does not impose any 598 restrictions. 600 Authors' Addresses 602 Vijay Devarapalli 603 Azaire Networks 604 3121 Jay Street 605 Santa Clara, CA 95054 606 USA 608 Email: vijay.devarapalli@azairenet.com 610 Pasi Eronen 611 Nokia Research Center 612 P.O. Box 407 613 FIN-00045 Nokia Group 614 Finland 616 Email: pasi.eronen@nokia.com 618 Full Copyright Statement 620 Copyright (C) The IETF Trust (2007). 622 This document is subject to the rights, licenses and restrictions 623 contained in BCP 78, and except as set forth therein, the authors 624 retain all their rights. 626 This document and the information contained herein are provided on an 627 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 628 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 629 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 630 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 631 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 632 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 634 Intellectual Property 636 The IETF takes no position regarding the validity or scope of any 637 Intellectual Property Rights or other rights that might be claimed to 638 pertain to the implementation or use of the technology described in 639 this document or the extent to which any license under such rights 640 might or might not be available; nor does it represent that it has 641 made any independent effort to identify any such rights. Information 642 on the procedures with respect to rights in RFC documents can be 643 found in BCP 78 and BCP 79. 645 Copies of IPR disclosures made to the IETF Secretariat and any 646 assurances of licenses to be made available, or the result of an 647 attempt made to obtain a general license or permission for the use of 648 such proprietary rights by implementers or users of this 649 specification can be obtained from the IETF on-line IPR repository at 650 http://www.ietf.org/ipr. 652 The IETF invites any interested party to bring to its attention any 653 copyrights, patents or patent applications, or other proprietary 654 rights that may cover technology that may be required to implement 655 this standard. Please address the information to the IETF at 656 ietf-ipr@ietf.org. 658 Acknowledgment 660 Funding for the RFC Editor function is provided by the IETF 661 Administrative Support Activity (IASA).