idnits 2.17.1 draft-meghana-mip4-mobike-optimizations-01.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 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 452. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 19, 2006) is 6392 days in the past. Is this intentional? 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: 'R' on line 202 -- Looks like a reference, but probably isn't: 'DHCP' on line 202 == Outdated reference: A later version (-03) exists of draft-ietf-mip4-mobike-connectivity-01 ** Obsolete normative reference: RFC 3344 (ref. '3') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 4306 (ref. '5') (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-ietf-mip4-vpn-problem-solution-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group M. Sahasrabudhe 3 Internet-Draft Nokia 4 Intended status: Standards Track V. Devarapalli 5 Expires: April 22, 2007 Azaire Networks 6 October 19, 2006 8 Optimizations to Secure Connectivity and Mobility 9 draft-meghana-mip4-mobike-optimizations-01 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 April 22, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Users that need to connect to their enterprise network from an 43 untrusted network require secure connectivity and mobility. 44 Enterprise users are increasingly using mobile nodes. A user may 45 need to connect to the enterprise network from anywhere, and in a 46 number of scenarios, from untrusted networks. There are existing 47 specifications developed by the Mobile IPv4 working group that 48 describe solutions for enterprise secure connectivity and mobility. 50 This document proposes optimizations to those solutions to reduce the 51 tunneling overhead and allow for a number of new access modes. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Access mode: 'fvf' . . . . . . . . . . . . . . . . . . . . 6 60 3.3. Access mode: 'cvf' . . . . . . . . . . . . . . . . . . . . 7 61 3.4. Access mode: 'mf' . . . . . . . . . . . . . . . . . . . . 7 62 4. Home Address as IPsec TIA . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 Intellectual Property and Copyright Statements . . . . . . . . . . 11 71 1. Introduction 73 It is assumed that the reader is familiar with the use of MIP4 and 74 MOBIKE to provide security connectivity and mobility to an enterprise 75 user [2]. This document talks about optimizations to the solution 76 proposed in [2] and also to [6]. An enterprise user authenticates to 77 the VPN gateway from an untrusted network to gain access to the 78 services on the enterprise network. While inside the network, a user 79 doesn't need to use the VPN gateway. When a user roams in and out 80 from a trusted to an untrusted network the sessions currently active 81 should not drop and the change in connectivity should be seamless to 82 the user. 84 The solution in [2] elaborates that the user uses only Mobile IPv4 85 [3] when inside the enterprise network and uses IPsec VPNs with 86 MOBIKE extensions to IKEv2 when roaming outside the enterprise 87 network to have access to the services provided by the enterprise. 88 Point to note is that this solution does not support legacy IPsec 89 VPNs. The VPN gateways have to implement mobility extensions to 90 IKEv2 [4]. The solution also does not require multiple Home Agents 91 or a Home Agent in the DMZ. The Home Agent is always located inside 92 the enterprise network. The tunnel inner address of the IPsec tunnel 93 is used as the MIPv4 co-located care of address (CCoA). As long as 94 the mobile node is connected to the same VPN gateway and its TIA 95 remains the same, there is no change in the CoA used by the mobile 96 node. When the mobile node moves to a new VPN gateway or gets a new 97 TIA, it updates its home agent with its new CCoA. 99 The packet format for packets sent from the mobile node to a 100 correspondent node, when the mobile node is outside the enterprise, 101 looks as follows 103 IPv4 hdr (src=IPA, dst=VPN_GW) 104 ESP Hdr 105 IPv4 hdr (src=TIA, dst=HA) 106 IPv4 hdr (src=HoA, dst=CN) 107 Payload 109 From the VPN gateway to the correspondent node the packet looks as 110 follows 112 IPv4 hdr (src=TIA, dst=HA) 113 IPv4 hdr (src=HoA, dst=CN) 114 Payload 116 When the mobile node is inside the enterprise the packet format looks 117 as follows 118 IPv4 hdr (src=IPA, dst=HA) 119 IPv4 hdr (src=HoA, dst=CN) 120 Payload 122 There is additional tunneling overhead when the mobile node is 123 roaming in an untrusted network. This overhead can be avoided by 124 having the Mobile IPv4 Foreign Agent functionality on the VPN 125 gateway. This would avoid having to encapsulate a Mobile IP tunnel 126 inside an IPsec tunnel. The following sections describe an optimized 127 connectivity and roaming solution that reduces the packet overhead 128 from the solution described in [2]. 130 2. Terminology 132 i-MIP: Mobile IP layer used for internal enterprise mobility. Home 133 Agent is inside the enterprise network. 135 x-MIP: Mobile IP layer used for access from outside the enterprise 136 network. Home Agent resides either in the Internet or in the DMZ 137 before the VPN gateway looking from the Internet 139 i-HA: Home Agent inside the enterprise network 141 x-HA: Home Agent outside the enterprise network 143 i-FA: Mobile IPv4 foreign agent residing in the trusted enterprise 144 network 146 FA CoA: Foreign Agent mode care of address 148 cCoA: co-located care of address 150 HoA: Home address 152 TIA: Tunnel Inner Address, the address given out to the mobile node 153 by the VPN gateway during IKE setup 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [1]. 159 3. Solution Overview 161 The optimization proposed in this document places the Foreign Agent 162 on the VPN gateway. This reduces the tunnel overhead as the 163 additional tunneling from the TIA to the Home Agent is not required. 165 When the VPN gateway receives the packet from the mobile node, it 166 removes the IPsec header and the FA functionality on the VPN GW 167 encapsulates the original packet and sends it to the Home Agent 168 inside the enterprise. 170 The packet format from the mobile node to the VPN gateway now looks 171 as follows 173 IPv4 hdr (src=IPA, dst=VPN_GW/FA) 174 ESP hdr 175 IPv4 hdr (src=HoA, dst=CN) 176 Payload 178 From the VPN gateway to the correspondent node the packet looks as 179 follows 181 IPv4 hdr (src=VPN_GW/FA, dst=HA) 182 IPv4 hdr (src=HoA, dst=CN) 183 Payload 185 Figure 6 depicts the network topology assumed for the solution. It 186 also shows the possible mobile node locations and access modes. 188 (MN) {mf} {home} (MN) [i-HA] 189 ! \ / 190 .--+---. .-+---+-. 191 ( ) ( ) 192 `--+---' [MVPN/FA] `--+----' 193 \ ! ! 194 [R/FA] .--+--. [R] 195 \ ( DMZ ) ! 196 .-+-------+--. `--+--' .-----+------. 197 ( ) ! ( ) 198 ( external net +---[R]----[FW]----[R]--+ internal net ) 199 ( ) ( ) 200 `--+---------' `---+---+----' 201 / / \ 202 [DHCP] [R] [DHCP] [R] [R] [i-FA] 203 \ / \ / \ / 204 .+--+---. .-+-+--. .--+--+-. 205 ( ) ( ) ( ) 206 `---+---' `--+---' `---+---' 207 ! ! ! 208 (MN) {mf} (MN) {c} (MN) {f} 210 Figure 6: Network Topology with FA colocated on VPN gateway 212 The tunnel overhead reduction is significant especially if the mobile 213 node is connected over a wireless network. The optimization 214 requirement of co-locating the Foreign Agent with the VPN gateway can 215 place the FA multiple hops away from the mobile node. FA 216 availability is hence an issue here. The FA still has to be on link 217 for the mobile node to receive Agent Advertisement messages. There 218 already exists a tunnel interface between the mobile node and the VPN 219 gateway. This tunnel interface can be used so the FA can appear just 220 one hope away and on link to the mobile node. The FA sends out Agent 221 Advertisement messages on the tunnel interface. The mobile node too 222 can send out MIP control messages to the FA on the tunnel interface. 224 3.1. Access modes 226 The access modes possible in [1] are 228 f: i-MIP with FA-CoA 229 c: i-MIP with CCoA 230 mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA 232 The additional access modes possible with the optimizations in this 233 document are 235 fvf: x-MIP with FA CoA/ VPN/ i-MIP with FA CoA 236 cvf: x-MIP with CCoA/VPN/ i-MIP with FA CoA 237 mf: mobile enhanced VPN, i-MIP with FA CoA 239 3.2. Access mode: 'fvf' 241 In this access mode there are two home agents. One Home Agent is 242 located inside the enterprise and one outside the enterprise in the 243 internet or the DMZ before the VPN gateway looking from the internet. 244 In this mode the mobile node uses the external care-of address 245 (x-FACoA) and an external home address (x-HoA). Packets are first 246 tunneled to the external home Agent, then to the VPN gateway and 247 eventually to the internal home Agent. 249 Packet format from the mobile node to the VPN gateway looks as 250 follows: 252 IPv4 hdr (src=x-FA-CoA, dst=x-HA) 253 IPv4 hdr (src=i-HoA, dst=VPN_GW/FA) 254 ESP hdr 255 IPv4 hdr (src=i-HoA, dst=CN) 256 Payload 258 Packet format from the VPN gateway to the correspondent node looks as 259 follows: 261 IPv4 hdr (src=VPN_GW/FA, dst=i-HA) 262 IPv4 hdr (src=i-HoA, dst=CN) 263 Payload 265 3.3. Access mode: 'cvf' 267 There are two home agents here also. One Home Agent is located 268 inside the enterprise and one outside the enterprise in the internet 269 or the DMZ before the VPN gateway looking from the internet. In this 270 mode tme mobile node uses the external co-located care-of address 271 (x-cCoA) and an external home address ( x-HoA).Packets are first 272 tunneled to the external home Agent, then to the VPN gateway and 273 eventually to the internal home Agent. 275 Packet format from the mobile node to the VPN gateway looks as 276 follows: 278 IPv4 hdr (src=x-cCoA, dst=x-HA) 279 IPv4 hdr (src=i-HoA, dst=VPN_GW/FA) 280 ESP hdr 281 IPv4 hdr (src=i-HoA, dst=CN) 282 Payload 284 Packet format from the VPN gateway to the correspondent node looks as 285 follows 287 IPv4 hdr (src=VPN_GW/FA, dst=i-HA) 288 IPv4 hdr (src=i-HoA, dst=CN) 289 Payload 291 3.4. Access mode: 'mf' 293 In this mode the VPN gateway is mobility aware in the sense that it 294 also implements MOBIKE extensions in addition to being a Foreign 295 Agent. The mobile node uses the TIA as a co-located care-of address. 297 Packet format from mobile node to the VPN GW/FA looks as follows: 299 IPv4 hdr (src=IPA, dst=VPN_GW/FA) 300 ESP hdr 301 IPv4 hdr (src=TIA, dst=HA) 302 IPv4 hdr (src=HoA, dst=CN) 303 Payload 305 Packet format from the VPN gateway to the correspondent node looks as 306 follows: 308 IPv4 hdr (TIA, dst=i-HA) 309 IPv4 hdr (src=i-HoA, dst=CN) 310 Payload 312 The advantage in using access modes 1 and 2 is that these can still 313 be used with legacy IPsec VPNs. Hence these can be deployed in 314 existing enterprise networks that may have already invested heavily 315 in legacy VPNs and would be reluctant to upgrade the VPN gateways in 316 the enterprise network. 318 4. Home Address as IPsec TIA 320 When the mobile node sets up an IPsec tunnel with the VPN gateway it 321 is allocated a tunnel inner address (TIA). The TIA is used as the 322 source address for all traffic sent through the IPsec tunnel. The 323 tunnel mode IPsec security associations are created based on TIA. 324 But when a foreign agent functionality exists on the VPN gateway, the 325 mobile node MUST use the home address as the source address on the 326 data traffic. Moreover, the optimization described in Section 3.4 is 327 possible only if the home address is equal to the TIA. 329 In order for the home address to be equal to the TIA, there is a need 330 for close interaction between the IKEv2 implementation and Foreign 331 agent implementation on the VPN gateway. This may not be possible 332 with all implementations, since the IPsec tunnel setup happens before 333 an Foreign Agent Advertisement can be sent over the IPsec tunnel to 334 the mobile node. One possible solution would be to allocate a TIA 335 when the IPsec tunnel is setup and later replace the TIA with the 336 home address. This would require updating the IPsec SAs with the new 337 home address. But this would violate RFC 4301 [8] which says the TIA 338 cannot be changed without rendering the tunnel mode IPsec SAs 339 invalid. 341 A simple solution would be for the mobile node to setup an IPsec 342 tunnel with the TIA allocated by the VPN gateway, and then run a 343 separate CREATE_CHILD_SA exchange [5] to setup new tunnel mode IPsec 344 security associations for the home address. This would however 345 introduce additional delay in the form of an additional 346 CREATE_CHILD_SA exchange when the mobile node connects to the 347 enterprise network from outside. The security associations created 348 earlier for the TIA may be either torn down or allowed to expire 349 based on the configuration on the mobile node and the VPN gateway. 351 5. Security Considerations 353 The solution described in this document does not introduce any new 354 security vulnerabilities on top of what is described in the security 355 considerations sections of [2], [6] and [7]. 357 6. IANA Considerations 359 This document requires no action from IANA. 361 7. References 363 7.1. Normative References 365 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 366 Levels", BCP 14, RFC 2119, March 1997. 368 [2] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility 369 using Mobile IPv4 and MOBIKE", 370 draft-ietf-mip4-mobike-connectivity-01 (work in progress), 371 June 2006. 373 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 374 August 2002. 376 [4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 377 RFC 4555, June 2006. 379 [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 380 December 2005. 382 7.2. Informative References 384 [6] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across 385 IPsec-based VPN Gateways", 386 draft-ietf-mip4-vpn-problem-solution-02 (work in progress), 387 November 2005. 389 [7] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 390 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, 391 August 2005. 393 [8] Kent, S. and K. Seo, "Security Architecture for the Internet 394 Protocol", RFC 4301, December 2005. 396 Authors' Addresses 398 Meghana Sahasrabudhe 399 Nokia 400 313 Fairchild Drive 401 Mountain View, CA 94043 402 USA 404 Email: meghana.saha@nokia.com 406 Vijay Devarapalli 407 Azaire Networks 408 4800 Great America Parkway 409 Santa Clara, CA 95054 410 USA 412 Email: vijay.devarapalli@azairenet.com 414 Full Copyright Statement 416 Copyright (C) The Internet Society (2006). 418 This document is subject to the rights, licenses and restrictions 419 contained in BCP 78, and except as set forth therein, the authors 420 retain all their rights. 422 This document and the information contained herein are provided on an 423 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 424 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 425 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 426 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 427 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 428 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 430 Intellectual Property 432 The IETF takes no position regarding the validity or scope of any 433 Intellectual Property Rights or other rights that might be claimed to 434 pertain to the implementation or use of the technology described in 435 this document or the extent to which any license under such rights 436 might or might not be available; nor does it represent that it has 437 made any independent effort to identify any such rights. Information 438 on the procedures with respect to rights in RFC documents can be 439 found in BCP 78 and BCP 79. 441 Copies of IPR disclosures made to the IETF Secretariat and any 442 assurances of licenses to be made available, or the result of an 443 attempt made to obtain a general license or permission for the use of 444 such proprietary rights by implementers or users of this 445 specification can be obtained from the IETF on-line IPR repository at 446 http://www.ietf.org/ipr. 448 The IETF invites any interested party to bring to its attention any 449 copyrights, patents or patent applications, or other proprietary 450 rights that may cover technology that may be required to implement 451 this standard. Please address the information to the IETF at 452 ietf-ipr@ietf.org. 454 Acknowledgment 456 Funding for the RFC Editor function is provided by the IETF 457 Administrative Support Activity (IASA).