idnits 2.17.1 draft-ietf-mip4-vpn-problem-solution-05.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 1947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1965. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1971. 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 -- 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 14, 2008) is 5881 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) -- Missing reference section? 'VPN' on line 424 looks like a reference -- Missing reference section? 'R' on line 434 looks like a reference -- Missing reference section? 'DHCP' on line 434 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP S. Vaarala 3 Internet-Draft Codebay 4 Intended status: Standards Track E. Klovning 5 Expires: September 15, 2008 Birdstep 6 March 14, 2008 8 Mobile IPv4 Traversal Across IPsec-based VPN Gateways 9 draft-ietf-mip4-vpn-problem-solution-05 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 15, 2008. 36 Abstract 38 This document outlines a solution for the Mobile IPv4 and IPsec 39 coexistence problem for enterprise users. The solution consists of 40 an applicability statement for using Mobile IPv4 and IPsec for 41 session mobility in corporate remote access scenarios, and a required 42 mechanism for detecting the trusted internal network securely. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 1.3. Related work . . . . . . . . . . . . . . . . . . . . . . . 6 50 1.4. Terms and abbreviations . . . . . . . . . . . . . . . . . 6 51 1.5. Requirement levels . . . . . . . . . . . . . . . . . . . . 7 52 1.6. Assumptions and rationale . . . . . . . . . . . . . . . . 8 53 1.7. Why IPsec lacks mobility . . . . . . . . . . . . . . . . . 9 54 2. The network environment . . . . . . . . . . . . . . . . . . . 11 55 2.1. Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . 13 56 2.2. Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . 14 57 2.3. Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 14 58 2.4. Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 15 59 2.5. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 15 60 3. Internal network detection . . . . . . . . . . . . . . . . . . 17 61 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 18 62 3.2. Implementation requirements . . . . . . . . . . . . . . . 18 63 3.2.1. Separate tracking of network interfaces . . . . . . . 18 64 3.2.2. Connection status change . . . . . . . . . . . . . . . 18 65 3.2.3. Registration-based internal network detection . . . . 19 66 3.2.4. Registration-based internal network monitoring . . . . 19 67 3.3. Proposed algorithm . . . . . . . . . . . . . . . . . . . . 20 68 3.4. Trusted Networks Configured (TNC) extension . . . . . . . 21 69 3.5. Implementation issues . . . . . . . . . . . . . . . . . . 22 70 3.6. Rationale for design choices . . . . . . . . . . . . . . . 23 71 3.6.1. Firewall configuration requirements . . . . . . . . . 23 72 3.6.2. Registration-based internal network monitoring . . . . 24 73 3.6.3. No encryption when inside . . . . . . . . . . . . . . 24 74 3.7. Improvements . . . . . . . . . . . . . . . . . . . . . . . 24 75 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 4.1. Mobile node requirements . . . . . . . . . . . . . . . . . 25 77 4.2. VPN device requirements . . . . . . . . . . . . . . . . . 25 78 4.3. Home agent requirements . . . . . . . . . . . . . . . . . 25 79 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 5.1. Comparison against guidelines . . . . . . . . . . . . . . 27 81 5.2. Packet overhead . . . . . . . . . . . . . . . . . . . . . 28 82 5.3. Latency considerations . . . . . . . . . . . . . . . . . . 29 83 5.4. Firewall state considerations . . . . . . . . . . . . . . 30 84 5.5. Intrusion detection systems (IDSs) . . . . . . . . . . . . 30 85 5.6. Implementation of mobile node . . . . . . . . . . . . . . 31 86 5.7. Non-IPsec VPN protocols . . . . . . . . . . . . . . . . . 31 87 6. Security considerations . . . . . . . . . . . . . . . . . . . 32 88 6.1. Internal network detection . . . . . . . . . . . . . . . . 32 89 6.2. Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 33 90 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 35 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 95 Appendix A. Packet flow examples . . . . . . . . . . . . . . . . 39 96 A.1. Connection setup for access mode 'cvc' . . . . . . . . . . 39 97 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 44 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 99 Intellectual Property and Copyright Statements . . . . . . . . . . 50 101 1. Introduction 103 The Mobile IP working group set out to explore the problem and 104 solution spaces of IPsec and Mobile IP coexistence. The problem 105 statement and solution requirements for Mobile IPv4 case was first 106 documented in [ref.rfc4093]. This document outlines the proposed 107 solution for IPv4. 109 The document contains two parts: 111 o a basic solution which is an applicability statement of Mobile 112 IPv4 and IPsec to provide session mobility between enterprise 113 Intranets and other external networks, intended for enterprise 114 mobile users; and 116 o a technical specification and a set of requirements for secure 117 detection of the internal and the external networks, including a 118 new extension which must be implemented by a mobile node and a 119 home agent situated inside the enterprise network. 121 There are many useful ways to combine Mobile IPv4 and IPsec. The 122 solution specified in this document is most applicable when the 123 assumption documented in the problem statement [ref.rfc4093] are 124 valid; among others that the solution: 126 o must minimize changes to existing firewall/VPN/DMZ deployments; 128 o must ensure that traffic is not routed through the DMZ when the 129 mobile node is inside (to avoid scalability and management 130 issues); 132 o must support foreign networks with only foreign agent access; 134 o should not require changes to existing IPsec or key exchange 135 protocols; 137 o must comply with the Mobile IPv4 protocol (but may require new 138 extensions or multiple instances of Mobile IPv4); and 140 o must propose a mechanism to avoid or minimize IPsec re-negotiation 141 when mobile node moves. 143 1.1. Overview 145 Typical corporate networks consist of three different domains: the 146 Internet (untrusted external network), the intranet (trusted internal 147 network), and the DMZ, which connects the two networks. Access to 148 the internal network is guarded both by a firewall and a VPN device; 149 access is only allowed if both firewall and VPN security policies are 150 respected. 152 Enterprise mobile users benefit from unrestricted seamless session 153 mobility between subnets, regardless of whether the subnets are part 154 of the internal or the external network. Unfortunately the current 155 Mobile IPv4 and IPsec standards alone do not provide such a service 156 [ref.tessier]. 158 The proposed solution is to use standard Mobile IPv4 (except for a 159 new extension used by the home agent in the internal network to aid 160 in network detection) when the mobile node is in the internal 161 network, and to use the VPN tunnel endpoint address for the Mobile 162 IPv4 registration when outside. IPsec-based VPN tunnels require re- 163 negotiation after movement. To overcome this limitation, another 164 layer of Mobile IPv4 is used underneath IPsec, in effect making IPsec 165 unaware of movement. Thus, the mobile node can freely move in the 166 external network without disrupting the VPN connection. 168 Briefly, when outside, the mobile node: 170 o detects that it is outside (Section 3); 172 o registers its co-located or foreign agent care-of address with the 173 external home agent; 175 o establishes a VPN tunnel using e.g. IKE (or IKEv2) if security 176 associations are not already available; 178 o registers the VPN tunnel address as its co-located care-of address 179 with the internal home agent; this registration request is sent 180 inside the IPsec tunnel. 182 The solution requires control over the protocol layers in the mobile 183 node. It must be capable of (1) detecting whether it is inside or 184 outside in a secure fashion, and (2) control the protocol layers 185 accordingly. For instance, if the mobile node is inside, the IPsec 186 layer needs to become dormant. 188 Except for the new Mobile IPv4 extension to improve security of 189 internal network detection, current Mobile IPv4 and IPsec standards, 190 when used in a suitable combination, are sufficient to implement the 191 solution; no changes are required to existing VPN devices or foreign 192 agents. 194 The solution described is compatible with different kinds of IPsec- 195 based VPNs, and no particular kind of VPN is required. Because the 196 appropriate security policy database (SPD) entries and other IKE and 197 IPsec specifics differ between deployed IPsec-based VPN products, 198 these details are not discussed in the document. 200 1.2. Scope 202 This document describes a solution for IPv4 only. The downside of 203 the described approach is that an external home agent is required, 204 and that the packet overhead (see Section 5) and overall complexity 205 increase. Optimizations would require significant changes to Mobile 206 IPv4 and/or IPsec, and are out of scope of this document. 208 VPN, in this document, refers to an IPsec-based remote access VPN. 209 Other types of VPNs are out of scope. 211 1.3. Related work 213 Related work has been done on Mobile IPv6 in [ref.rfc3776] which 214 discusses the interaction of IPsec and Mobile IPv6 in protecting 215 Mobile IPv6 signaling. The document also discusses dynamic updating 216 of the IPsec endpoint based on Mobile IP signaling packets. 218 The "transient pseudo-NAT" attack, described in [ref.pseudonat] and 219 [ref.mipnat], affects any approach which attempts to provide security 220 of mobility signaling in conjunction with NAT devices. In many 221 cases, one cannot assume any co-operation from NAT devices which thus 222 have to be treated as any other networking entity. 224 The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [ref.rfc4555] 225 provides better mobility for IPsec. This would allow the external 226 Mobile IPv4 layer described in this specification to be removed. 227 However, deploying MOBIKE requires changes to VPN devices, and is 228 thus out of scope of this specification. 230 1.4. Terms and abbreviations 232 co-CoA: co-located care-of address. 234 DMZ: (DeMilitarized Zone) A small network inserted as a "neutral 235 zone" between a company's private network and the outside public 236 network to prevent outside users from getting direct access to the 237 company's private network. 239 external network: the untrusted network (i.e. Internet). Note 240 that a private network (e.g. another corporate network) other than 241 the mobile node's internal network is considered an external 242 network. 244 FA: Mobile IPv4 foreign agent. 246 FA-CoA: foreign agent care-of address. 248 FW: Firewall. 250 internal network: the trusted network; for instance, a physically 251 secure corporate network where the i-HA is located. 253 i-FA: Mobile IPv4 foreign agent residing in the internal network. 255 i-HA: Mobile IPv4 home agent residing in the internal network; 256 typically has a private address [ref.privaddr]. 258 i-HoA: home address of the mobile node in the internal home agent. 260 MN: Mobile Node. 262 NAI: Network Access Identifier [ref.rfc4282]. 264 R: Router. 266 VPN: Virtual Private Network based on IPsec. 268 VPN-TIA: VPN tunnel inner address, the address(es) negotiated 269 during IKE phase 2 (quick mode), assigned manually, using IPsec- 270 DHCP [ref.rfc3456], using the "de facto" standard ISAKMP 271 configuration mode, or by some other means. Some VPN clients use 272 their current care-of address as their TIA for architectural 273 reasons. 275 VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode 276 IPsec connection, or L2TP combined with IPsec transport 277 connection. 279 x-FA: Mobile IPv4 foreign agent residing in the external network. 281 x-HA: Mobile IPv4 home agent residing in the external network. 283 x-HoA: home address of the mobile node in the external home agent. 285 1.5. Requirement levels 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 289 document are to be interpreted as described in RFC 2119 290 [ref.rfc2119]. 292 1.6. Assumptions and rationale 294 The proposed solution is an attempt to solve the problem described in 295 [ref.rfc4093]. The major assumptions and their rationale is 296 summarized below. 298 Changes to existing firewall and VPN deployments should be minimized: 300 o The current deployment of firewalls and IPsec-based VPNs is much 301 larger than corresponding Mobile IPv4 elements. Thus, a solution 302 should work within the existing VPN infrastructure. 304 o Current enterprise network deployments typically centralize 305 management of security and network access into a compact DMZ. 307 When the mobile node is inside, traffic should not go through the DMZ 308 network: 310 o Routing all mobile node traffic through the DMZ is seen as a 311 performance problem in existing deployments of firewalls. The 312 more sophisticated firewall technology is used (e.g. content 313 scanning), the more serious the performance problem is. 315 o Current deployments of firewalls and DMZs in general have been 316 optimized for the case where only a small minority of total 317 enterprise traffic goes through the DMZ. Furthermore, users of 318 current VPN remote access solutions do not route their traffic 319 through the DMZ when connected to an internal network. 321 An home agent inside the enterprise cannot be reached directly from 322 outside, even if the home agent contains IPsec functionality: 324 o Deployment of current combined IPsec/MIPv4 solutions are not 325 common in large installations. 327 o Doing decryption in the home agents "deep inside" the enterprise 328 effectively means having a security perimeter much larger than the 329 typical, compact DMZ used by a majority of enterprises today. 331 o In order to maintain a security level equal to current firewall/ 332 DMZ deployments, every home agent decapsulating IPsec would need 333 to do the same firewalling as the current DMZ firewalls (content 334 scanning, connection tracking, etc). 336 Traffic cannot be encrypted when the mobile node is inside: 338 o There is a considerable performance impact on home agents (which 339 currently do rather light processing), and mobile nodes 340 (especially for small devices). Note that traffic throughput 341 inside the enterprise is typically order(s) of magnitude larger 342 than the remote access traffic through a VPN. 344 o Encryption consumes processing power and has a significant impact 345 on device battery life. 347 o There is also a usability issue involved; the user needs to 348 authenticate connection to the IPsec layer in the home agent to 349 gain access. For interactive authentication mechanisms (e.g. 350 SecurID) this always means user interaction. 352 o Furthermore, if there is a separate VPN device in the DMZ for 353 remote access, the user needs to authenticate to both devices, and 354 might need to have separate credentials for both. 356 o Current Mobile IPv4 home agents do not typically incorporate IPsec 357 functionality, which is relevant for the proposed solution when we 358 assume zero or minimal changes to existing Mobile IPv4 nodes. 360 o Note, however, that the assumption (no encryption when inside) 361 does not necessarily apply to all solutions in the solution space; 362 if the abovementioned problems were resolved there is no 363 fundamental reason why encryption could not be applied when 364 inside. 366 1.7. Why IPsec lacks mobility 368 IPsec, as currently specified [ref.rfc4301] requires that a new IKE 369 negotiation be done whenever an IPsec peer moves, i.e. changes 370 care-of address. The main reason is that a security association is 371 uni-directional and identified by a triplet consisting of (1) the 372 destination address (which is the outer address when tunnel mode is 373 used), (2) the security protocol (ESP or AH), and (3) the Security 374 Parameter Index (SPI) ([ref.rfc4301], Section 4.1). Although an 375 implementation is not required to use all of these for its own SAs, 376 an implementation cannot assume that a peer does not. 378 When a mobile IPsec peer sends packets to a stationary IPsec peer, 379 there is no problem; the SA is "owned" by the stationary IPsec peer, 380 and therefore the destination address does not need to change. The 381 (outer) source address should be ignored by the stationary peer 382 (although some implementations do check the source address as well). 384 The problem arises when packets are sent from the stationary peer to 385 the mobile peer. The destination address of this SA (SAs are 386 unidirectional) is established during IKE negotiation, and is 387 effectively the care-of address of the mobile peer at time of 388 negotiation. Therefore the packets will be sent to the original 389 care-of address, not a changed care-of address. 391 The IPsec NAT traversal mechanism can also be used for limited 392 mobility, but UDP tunneling needs to be used even when there is no 393 NAT in the route between the mobile and the stationary peers. 394 Furthermore, support for changes in current NAT mapping is not 395 required by the NAT traversal specification [ref.rfc3947]. 397 In summary, although the IPsec standard does not as such prevent 398 mobility (in the sense of updating security associations on-the-fly), 399 the standard does not include a built-in mechanism (explicit or 400 implicit) for doing so. Therefore it is assumed throughout this 401 document that any change in the addresses comprising the identity of 402 an SA requires IKE re-negotiation, which implies too heavy 403 computation and too large latency for useful mobility. 405 The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [ref.rfc4555] 406 provides better mobility for IPsec. This would allow the external 407 Mobile IPv4 layer described in this specification to be removed. 408 However, deploying MOBIKE requires changes to VPN devices, and is 409 thus out of scope of this specification. 411 2. The network environment 413 Enterprise users will access both the internal and external networks 414 using different networking technologies. In some networks, the MN 415 will use FAs and in others it will anchor at the HA using co-located 416 mode. The following figure describes an example network topology 417 illustrating the relationship between the internal and external 418 networks, the possible locations of the mobile node (i.e. (MN)). 420 (MN) {fvc} {home} (MN) [i-HA] 421 ! \ / 422 .--+---. .-+---+-. 423 ( ) ( ) 424 `--+---' [VPN] `--+----' 425 \ ! ! 426 [R/FA] [x-HA] .--+--. [R] 427 \ / ( DMZ ) ! 428 .-+-------+--. `--+--' .-----+------. 429 ( ) ! ( ) 430 ( external net +---[R]----[FW]----[R]--+ internal net ) 431 ( ) ( ) 432 `--+---------' `---+---+----' 433 / / \ 434 [DHCP] [R] [DHCP] [R] [R] [i-FA] 435 \ / \ / \ / 436 .+--+---. .-+-+--. .--+--+-. 437 ( ) ( ) ( ) 438 `---+---' `--+---' `---+---' 439 ! ! ! 440 (MN) {cvc} (MN) {c} (MN) {f} 442 Figure: Basic topology, possible MN locations and access modes 444 In every possible location described in the figure, the mobile node 445 can establish a connection to the corresponding HA(s) by using a 446 suitable "access mode". An access mode is here defined to consist 447 of: 449 1. a composition of the mobile node networking stack (i-MIP or 450 x-MIP/VPN/i-MIP); and 452 2. registration mode(s) of i-MIP and x-MIP (if used); i.e. co- 453 located care-of address or foreign agent care-of address. 455 Each possible access mode is encoded as "xyz", where: 457 o "x" indicates whether the x-MIP layer is used, and if used, the 458 mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence 459 indicates not used); 461 o "y" indicates whether the VPN layer is used ("v" indicates VPN 462 used, absence indicates not used); 464 o "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c" 465 indicates co-CoA). 467 This results in four access modes: 469 c: i-MIP w/ co-CoA 470 f: i-MIP w/ FA-CoA 471 cvc: x-MIP w/ co-CoA, VPN-TIA as i-MIP co-CoA 472 fvc: x-MIP w/ FA-CoA, VPN-TIA as i-MIP co-CoA 474 This notation is more useful when optimizations to protocol layers 475 are considered. The notation is preserved here so that work on the 476 optimizations can refer to a common notation. 478 The internal network is typically a multi-subnetted network using 479 private addressing [ref.privaddr]. Subnets may contain internal home 480 agent(s), DHCP server(s), and/or foreign agent(s). Current IEEE 481 802.11 wireless LANs are typically deployed in the external network 482 or the DMZ because of security concerns. 484 The figure leaves out a few details worth noticing: 486 o There may be multiple NAT devices anywhere in the diagram. 488 * When the MN is outside, the NAT devices may be placed between 489 the MN and the x-HA or the x-HA and the VPN. 491 * There may be also be NAT(s) between the VPN and the i-HA, or a 492 NAT integrated into the VPN. In essence, any router in the 493 figure may be considered to represent zero or more routers, 494 each possibly performing NAT and/or ingress filtering. 496 * When the MN is inside, there may be NAT devices between the MN 497 and the i-HA. 499 o Site-to-site VPN tunnels are not shown. Although mostly 500 transparent, IPsec endpoints may perform ingress filtering as part 501 of enforcing their policy. 503 o The figure represents a topology where each functional entity is 504 illustrated as a separate device. However, it is possible that 505 several network functions are co-located in a single device. In 506 fact, all three server components (x-HA, VPN, and i-HA) may be co- 507 located in a single physical device. 509 The following issues are also important when considering enterprise 510 mobile users: 512 o Some firewalls are configured to block ICMP messages and/or 513 fragments. Such firewalls (routers) cannot be detected reliably. 515 o Some networks contain transparent application proxies, especially 516 for the HTTP protocol. Like firewalls, such proxies cannot be 517 detected reliably in general. IPsec and Mobile IPv4 are 518 incompatible with such networks. 520 Whenever a mobile node obtains either a co-CoA or a FA-CoA, the 521 following conceptual steps take place: 523 o The mobile node detects whether the subnet where the care-of 524 address was obtained belongs to the internal or the external 525 network using the method described in Section 3 (or a vendor 526 specific mechanism fulfilling the requirements described). 528 o The mobile node performs necessary registrations and other 529 connection setup signaling for the protocol layers (in the 530 following order): 532 * x-MIP (if used); 534 * VPN (if used); and 536 * i-MIP. 538 Note that these two tasks are intertwined to some extent: detection 539 of the internal network results in a successful registration to the 540 i-HA using the proposed network detection algorithm. An improved 541 network detection mechanism not based on Mobile IPv4 registration 542 messages might not have this side-effect. 544 The following subsections describe the different access modes and the 545 requirements for registration and connection setup phase. 547 2.1. Access mode: 'c' 549 This access mode is standard Mobile IPv4 [ref.rfc3344] with a co- 550 located address, except that: 552 o the mobile node MUST detect that it is in the internal network; 553 and 555 o the mobile node MUST re-register periodically (with a configurable 556 interval) to ensure it is still inside the internal network (see 557 Section 4). 559 2.2. Access mode: 'f' 561 This access mode is standard Mobile IPv4 [ref.rfc3344] with a foreign 562 agent care-of address, except that 564 o the mobile node MUST detect that it is in the internal network; 565 and 567 o the mobile node MUST re-register periodically (with a configurable 568 interval) to ensure it is still inside the internal network (see 569 Section 4). 571 2.3. Access mode: 'cvc' 573 Steps: 575 o The mobile node obtains a care-of address. 577 o The mobile node detects it is not inside and registers with the 578 x-HA, where 580 * T-bit MAY be set (reverse tunneling), which minimizes the 581 probability of firewall related connectivity problems 583 o If the mobile node does not have an existing IPsec security 584 association, it uses IKE to set up an IPsec security association 585 with the VPN gateway, using the x-HoA as the IP address for IKE/ 586 IPsec communication. How the VPN-TIA is assigned is outside the 587 scope of this document. 589 o The mobile node sends a MIPv4 RRQ to the i-HA, registering the 590 VPN-TIA as a co-located care-of address, where 592 * T-bit SHOULD be set (reverse tunneling) (see discussion below) 594 Reverse tunneling in the inner Mobile IPv4 layer is often required 595 because of IPsec security policy limitations. IPsec selectors define 596 allowed IP addresses for packets sent inside the IPsec tunnel. 597 Typical IPsec remote VPN selectors restrict the client address to be 598 VPN-TIA (remote address is often unrestricted). If reverse tunneling 599 is not used, the source address of a packet sent by the MN will be 600 the MN's home address (registered with i-HA), which is different from 601 the VPN-TIA, thus violating IPsec security policy. Consequently the 602 packet will be dropped, resulting in a connection black hole. 604 Some types of IPsec-based VPNs, in particular L2TP/IPsec VPNs (PPP- 605 over-L2TP-over-IPsec), do not have this limitation and can use 606 triangular routing. 608 Note that although the MN can use triangular routing, i.e. skip the 609 inner MIPv4 layer, it MUST NOT skip the VPN layer for security 610 reasons. 612 2.4. Access mode: 'fvc' 614 Steps: 616 o The mobile node obtains a foreign agent advertisement from the 617 local network. 619 o The mobile node detects it is outside and registers with the x-HA, 620 where 622 * T-bit MAY be set (reverse tunneling), which minimizes the 623 probability of firewall related connectivity problems 625 o If necessary, the mobile node uses IKE to set up an IPsec 626 connection with the VPN gateway, using the x-HoA as the IP address 627 for IKE/IPsec communication. How the VPN-TIA is assigned is 628 outside the scope of this document. 630 o The mobile node sends a MIPv4 RRQ to the i-HA, registering the 631 VPN-TIA as a co-located care-of address, where 633 * T-bit SHOULD be set (reverse tunneling) (see discussion in 634 Section 2.3) 636 Note that although the MN can use triangular routing, i.e. skip the 637 inner MIPv4 layer, it MUST NOT skip the VPN layer for security 638 reasons. 640 2.5. NAT traversal 642 NAT devices may affect each layer independently. Mobile IPv4 NAT 643 traversal [ref.mipnat] SHOULD be supported for x-MIP and i-MIP 644 layers, while IPsec NAT traversal [ref.rfc3947][ref.rfc3948] SHOULD 645 be supported for the VPN layer. 647 Note that NAT traversal for the internal MIPv4 layer may be necessary 648 even when there is no separate NAT device between the VPN gateway and 649 the internal network. Some VPN implementations NAT VPN tunnel inner 650 addresses before routing traffic to the intranet. Sometimes this is 651 done to make a deployment easier, but in some cases this approach 652 makes VPN client implementation easier. Mobile IPv4 NAT traversal is 653 required to establish a MIPv4 session in this case. 655 3. Internal network detection 657 Secure detection of the internal network is critical to prevent 658 plaintext traffic from being sent over an untrusted network. In 659 other words, the overall security (confidentiality and integrity of 660 user data) relies on the security of the internal network detection 661 mechanism in addition to IPsec. For this reason, security 662 requirements are described in this section. 664 In addition to detecting entry into the internal network, the mobile 665 node must also detect when it has left the internal network. Entry 666 into the internal network is easier security-wise: the mobile node 667 can ensure that it is inside the internal network before sending any 668 plaintext traffic. Exit from the internal network is more difficult 669 to detect, and the MN may accidentally leak plaintext packets if the 670 event is not detected in time. 672 Several events can cause the mobile node to leave the internal 673 network, including: 675 o a routing change upstream; 677 o a reassociation of 802.11 on layer 2 which the mobile node 678 software does not detect; 680 o a physical cable disconnect and reconnect which the mobile node 681 software does not detect. 683 Whether the mobile node can detect such changes in the current 684 connection reliably depends on the implementation and the networking 685 technlogy. For instance, some mobile nodes may be implemented as 686 pure layer three entities. Even if the mobile node software has 687 access to layer two information, such information is not trustworthy 688 security-wise, and depends on the network interface driver. 690 If the mobile node does not detect these events properly, it may leak 691 plaintext traffic into an untrusted network. A number of approaches 692 can be used to detect exit from the internal network, ranging from 693 frequent re-registration to the use of layer two information. 695 A mobile node MUST implement a detection mechanism fulfilling the 696 requirements described in Section 3.2; this ensures that basic 697 security requirements are fulfilled. The basic algorithm described 698 in Section 3.3 is one way to do that, but alternative methods may be 699 used instead or in conjunction. The assumptions that the 700 requirements and the proposed mechanism rely upon are described in 701 Section 3.1. 703 3.1. Assumptions 705 The enterprise firewall MUST be configured to block traffic 706 originating from external networks going to the i-HA. In other 707 words, the mobile node MUST NOT be able to perform a successful RRQ/ 708 RRP exchange (without using IPsec) unless it is connected to the 709 trusted internal network; the mobile node can then stop using IPsec 710 without compromising data confidentiality. 712 If this assumption does not hold, data confidentiality is compromised 713 in a potentially silent and thus dangerous manner. To minimize the 714 impact of this scenario the i-HA is also required to check the source 715 address of any RRQ to determine whether it comes from a trusted 716 (internal network) address. The i-HA needs to indicate to the MN 717 that it supports checking of trusted source addresses by including a 718 Trusted Networks Configured extension in its registration reply. 719 This new extension, which needs to be implemented by both i-HA and 720 the MN, is described in Section 3.4. 722 The firewall MAY be configured to block registration traffic to the 723 x-HA originating from within the internal network, which makes the 724 network detection algorithm simpler and more robust. However, as the 725 registration request is basically UDP traffic, an ordinary firewall 726 (even a stateful one) would typically allow the registration request 727 to be sent, and a registration reply to be received through the 728 firewall. 730 3.2. Implementation requirements 732 Any mechanism used to detect the internal network MUST fulfill the 733 requirements described in this section. An example of a network 734 detection mechanism fulfilling these requirements is given in Section 735 Section 3.3. 737 3.2.1. Separate tracking of network interfaces 739 The mobile node implementation MUST track each network interface 740 separately. Successful registration with the i-HA through interface 741 X does not imply anything about the status of interface Y. 743 3.2.2. Connection status change 745 When the mobile node detects that its connection status on a certain 746 network interface changes, the mobile node MUST: 748 o immediately stop relaying user data packets; 749 o detect whether this interface is connected to the internal or the 750 external network; 752 o resume data traffic only after the internal network detection and 753 necessary registrations and VPN tunnel establishment have been 754 completed. 756 The mechanisms used to detect a connection status change depends on 757 the mobile node implementation, the networking technology, and the 758 access mode. 760 3.2.3. Registration-based internal network detection 762 The mobile node MUST NOT infer that an interface is connected to the 763 internal network unless a successful registration has been completed 764 through that particular interface to the i-HA, the i-HA registration 765 reply contained a Trusted Networks Configured extension 766 (Section 3.4), and the connection status of the interface has not 767 changed since. 769 3.2.4. Registration-based internal network monitoring 771 Some leak of plaintext packets to a (potentially) untrusted network 772 cannot always be completely prevented; this depends heavily on the 773 client implementation. In some cases the client cannot detect such a 774 change, e.g. if upstream routing is changed. 776 More frequent re-registrations when the MN is inside is a simple way 777 to ensure that MN is still inside. The MN SHOULD start re- 778 registration every (T_MONITOR - N) seconds when inside, where N is a 779 grace period which ensures that re-registration is completed before 780 T_MONITOR seconds are up. To bound the maximum amount of time that a 781 plaintext leak may persist, the mobile node must fulfill the 782 following security requirements when inside: 784 o The mobile node MUST NOT send or receive a user data packet if 785 more than T_MONITOR seconds has elapsed since last successful 786 (re-)registration with the i-HA. 788 o If more than T_MONITOR seconds has elapsed, data packets MUST be 789 either dropped or queued. If the packets are queued, the queues 790 MUST NOT be processed until the re-registration has been 791 successfully completed without a connection status change. 793 o The T_MONITOR parameter MUST be configurable, and have the default 794 value of 60 seconds. This default is a trade-off between traffic 795 overhead and a reasonable bound to exposure. 797 This approach is reasonable for a wide range of mobile nodes (e.g. 798 laptops), but has unnecessary overhead when the mobile node is idle 799 (not sending or receiving packets). If re-registration does not 800 complete before T_MONITOR seconds are up, data packets must be queued 801 or dropped as specified above. Note that re-registration packets 802 MUST be sent even if bi-directional user data traffic is being 803 relayed: data packets are no substitute for an authenticated re- 804 registration. 806 To minimize traffic overhead when the mobile node is idle, re- 807 registrations can be stopped when no traffic is being sent or 808 received. If the mobile node subsequently receives or needs to send 809 a packet, the packet must be dropped or queued (as specified above) 810 until a re-registration with the i-HA has been successfully 811 completed. Although this approach adds packet processing complexity, 812 it may be appropriate for small battery powered devices which may be 813 idle much of the time. (Note that ordinary re-registration before 814 the mobility binding lifetime is exhausted should still be done to 815 keep the MN reachable.) 817 T_MONITOR is required to be configurable so that an administrator can 818 determine the required security level for the particular deployment. 819 Configuring T_MONITOR in the order of few seconds is not practical; 820 alternative mechanisms need to be considered if such confidence is 821 required. 823 The re-registration mechanism is a worst case fallback mechanism. If 824 additional information (such as layer two triggers) are available to 825 the mobile node, the mobile node SHOULD use the triggers to detect MN 826 movement and restart the detection process to minimize exposure. 828 Note that re-registration is required by Mobile IPv4 by default 829 (except for the untypical case of an infinite binding lifetime); 830 however, the re-registration interval may be much larger when using 831 an ordinary Mobile IPv4 client. Shorter re-registration interval is 832 usually not an issue, because the internal network is typically a 833 fast, wired network, and the shortened re-registration interval 834 applies only when the mobile node is inside the internal network. 835 When outside, the ordinary Mobile IPv4 re-registration process (based 836 on binding lifetime) is used. 838 3.3. Proposed algorithm 840 When the MN detects that it has changed its point of network 841 attachment on a certain interface, it issues two simultaneous 842 registration requests, one to the i-HA and another to the x-HA. 843 These registration requests are periodically retransmitted if reply 844 messages are not received. 846 Registration replies are processed as follows: 848 o If a response from the x-HA is received, the MN stops 849 retransmitting its registration request to the x-HA and 850 tentatively determines it is outside. However, the MN MUST keep 851 on retransmitting its registration to the i-HA for a period of 852 time. The MN MAY postpone the IPsec connection setup for some 853 period of time while it waits for a (possible) response from the 854 i-HA. 856 o If a response from the i-HA is received and the response contains 857 the Trusted Networks Configured extension (Section 3.4), the MN 858 SHOULD determine that it is inside. In any case, the MN MUST stop 859 retransmitting its registration requests to both i-HA and x-HA. 861 o When successfully registered with the i-HA, MN SHOULD de-register 862 with the x-HA. 864 If the MN ends up detecting that it is inside, it MUST re-register 865 periodically (regardless of binding lifetime); see Section 3.2.4. If 866 the re-registration fails, the MN MUST stop sending and receiving 867 plaintext traffic, and MUST restart the detection algorithm. 869 Plaintext re-registration messages are always addressed either to the 870 x-HA or the i-HA, not to both. This is because the MN knows, after 871 initial registration, whether it is inside or outside. (However, 872 when the mobile node is outside, it re-registers independently with 873 the x-HA using plaintext, and with the i-HA through the VPN tunnel.) 875 Postponing the IPSec connection setup could prevent aborted IKE 876 sessions. Aborting IKE sessions may be a problem in some cases 877 because IKE does not provide a reliable, standardized, and mandatory- 878 to-implement mechanism for terminating a session cleanly. 880 If the x-HA is not reachable from inside (i.e. the firewall 881 configuration is known), a detection period of zero is preferred, as 882 it minimizes connection setup overhead and causes no timing problems. 883 Should the assumption have been invalid and a response from the i-HA 884 received after a response from the x-HA, the MN SHOULD re-register 885 with the i-HA directly. 887 3.4. Trusted Networks Configured (TNC) extension 889 This extension is a skippable extension. An i-HA sending the 890 extension must fulfill the requirements described in Section 4.3 891 while an MN processing the extension must fulfill the requirements 892 described in Section 4.1. The format of the extension is described 893 below. It adheres to the short extension format described in 895 [ref.rfc3344]: 897 0 1 2 3 898 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Type | Length | Sub-Type | Reserved | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 Type TBD:IANA 905 Length 2 907 Sub-Type TBD:IANA (probably 0 if Type is new) 909 Reserved Set to 0 when sending, ignored when receiving 911 3.5. Implementation issues 913 When the MN uses a parallel detection algorithm and is using an FA, 914 the MN sends two registration requests through the same FA with the 915 same MAC address (or equivalent) and possibly even the same home 916 address. Although this is not in conflict with existing 917 specifications, it is an unusual scenario; hence some FA 918 implementations may not work properly in such a situation. However, 919 testing against deployed foreign agents seems to indicate that a 920 majority of available foreign agents handle this situation. 922 When the x-HA and i-HA addresses are the same, the scenario is even 923 more difficult for the FA, and it is almost certain that existing FAs 924 do not deal with the situation correctly. Therefore, it is required 925 that x-HA and i-HA addresses MUST be different. 927 Regardless, if the MN detects that i-HA and x-HA have the same 928 address, it MUST assume that it is in the external network and bypass 929 network detection to avoid confusing the FA. Because the HA 930 addresses are used at different layers, achieving connectivity is 931 possible without address confusion. 933 The mobile node MAY use the following hints to determine that it is 934 inside, but MUST verify reachability of the i-HA anyway: 936 o a domain name in a DHCPDISCOVER / DHCPOFFER message; 938 o a NAI in a foreign agent advertisement; 940 o a list of default gateway MAC addresses which are known to reside 941 in the internal network (i.e. configured as such, or have been 942 previously verified to be inside). 944 For instance, if the MN has reason to believe it is inside, it MAY 945 postpone sending of registration request to the x-HA for some time. 946 Similarly, if the MN has a reason to believe it is outside, it may 947 start IPsec connection setup immediately after receiving a 948 registration reply from the x-HA. However, should the MN receive a 949 registration reply from the i-HA after IPsec connection setup has 950 been started, the MN SHOULD still switch to using the i-HA directly. 952 3.6. Rationale for design choices 954 3.6.1. Firewall configuration requirements 956 The requirement that the i-HA cannot be reached from the external 957 network is necessary. If not, a successful registration with the 958 i-HA (without IPsec) cannot be used as a secure indication that the 959 mobile node is inside. A possible solution to the obvious security 960 problem would be to define and deploy a secure internal network 961 detection mechanism based on e.g. signed FA advertisement or signed 962 DHCP messages. 964 However, unless the mechanism is defined for both FA and DHCP 965 messages and is deployed in every internal network, it has limited 966 applicability. In other words, the mobile node MUST NOT assume it is 967 in the internal network unless it receives a signed FA or DHCP 968 message (regardless of whether it can register directly with the i-HA 969 or not!). If it receives an unsigned FA or DHCP message, it MUST use 970 IPsec; otherwise the mobile node can be easily tricked into using 971 plaintext. 973 Assuming that all FA and DHCP servers in the internal network are 974 upgraded to support such a feature does not seem realistic; it is 975 highly desirable to be able to take advantage of existing DHCP and FA 976 deployments. Similar analysis seems to apply regardless of what kind 977 of additional security mechanism is defined. 979 Because a firewall configuration error can have catastrophic data 980 security consequences (silent exposure of user data to external 981 attackers), a separate protection mechanism is provided by the i-HA. 982 The i-HA must be configured, by the administrator, with a list of 983 trusted networks. The i-HA advertises that it knows which 984 registration request source addresses are trusted, using a 985 registration reply extension (Trusted Networks Configured extension, 986 Section 3.4). Without this extension, an MN may not rely on a 987 successful registration to indicate that it is connected to the 988 internal network. This ensures that user data compromise does not 989 occur unless both the firewall and the i-HA are configured 990 incorrectly. Further, occurrences of registration requests from 991 untrusted addresses should be logged by the i-HA, exposing them to 992 administrator review. 994 3.6.2. Registration-based internal network monitoring 996 This issue also affects IPsec client security. However, as IPsec 997 specifications take no stand on how and when client IPsec policies 998 are configured or changed (for instance, in response to a change in 999 network connectivity), the issue is out of scope for IPsec. Because 1000 this document describes an algorithm and requirements for (secure) 1001 internal network detection, the issue is in scope of the document. 1003 The current requirement for internal network monitoring was added as 1004 a fallback mechanism. 1006 3.6.3. No encryption when inside 1008 If encryption was applied also when MN was inside, there would be no 1009 security reason to monitor the internal network periodically. 1011 The main rationale for why encryption cannot be applied when the MN 1012 is inside was given in Section 1.6. In short, the main issues are 1013 (1) power consumption; (2) extra CPU load, especially because 1014 internal networks are typically switched networks and a lot of data 1015 may be routinely transferred; (3) existing HA devices do not 1016 typically integrate IPsec functionality; (4) (IPsec) encryption 1017 requires user authentication, which may be interactive in some cases 1018 (e.g. SecurID) and thus a usability issue; and (5) user may need to 1019 have separate credentials for VPN devices in the DMZ and the HA. 1021 3.7. Improvements 1023 The registration process can be improved in many ways. One simple 1024 way is to make the x-HA detect whether a registration request came 1025 from inside or outside the enterprise network. If it came from 1026 inside the enterprise network, the x-HA can simply drop the 1027 registration request. 1029 This approach is feasible without protocol changes in scenarios where 1030 a corporation owns both the VPN and the x-HA. The x-HA can simply 1031 determine based on incoming interface identifier (or the router which 1032 relayed the packet) whether the registration request came from inside 1033 or not. 1035 In other scenarios protocol changes may be needed. Such changes are 1036 out of scope of this document. 1038 4. Requirements 1040 4.1. Mobile node requirements 1042 The mobile node MUST implement an internal network detection 1043 algorithm fulfilling the requirements set forth in Section 3.2. A 1044 new configurable MN parameter, T_MONITOR, is required. The value of 1045 this parameter reflects a balance between security and the amount of 1046 signaling overhead, and thus needs to be configurable. In addition, 1047 when doing internal network detection, the MN MUST NOT disable IPsec 1048 protection unless the registration reply from the i-HA contains a 1049 Trusted Networks Configured extension (Section 3.4). 1051 The mobile node MUST support access modes: c, f, cvc, fvc 1052 (Section 2). 1054 The mobile node SHOULD support Mobile IPv4 NAT traversal [ref.mipnat] 1055 for both internal and external Mobile IP. 1057 The mobile node SHOULD support IPsec NAT traversal 1058 [ref.rfc3947][ref.rfc3948]. 1060 When the mobile node has direct access to the i-HA, it SHOULD use 1061 only the inner Mobile IPv4 layer to minimize firewall and VPN impact. 1063 When the mobile node is outside and using the VPN connection, IPsec 1064 policies MUST be configured to encrypt all traffic sent to and from 1065 the enterprise network. The particular Security Policy Database 1066 (SPD) entries depend on the type and configuration of the particular 1067 VPN (e.g. plain IPsec vs. L2TP/IPsec, full tunneling or split 1068 tunneling). 1070 4.2. VPN device requirements 1072 The VPN security policy MUST allow communication using UDP to the 1073 internal home agent(s), with home agent port 434 and any remote port. 1074 The security policy SHOULD allow IP-IP to internal home agent(s) in 1075 addition to UDP port 434. 1077 The VPN device SHOULD implement the IPsec NAT traversal mechanism 1078 described in [ref.rfc3947] [ref.rfc3948]. 1080 4.3. Home agent requirements 1082 The home agent SHOULD implement the Mobile IPv4 NAT traversal 1083 mechanism described in [ref.mipnat]. (This also refers to the i-HA: 1084 NAT traversal is required to support VPNs that NAT VPN tunnel 1085 addresses or block IP-IP traffic.) 1086 To protect user data confidentiality against firewall configuration 1087 errors, the i-HA: 1089 o MUST be configured with a list of trusted IP subnets (containing 1090 only addresses from the internal network), with no subnets being 1091 trusted by default. 1093 o MUST reject (drop silently) any registration request coming from a 1094 source address which is not inside any of the configured trusted 1095 subnets. These dropped registration requests SHOULD be logged. 1097 o MUST include a Trusted Networks Configured extension (Section 3.4) 1098 in a registration reply sent in response to a registration request 1099 coming from a trusted address. 1101 5. Analysis 1103 This section provides a comparison against guidelines described in 1104 Section 6 of the problem statement [ref.rfc4093] and additional 1105 analysis of packet overhead with and without the optional mechanisms. 1107 5.1. Comparison against guidelines 1109 Preservation of existing VPN infrastructure 1111 o The proposed solution does not mandate any changes to existing VPN 1112 infrastructure, other than possibly changes in configuration to 1113 avoid stateful filtering of traffic. 1115 Software upgrades to existing VPN clients and gateways 1117 o The solution described does not require any changes to VPN 1118 gateways or Mobile IPv4 foreign agents. 1120 IPsec protocol 1122 o Proposed solution does not require any changes to existing IPsec 1123 or key exchange standard protocols, and does not require 1124 implementation of new protocols in the VPN device. 1126 Multi-vendor interoperability 1128 o The proposed solution provides easy multi-vendor interoperability 1129 between server components (VPN device, foreign agents and home 1130 agents). Indeed, these components need not be aware of each 1131 other. 1133 o The mobile node networking stack is somewhat complex to implement, 1134 which may be an issue for multi-vendor interoperability. However, 1135 this is a purely software architecture issue, and there are no 1136 known protocol limitations for multi-vendor interoperability. 1138 MIPv4 protocol 1140 o The solution adheres to the MIPv4 protocol, but requires the new 1141 Trusted Networks Configured extension to improve the 1142 trustworthiness of internal network detection. 1144 o The solution requires the use of two parallel MIPv4 layers. 1146 Handoff overhead 1147 o The solution provides a mechanism to avoid VPN tunnel SA 1148 renegotiation upon movement by using the external MIPv4 layer. 1150 Scalability, availability, reliability, and performance 1152 o The solution complexity is linear with the number of MNs 1153 registered and accessing resources inside the intranet. 1155 o Additional overhead is imposed by the solution. 1157 Functional entities 1159 o The solution does not impose any new types of functional entities 1160 or required changes to existing entities. However, an external HA 1161 device is required. 1163 Implications of intervening NAT gateways 1165 o The solution leverages existing MIPv4 NAT traversal [ref.mipnat] 1166 and IPsec NAT traversal [ref.rfc3947] [ref.rfc3948] solutions and 1167 does not require any new functionality to deal with NATs. 1169 Security implications 1171 o The solution requires a new mechanism to detect whether the mobile 1172 node is in the internal or the external network. The security of 1173 this mechanism is critical in ensuring that the security level 1174 provided by IPsec is not compromised by a faulty detection 1175 mechanism. 1177 o When the mobile node is outside, the external Mobile IPv4 layer 1178 may allow some traffic redirection attacks that plain IPsec does 1179 not allow. Other than that, IPsec security is unchanged. 1181 o More security considerations are described in Section 6. 1183 5.2. Packet overhead 1185 The maximum packet overhead depends on access mode as follows: 1187 o f: 0 octets 1189 o c: 20 octets 1191 o fvc: 77 octets 1193 o cvc: 97 octets 1194 The overhead consists of the following: 1196 o IP-IP for i-MIPv4: 20 octets 1198 o IPsec ESP: 57 octets total, consisting of: 20 (new IP header), 1199 4+4+8 = 16 (SPI, sequence number, cipher initialization vector), 1200 7+2 = 9 (padding, padding length field, next header field), 12 1201 (ESP authentication trailer) 1203 o IP-IP for x-MIPv4: 20 octets 1205 When IPsec is used, a variable amount of padding is present in each 1206 ESP packet. The figures were computed for a cipher with 64-bit block 1207 size, padding overhead of 9 octets (next header field, padding length 1208 field, and 7 octets of padding, see Section 2.4 of [ref.rfc4303]), 1209 and ESP authentication field of 12 octets (HMAC-SHA1-96 or 1210 HMAC-MD5-96). Note that an IPsec implementation MAY pad with more 1211 than a minimum amount of octets. 1213 NAT traversal overhead is not included, and adds 8 octets when IPsec 1214 NAT traversal [ref.rfc3947] [ref.rfc3948] is used and 12 octets when 1215 MIP NAT traversal [ref.mipnat] is used. For instance, when using 1216 access mode cvc, the maximum NAT traversal overhead is 12+8+12 = 32 1217 octets. Thus, the worst case scenario (with the abovementioned ESP 1218 assumptions) is 129 octets for cvc. 1220 5.3. Latency considerations 1222 When the MN is inside, connection setup latency does not increase 1223 compared to standard MIPv4 if the MN implements the suggested 1224 parallel registration sequence (see Section 3.3). Exchange of RRQ/ 1225 RRP messages with the i-HA confirms the MN is inside, and the MN may 1226 start sending and receiving user traffic immediately. For the same 1227 reason, handovers in the internal network have no overhead relative 1228 to standard MIPv4. 1230 When the MN is outside, the situation is slightly different. Initial 1231 connection setup latency essentially consists of (1) registration 1232 with the x-HA, (2) optional detection delay (waiting for i-HA 1233 response), (3) IPsec connection setup (IKE), (4) registration with 1234 the i-HA. All but (4) are in addition to standard MIPv4. 1236 However, handovers in the external network have performance 1237 comparable to standard MIPv4. The MN simply re-registers with the 1238 x-HA and starts to send IPsec traffic to the VPN gateway from the new 1239 address. 1241 The MN may minimize latency by (1) not waiting for an i-HA response 1242 before triggering IKE if the x-HA registration succeeds; and (2) 1243 sending first the RRQ most likely to succeed (e.g. if the MN is most 1244 likely outside. These can be done based on heuristics about the 1245 network, e.g. addresses, MAC address of the default gateway (which 1246 the mobile node may remember from previous access), based on the 1247 previous access network (i.e. optimize for inside-inside and outside- 1248 outside movement), etc. 1250 5.4. Firewall state considerations 1252 A separate firewall device or an integrated firewall in the VPN 1253 gateway typically performs stateful inspection of user traffic. The 1254 firewall may, for instance, track TCP session status and block TCP 1255 segments not related to open connections. Other stateful inspection 1256 mechanisms also exist. 1258 Firewall state poses a problem when the mobile node moves between the 1259 internal and external networks. The mobile node may, for instance, 1260 initiate a TCP connection while inside, and later go outside while 1261 expecting to keep the connection alive. From the point of view of 1262 the firewall, the TCP connection has not been initiated, as it has 1263 not witnessed the TCP connection setup packets, thus potentially 1264 resulting in connectivity problems. 1266 When the VPN-TIA is registered as a co-located care-of address with 1267 the i-HA, all mobile node traffic appears as IP-IP for the firewall. 1268 Typically firewalls do not continue inspection beyond the IP-IP 1269 tunnel, but support for deeper inspection is available in many 1270 products. In particular, an administrator can configure traffic 1271 policies in many firewall products even for IP-IP encapsulated 1272 traffic. If this is done, similar statefulness issues may arise. 1274 In summary, the firewall must allow traffic coming from and going 1275 into the IPsec connection to be routed, even though they may not have 1276 successfully tracked the connection state. How this is done is out 1277 of scope of this document. 1279 5.5. Intrusion detection systems (IDSs) 1281 Many firewalls incorporate intrusion detection systems monitoring 1282 network traffic for unusual patterns and clear signs of attack. 1283 Since traffic from a mobile node implementing this specification is 1284 UDP to i-HA port 434, and possibly IP-IP traffic to the i-HA address, 1285 existing IDSs may treat the traffic differently than ordinary VPN 1286 remote access traffic. Like firewalls, IDSs are not standardized, so 1287 it is impossible to guarantee interoperability with any particular 1288 IDS system. 1290 5.6. Implementation of mobile node 1292 Implementation of the mobile node requires the use of three tunneling 1293 layers, which may be used in various configurations depending on 1294 whether that particular interface is inside or outside. Note that it 1295 is possible that one interface is inside and another interface is 1296 outside, which requires a different layering for each interface at 1297 the same time. 1299 For multi-vendor implementation, the IPsec and MIPv4 layers need to 1300 interoperate in the same mobile node. This implies that a flexible 1301 framework for protocol layering (or protocol-specific APIs) are 1302 required. 1304 5.7. Non-IPsec VPN protocols 1306 The proposed solution works also for VPN tunneling protocols that are 1307 not IPsec-based, provided that the mobile node is provided IPv4 1308 connectivity with an address suitable for registration. However, 1309 such VPN protocols are not explicitly considered. 1311 6. Security considerations 1313 6.1. Internal network detection 1315 If the mobile node by mistake believes it is in the internal network 1316 and sends plaintext packets, it compromises IPsec security. For this 1317 reason, the overall security (confidentiality and integrity) of user 1318 data is a minimum of (1) IPsec security, and (2) security of the 1319 internal network detection mechanism. 1321 Security of the internal network detection relies on a successful 1322 registration with the i-HA. For standard Mobile IPv4 [ref.rfc3344] 1323 this means HMAC-MD5 and Mobile IPv4 replay protection. The solution 1324 also assumes that the i-HA is not directly reachable from the 1325 external network, requiring careful enterprise firewall 1326 configuration. To minimize the impact of a firewall configuration 1327 problem, the i-HA is separately required to be configured with 1328 trusted source addresses (i.e., addresses belonging to the internal 1329 network), and to include an indication of this in a new Trusted 1330 Networks Configured extension. The MN is required not to trust a 1331 registration as an indication of being connected to the internal 1332 network, unless this extension is present in the registration reply. 1333 Thus, to actually compromise user data confidentiality, both the 1334 enterprise firewall and the i-HA have to be configured incorrectly, 1335 which reduces the likelihood of the scenario. 1337 When the mobile node sends a registration request to the i-HA from an 1338 untrusted network that does not go through the IPsec tunnel, it will 1339 reveal the i-HA's address, its own identity including the NAI and the 1340 home address, and the Authenticator value in the authentication 1341 extensions to the untrusted network. This may be a concern in some 1342 deployments. 1344 When the connection status of an interface changes, an interface 1345 previously connected to the trusted internal network may suddenly be 1346 connected to an untrusted network. Although the same problem is also 1347 relevant to IPsec-based VPN implementations, the problem is 1348 especially relevant in the scope of this specification. 1350 In most cases, mobile node implementations are expected to have layer 1351 two information available, making connection change detection both 1352 fast and robust. To cover cases where such information is not 1353 available (or fails for some reason), the mobile node is required to 1354 periodically re-register with the internal home agent to verify that 1355 it is still connected to the trusted network. It is also required 1356 that this re-registration interval be configurable, thus giving the 1357 administrator a parameter by which potential exposure may be 1358 controlled. 1360 6.2. Mobile IPv4 versus IPsec 1362 MIPv4 and IPsec have different goals and approaches for providing 1363 security services. MIPv4 typically uses a shared secret for 1364 authentication of signaling traffic, while IPsec typically uses IKE 1365 (an authenticated Diffie-Hellman exchange) to set up session keys. 1366 Thus, the overall security properties of a combined MIPv4 and IPsec 1367 system depend on both mechanisms. 1369 In the solution outlined in this document, the external MIPv4 layer 1370 provides mobility for IPsec traffic. If the security of MIPv4 is 1371 broken in this context, traffic redirection attacks against the IPsec 1372 traffic are possible. However, such routing attacks do not affect 1373 other IPsec properties (confidentiality, integrity, replay 1374 protection, etc), because IPsec does not consider the network between 1375 two IPsec endpoints to be secure in any way. 1377 Because MIPv4 shared secrets are usually configured manually, they 1378 may be weak if easily memorizable secrets are chosen, thus opening up 1379 redirection attacks described above. Note especially that a weak 1380 secret in the i-HA is fatal to security, as the mobile node can be 1381 fooled into dropping encryption if the i-HA secret is broken. 1383 Assuming the MIPv4 shared secrets have sufficient entropy, there are 1384 still at least the following differences and similarities between 1385 MIPv4 and IPsec worth considering: 1387 o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" 1388 attack described in [ref.pseudonat] and [ref.mipnat], assuming 1389 that NAT traversal is enabled (which is typically the case). 1390 "Pseudo NAT" attacks allow an attacker to redirect traffic flows, 1391 resulting in resource consumption, lack of connectivity, and 1392 denial-of-service. However, such attacks cannot compromise the 1393 confidentiality of user data protected using IPsec. 1395 o When considering a "pseudo NAT" attack against standard IPsec and 1396 standard MIP (with NAT traversal), redirection attacks against MIP 1397 may be easier because: 1399 * MIPv4 re-registrations typically occur more frequently than 1400 IPsec SA setups (although this may not be the case for mobile 1401 hosts). 1403 * It suffices to catch and modify a single registration request, 1404 whereas attacking IKE requires that multiple IKE packets are 1405 caught and modified. 1407 o There may be concerns about mixing of algorithms. For instance, 1408 IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC- 1409 MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore, 1410 while IPsec algorithms are typically configurable, MIPv4 clients 1411 typically use only HMAC-MD5 or prefix+suffix MD5. Although this 1412 is probably not a security problem as such, it is more difficult 1413 to communicate to users. 1415 o When IPsec is used with a PKI, the key management properties are 1416 superior to those of basic MIPv4. Thus, adding MIPv4 to the 1417 system makes key management more complex. 1419 o In general, adding new security mechanisms increases overall 1420 complexity and makes the system more difficult to understand. 1422 7. IANA considerations 1424 This document specifies a new skippable extension (in the short 1425 format) in Section 3.4, whose Type and Sub-Type values need to be 1426 assigned. 1428 8. Acknowledgements 1430 This document is a joint work of the contributing authors (in 1431 alphabetical order): 1433 - Farid Adrangi (Intel Corporation) 1434 - Nitsan Baider (Check Point Software Technologies, Inc.) 1435 - Gopal Dommety (Cisco Systems) 1436 - Eli Gelasco (Cisco Systems) 1437 - Dorothy Gellert (Nokia Corporation) 1438 - Espen Klovning (Birdstep) 1439 - Milind Kulkarni (Cisco Systems) 1440 - Henrik Levkowetz (ipUnplugged AB) 1441 - Frode Nielsen (Birdstep) 1442 - Sami Vaarala (Codebay) 1443 - Qiang Zhang (Liqwid Networks, Inc.) 1445 The authors would like to thank MIP/VPN design team, especially Mike 1446 Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent 1447 Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan 1448 O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans 1449 Sjostrand, and Serge Tessier for their continuous feedback and 1450 helping us improve this draft. Special thanks to Radia Perlman for 1451 giving the document a thorough read and a security review. Tom 1452 Hiller pointed out issues with battery powered devices. We would 1453 also like to thank the previous Mobile IP working group chairs 1454 (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important 1455 feedback and guidance. 1457 9. References 1459 9.1. Normative References 1461 [ref.rfc2119] 1462 Bradner, S., "Key words for use in RFCs to Indicate 1463 Requirement Levels", RFC 2119, March 1997. 1465 [ref.rfc4301] 1466 Kent, S. and K. Seo, "Security Architecture for the 1467 Internet Protocol", RFC 4301, December 2005. 1469 [ref.rfc3344] 1470 Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1471 August 2002. 1473 [ref.mipnat] 1474 Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1475 Network Address Translation (NAT) Devices", RFC 3519, 1476 April 2003. 1478 [ref.privaddr] 1479 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1480 and E. Lear, "Address Allocation for Private Internets", 1481 RFC 1918, BCP 5, February 1996. 1483 [ref.rfc3947] 1484 Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1485 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1486 January 2005. 1488 [ref.rfc3948] 1489 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1490 Stenberg, "UDP Encapsulation of IPsec packets", RFC 3948, 1491 January 2005. 1493 [ref.rfc4303] 1494 Kent, S., "IP Encapsulating Security Payload (ESP)", 1495 RFC 4303, December 2005. 1497 9.2. Informative References 1499 [ref.rfc4093] 1500 Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile 1501 IPv4 Traversal of Virtual Private Network (VPN) Gateways", 1502 RFC 4093, August 2005. 1504 [ref.rfc4282] 1505 Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1506 Network Access Identifier", RFC 4282, December 2005. 1508 [ref.rfc4555] 1509 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1510 (MOBIKE)", RFC 4555, June 2006. 1512 [ref.tessier] 1513 Tessier, S., "Guidelines for Mobile IP and IPsec VPN 1514 Usage", December 2002. 1516 [ref.rfc3776] 1517 Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1518 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1519 Home Agents", RFC 3776, June 2004. 1521 [ref.rfc3456] 1522 Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 1523 Host Configuration Protocol (DHCPv4) Configuration of 1524 IPsec Tunnel Mode", RFC 3456, January 2003. 1526 [ref.pseudonat] 1527 Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks 1528 or how NATs are even more evil than you believed 1529 (draft-dupont-transient-pseudonat-04, work in progress)", 1530 June 2004. 1532 Appendix A. Packet flow examples 1534 A.1. Connection setup for access mode 'cvc' 1536 The following figure illustrates connection setup when the mobile 1537 node is outside and using a co-located care-of address. IKE 1538 connection setup is not shown in full, and involves multiple round 1539 trips (4.5 round trips when using main mode followed by quick mode). 1541 MN-APP MN x-HA VPN i-HA CN 1542 ! ! ! ! ! ! 1543 ! ! -------> ! ! ! ! 1544 ! ! rrq ! ! ! ! 1545 ! ! -----------------X ! ! ! rrq not 1546 ! ! rrq ! ! ! ! received 1547 ! ! ! ! ! ! by i-HA 1548 ! ! <------- ! ! ! ! 1549 ! ! rrp ! ! ! ! 1550 ! ! ! ! ! ! 1551 ! [wait for detection period for response from i-HA] ! 1552 ! [may also retransmit to i-HA, depending on config] ! no rrp 1553 ! ! ! ! ! ! from i-HA 1554 ! ! ==(1)==> ! ! ! ! 1555 ! ! ike {1a}! -------> ! ! ! 1556 ! ! ! ike ! ! ! 1557 ! ! ! <------- ! ! ! 1558 ! ! <==(1)== ! ike ! ! ! 1559 ! ! ike ! ! ! ! 1560 : : : : : : 1561 : : : : : : 1562 ! ! ! ! ! ! 1563 ! ! ==(2)==> ! ! ! ! 1564 ! ! rrq {2a}! ==(1)==> ! ! ! 1565 ! ! ! rrq {2b}! -------> ! ! 1566 ! ! ! ! rrq {2c}! ! 1567 ! ! ! ! <------- ! ! 1568 ! ! ! <==(1)== ! rrp ! ! 1569 ! ! <==(2)== ! rrp ! ! ! 1570 ! ! rrp ! ! ! ! 1571 ! ! ! ! ! ! 1572 [[--- connection setup ok, bidirectional connection up ---]] 1573 ! ! ! ! ! ! 1574 ! -------> ! ! ! ! ! 1575 ! pkt {3a}! ==(3)==> ! ! ! ! 1576 ! ! pkt {3b}! ==(2)==> ! ! ! 1577 ! ! ! pkt {3c}! ==(1)==> ! ! 1578 ! ! ! ! pkt {3d}! -------> ! 1579 ! ! ! ! ! pkt {3e}! 1580 ! ! ! ! ! <------- ! 1581 ! ! ! ! <==(1)== ! pkt ! 1582 ! ! ! <==(2)== ! pkt ! ! 1583 ! ! <==(3)== ! pkt ! ! ! 1584 ! <------ ! pkt ! ! ! ! 1585 ! pkt ! ! ! ! ! 1586 : : : : : : 1587 : : : : : : 1589 The notation "==(N)==>" or "<==(N)==" indicates that the innermost 1590 packet has been encapsulated N times, using IP-IP, ESP, or MIP NAT 1591 traversal. 1593 Packets marked with {xx} are shown in more detail below. Each area 1594 represents a protocol header (labeled). Source and destination 1595 addresses or ports are shown underneath the protocol name when 1596 applicable. Note that there are no NAT traversal headers in the 1597 example packets. 1599 Packet {1a} 1600 .------------------------------------. 1601 ! IP ! IP ! UDP ! IKE ! 1602 ! co-CoA ! x-HoA ! 500 ! ! 1603 ! x-HA ! VPN-GW ! 500 ! ! 1604 `------------------------------------' 1606 Packet {2a} 1607 .--------------------------------------------------------. 1608 ! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ ! 1609 ! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! ! 1610 ! x-HA ! VPN-GW ! ! i-HA ! 434 ! ! 1611 `--------------------------------------------------------' 1613 Packet {2b} 1614 .----------------------------------------------. 1615 ! IP ! ESP ! IP ! UDP ! MIP RRQ ! 1616 ! x-HoA ! ! VPN-TIA ! ANY ! ! 1617 ! VPN-GW ! ! i-HA ! 434 ! ! 1618 `----------------------------------------------' 1620 Packet {2c} 1621 .----------------------------. 1622 ! IP ! UDP ! MIP RRQ ! 1623 ! VPN-TIA ! ANY ! ! 1624 ! i-HA ! 434 ! ! 1625 `----------------------------' 1627 Packet {3a} 1628 .-------------------. 1629 ! IP ! user ! 1630 ! i-HoA ! protocol ! 1631 ! CN ! ! 1632 `-------------------' 1634 Packet {3b} 1635 .------------------------------------------------------- - 1636 ! IP ! IP ! ESP ! IP ! IP ! user \ 1637 ! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../ 1638 ! x-HA ! VPN-GW ! ! i-HA ! CN ! \ 1639 `------------------------------------------------------- - 1640 - - -----------------. 1641 \..user ! ESP ! 1642 / protocol ! trailer ! 1643 \ ! ! 1644 - - -----------------' 1646 Packet {3c} 1647 .--------------------------------------------------------. 1648 ! IP ! ESP ! IP ! IP ! user ! ESP ! 1649 ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer ! 1650 ! VPN-GW ! ! i-HA ! CN ! ! ! 1651 `--------------------------------------------------------' 1653 Packet {3d} 1654 .------------------------------. 1655 ! IP ! IP ! user ! 1656 ! VPN-TIA ! i-HoA ! protocol ! 1657 ! i-HA ! CN ! ! 1658 `------------------------------' 1660 Packet {3e} 1661 .-------------------. 1662 ! IP ! user ! 1663 ! i-HoA ! protocol ! 1664 ! CN ! ! 1665 `-------------------' 1667 Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is 1668 shown below for comparison. 1670 Packet {3b} (with NAT traversal headers) 1671 .------------------------------------------------- - 1672 ! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \ 1673 ! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! / 1674 ! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \ 1675 `------------------------------------------------- - 1676 <=== external MIPv4 ====> <=== IPsec ESP ======== = = 1678 - - ------------------------------------------------ - 1679 \..ESP ! IP ! UDP ! MIP ! IP ! user \ 1680 / ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../ 1681 \ ! i-HA ! 434 ! data ! CN ! \ 1682 - - ------------------------------------------------ - 1683 = ===> <==== internal MIPv4 ====> <== user packet == = 1685 - - -----------------. 1686 \..user ! ESP ! 1687 / protocol ! trailer ! 1688 \ ! ! 1689 - - -----------------' 1690 = = ======> <= ESP => 1692 Appendix B. Changes 1694 Changes from draft-ietf-mip4-vpn-problem-solution-04 to 1695 draft-ietf-mip4-vpn-problem-solution-05: 1697 o Clarification of why IPsec and IKE specifics related to "useipsec" 1698 are not discussed: added text to Overview. 1700 o Document category changed from BCP to STD, because new protocol 1701 elements are now introduced for network detection. 1703 Changes from draft-ietf-mip4-vpn-problem-solution-03 to 1704 draft-ietf-mip4-vpn-problem-solution-04: 1706 o Minor corrections and editorial changes: 1708 * Intended status explicit. 1710 * Remove "no MIPv4 changes" from abstract and Introduction. 1712 * Firewall assumptions for i-HA and network detection security 1713 more explicitly mentioned in security considerations. 1715 * T_MONITOR configuration knob stated as a new MN parameter. 1717 * Wording of second and third bullets in Section 3.3 changed to 1718 reflect comment from Suresh Krishnan. 1720 * The term "inside" was clarified in Section 3.6 to be more 1721 explicit. 1723 * Topology figure moved to right after the first paragraph of 1724 Section 2 to improve readability. 1726 * More explicit handling of the case where i-HA and x-HA have the 1727 same address in Section 3.4. 1729 * Pseudo NAT attack impact stated more clearly in Security 1730 Considerations. 1732 * Added informative reference to "IPsec DHCP", and clarified that 1733 "mode config" is a "de facto" standard only. 1735 * Explicitly mention that IPsec must not be bypassed in cvc mode 1736 regardless of use of triangular routing. 1738 * Added a paragraph about IPsec policies to Section 4.1. 1740 * Section 3.2 text made more explicit with respect to what is 1741 required of all network detection mechanisms. 1743 * Section 3.3 no longer requires that a successful RRQ/RRP 1744 exchange be necessarily trust ("MUST determine.." => "SHOULD 1745 determine.."). 1747 * Section 3.5.2 reference to "IPsec does not take a stand on..." 1748 changed to be more accurate: IPsec does not specify how and 1749 when IPsec policies are altered if network connectivity 1750 changes. 1752 * Section 5.1 reference to multi-vendor interoperability 1753 augmented with a clarification that known multi-vendor issues 1754 are software architecture related, and there are no known 1755 protocol issues for interoperability. 1757 * Section 5.4 IP-IP inspection text clarified: IP-IP encapsulated 1758 traffic can be inspected and may suffer from statefulness 1759 issues too. 1761 * "Current version" reference from Introduction removed as 1762 incorrect. 1764 * Section 1.2: "require changes" changed to "require significant 1765 changes". 1767 * Section 3.2: separate tracking of network interfaces put into a 1768 separate section for clarity. 1770 o Added a new extension used by the i-HA to indicate that it has 1771 been configured with a list of trusted networks, and that the RRQ 1772 came from a trusted address. This mechanism was added based on 1773 feedback from security review. Individual changes are: 1775 * Introduction: mention new extension. 1777 * Section 3.1: wording changes for firewall requirements; refer 1778 to the new extension. 1780 * Section 3.2.2 (Registration-based internal network detection): 1781 add requirement for checking RRP for Trusted Networks 1782 Configured extension. Rationale is given in Section 3.5. 1784 * New Section 3.4 describing the extension format. 1786 * Section 3.5.1 (Firewall configuration requirements): rationale 1787 for the new extension. 1789 * Section 4.1 (Mobile node requirements): requirement for 1790 checking i-HA RRP for Trusted Networks Configured extension. 1792 * Section 4.3 (Home agent requirements): configuration and RRQ 1793 processing requirements for i-HA. 1795 * Section 5.1 (Comparison against guidelines): Mobile IPv4 change 1796 (new extension) mentioned. 1798 * Section 6.1 (Internal network detection): new extension 1799 mentioned in firewall security consideration part. 1801 Changes from draft-ietf-mip4-vpn-problem-solution-02 to 1802 draft-ietf-mip4-vpn-problem-solution-03: 1804 o Added one paragraph to the security considerations section which 1805 explains that RRQ packets which are not IPsec protected reveal the 1806 MN's NAI and other RRQ extension information. 1808 o Added a new reference to MOBIKE instead of referring to the now 1809 closed MOBIKE working group, reworded some MOBIKE related text. 1811 o ID nits cleaned up: references and boilerplate updated, etc. 1813 Changes from draft-ietf-mip4-vpn-problem-solution-01 to 1814 draft-ietf-mip4-vpn-problem-solution-02: 1816 o Feedback from Vijay Devarapalli incorporated. 1818 o Added references to MOBIKE WG where applicable. 1820 o Changed requirement for reverse tunneling of inner MIPv4 when MN 1821 is outside, from MUST to SHOULD. Reason: not all IPsec-based VPNs 1822 have the policy limitation; in particular, L2TP/IPsec 1823 implementations do not. 1825 o Added better explanation of why reverse tunneling to i-HA is often 1826 required when the MN is outside. 1828 o Re-added latency considerations section in a simplified form. 1830 o IPR reference from RFC 3667 updated to RFC 3978. 1832 o Removed explicit IPR section, as the general reference to on-line 1833 IPR statements suffices. 1835 o Removed unused document references. 1837 o Other minor cleanups. 1839 Changes from draft-ietf-mip4-vpn-problem-solution-00 to 1840 draft-ietf-mip4-vpn-problem-solution-01: 1842 o Presentation style cleaned up in many places, wording changes 1843 throughout the document to improve readability. 1845 o More compact introduction section, terminology additions, IPsec 1846 mobility problem description shortened. 1848 o Sections 2 (topology) and 3 (access modes) merged. 1850 o Section 6.8 (shortcoming for enterprise use) removed. 1852 o Appendix A.2 (connection setup for access mode 'fvc') removed, it 1853 contained mostly duplicate information (from A.1). 1855 Changes from draft-ietf-mobileip-vpn-problem-solution-03 to 1856 draft-ietf-mip4-vpn-problem-solution-00: 1858 o Renamed and resubmitted document. 1860 o New boilerplate to match RFCs 3667 and 3668. 1862 Changes from -02 to -03: 1864 o Remaining issues from security review worked into document. 1866 o Short rationale for why (a) IPsec is not mobile, and (b) the 1867 essential problem statement assumptions added. 1869 o Minor wording changes (IETF 57 comments). 1871 o Internal network monitoring section revised with "relaxed re- 1872 registration" approach to improve applicability to battery powered 1873 devices. 1875 o IPR section needs to refer to on-line rights (and current text 1876 moved on-line). Not done yet. 1878 Changes from -01 to -02: 1880 o Packet flow examples added. 1882 o Explicit IDS reference added. 1884 o Requirement levels adjusted; NAT traversal requirements changed 1885 from MUST to SHOULD and other changes. 1887 o MN no longer required to use i-HA directly whenever available (in 1888 some cases that may not be desired). 1890 o IPR section revised. 1892 o Latency considerations section added. 1894 o External HA reachability assumption refined; if firewall properly 1895 configured, handover performance can be improved. This is now 1896 mentioned in the detection section. 1898 o Overhead section simplified, only base solution discussed. 1900 o Proposed solutions section removed from appendix. 1902 o Strawmen of optimizations removed from appendix, references to 1903 optimizations removed from text. 1905 Changes from -00 to -01: 1907 o First description of proposed solution based on basic and 1908 optimized dual HA drafts, as well as IPsec endpoint update 1909 mechanism. 1911 o List of proposed solutions in -00 included in appendix. 1913 Authors' Addresses 1915 Sami Vaarala 1916 Codebay 1917 P.O. Box 63 1918 Espoo 02601 1919 FINLAND 1921 Phone: +358 (0)50 5733 862 1922 Email: sami.vaarala@iki.fi 1924 Espen Klovning 1925 Birdstep 1926 Bryggegata 7 1927 Oslo 0250 1928 NORWAY 1930 Phone: +47 95 20 26 29 1931 Email: espen@birdstep.com 1933 Full Copyright Statement 1935 Copyright (C) The IETF Trust (2008). 1937 This document is subject to the rights, licenses and restrictions 1938 contained in BCP 78, and except as set forth therein, the authors 1939 retain all their rights. 1941 This document and the information contained herein are provided on an 1942 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1943 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1944 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1945 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1946 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1947 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1949 Intellectual Property 1951 The IETF takes no position regarding the validity or scope of any 1952 Intellectual Property Rights or other rights that might be claimed to 1953 pertain to the implementation or use of the technology described in 1954 this document or the extent to which any license under such rights 1955 might or might not be available; nor does it represent that it has 1956 made any independent effort to identify any such rights. Information 1957 on the procedures with respect to rights in RFC documents can be 1958 found in BCP 78 and BCP 79. 1960 Copies of IPR disclosures made to the IETF Secretariat and any 1961 assurances of licenses to be made available, or the result of an 1962 attempt made to obtain a general license or permission for the use of 1963 such proprietary rights by implementers or users of this 1964 specification can be obtained from the IETF on-line IPR repository at 1965 http://www.ietf.org/ipr. 1967 The IETF invites any interested party to bring to its attention any 1968 copyrights, patents or patent applications, or other proprietary 1969 rights that may cover technology that may be required to implement 1970 this standard. Please address the information to the IETF at 1971 ietf-ipr@ietf.org.