idnits 2.17.1 draft-ietf-mobileip-vpn-problem-solution-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 910 has weird spacing: '...hey are secur...' -- 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 (September 29, 2003) is 7513 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: 'VPN' on line 449 -- Looks like a reference, but probably isn't: 'R' on line 459 -- Looks like a reference, but probably isn't: 'DHCP' on line 459 == Unused Reference: '11' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1520, but no explicit reference was found in the text -- No information found for draft-ietf-mobileip-vpn-problem-statement-guide-00e - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2486 (ref. '4') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3344 (ref. '5') (Obsoleted by RFC 5944) == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-05 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-06 ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Normative reference to a draft: ref. '11' -- No information found for draft-adrangi-mobileip-mipvpn-traversal - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-01 == Outdated reference: A later version (-04) exists of draft-dupont-transient-pseudonat-01 -- Possible downref: Normative reference to a draft: ref. '16' Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP S. Vaarala (Ed.) 3 Internet-Draft Netseal 4 Expires: March 29, 2004 September 29, 2003 6 Mobile IPv4 Traversal Across IPsec-based VPN Gateways 7 draft-ietf-mobileip-vpn-problem-solution-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on March 29, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document outlines the proposed solution for the Mobile IPv4 and 38 IPsec coexistence problem for enterprise users. The solution consists 39 of an applicability statement for using Mobile IPv4 and IPsec for 40 session mobility in corporate remote access scenarios, and a required 41 mechanism for detecting the trusted internal network securely. The 42 solution requires only changes to the mobile node; changes to Mobile 43 IPv4 or IPsec are not required. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . 6 51 1.4 Terms and abbreviations . . . . . . . . . . . . . . . . . . 6 52 1.5 Requirement levels . . . . . . . . . . . . . . . . . . . . . 7 53 1.6 Assumptions and rationale . . . . . . . . . . . . . . . . . 7 54 1.7 Why IPsec lacks mobility . . . . . . . . . . . . . . . . . . 9 55 2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 3. Access modes . . . . . . . . . . . . . . . . . . . . . . . . 14 57 3.1 Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . . 15 58 3.2 Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . . 15 59 3.3 Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . . 16 60 3.4 Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . . 16 61 3.5 NAT traversal . . . . . . . . . . . . . . . . . . . . . . . 17 62 4. Internal network detection . . . . . . . . . . . . . . . . . 18 63 4.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 19 64 4.2 Implementation requirements . . . . . . . . . . . . . . . . 19 65 4.2.1 Connection status change . . . . . . . . . . . . . . . . . . 19 66 4.2.2 Registration-based internal network detection . . . . . . . 20 67 4.2.3 Registration-based internal network monitoring . . . . . . . 20 68 4.2.4 Handling of network interfaces . . . . . . . . . . . . . . . 21 69 4.3 Proposed algorithm . . . . . . . . . . . . . . . . . . . . . 21 70 4.4 Implementation issues . . . . . . . . . . . . . . . . . . . 23 71 4.5 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 23 72 4.5.1 Firewall configuration requirements . . . . . . . . . . . . 24 73 4.5.2 Registration-based internal network monitoring . . . . . . . 24 74 4.5.3 No encryption when inside . . . . . . . . . . . . . . . . . 24 75 4.6 Improvements . . . . . . . . . . . . . . . . . . . . . . . . 25 76 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 26 77 5.1 Mobile node requirements . . . . . . . . . . . . . . . . . . 26 78 5.2 VPN device requirements . . . . . . . . . . . . . . . . . . 26 79 5.3 Home agent requirements . . . . . . . . . . . . . . . . . . 26 80 6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 6.1 Comparison against guidelines . . . . . . . . . . . . . . . 27 82 6.2 Packet overhead . . . . . . . . . . . . . . . . . . . . . . 28 83 6.3 Latency considerations . . . . . . . . . . . . . . . . . . . 29 84 6.4 Firewall state considerations . . . . . . . . . . . . . . . 30 85 6.5 Intrusion detection systems (IDSs) . . . . . . . . . . . . . 31 86 6.6 Implementation of mobile node . . . . . . . . . . . . . . . 31 87 6.7 Non-IPsec VPN protocols . . . . . . . . . . . . . . . . . . 31 88 6.8 Shortcomings for enterprise use . . . . . . . . . . . . . . 32 89 7. Security considerations . . . . . . . . . . . . . . . . . . 33 90 7.1 Internal network detection . . . . . . . . . . . . . . . . . 33 91 7.2 Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . . 33 92 8. Intellectual property rights . . . . . . . . . . . . . . . . 35 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 94 References . . . . . . . . . . . . . . . . . . . . . . . . . 37 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . 38 96 A. Packet flow examples . . . . . . . . . . . . . . . . . . . . 39 97 A.1 Connection setup for access mode 'cvc' . . . . . . . . . . . 39 98 A.2 Connection setup for access mode 'fvc' . . . . . . . . . . . 43 99 B. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 46 100 Intellectual Property and Copyright Statements . . . . . . . 48 102 1. Introduction 104 The Mobile IP working group started a design team to explore the 105 problem and solution spaces of IPsec and Mobile IP coexistence. The 106 problem statement and solution requirements for Mobile IPv4 case was 107 first documented in [1]. The design team then set out to evaluate 108 solution candidates and ultimately arrive at a solution draft. 110 The current version of this document outlines the proposed solution 111 for IPv4. The solution places only requirements on the 112 implementation of the mobile node and requires no changes to existing 113 standards. 115 This document contains two parts: 117 o a basic solution which is an applicability statement of Mobile 118 IPv4 and IPsec to provide session mobility between internal and 119 external networks, intended for enterprise mobile users; and 121 o a technical specification and a set of requirements for secure 122 detection of the internal and the external networks. 124 There is no single solution for combining Mobile IPv4 with IPsec; by 125 changing the requirements and assumptions one ends up with different 126 solutions. The solution specified in this document is most 127 applicable when the assumption documented in the problem statement 128 [1] are valid; among others that the solution: 130 o must minimize changes to existing firewall/VPN/DMZ deployments; 132 o must ensure that traffic is not routed through the DMZ when the 133 mobile node is inside (to avoid scalability and management 134 issues); 136 o must support foreign networks with only foreign agent access; 138 o should not require changes to existing IPsec or key exchange 139 standards; 141 o must adhere to the Mobile IPv4 protocol (but may require new 142 extensions or multiple instances of Mobile IPv4); and 144 o must propose a mechanism to avoid or minimize IPsec re-negotiation 145 when mobile node moves. 147 Two crucial assumptions with regards to the specified solution are 148 the "existing DMZ" assumption, and the assumption that traffic cannot 149 be routed through the DMZ when the mobile node is inside. More 150 optimal solutions are possible by relaxing assumptions and 151 requirements; however, these are out of scope of this document. 153 1.1 Overview 155 Typical corporate networks consist of three different domains: the 156 Internet (untrusted external network), the intranet (trusted internal 157 network), and the DMZ, which connects the two networks. Access to 158 the internal network is guarded both by a firewall and a VPN device; 159 access is only allowed if both firewall and VPN security policies are 160 respected. 162 Enterprise mobile users benefit from unrestrained seamless session 163 mobility between subnets, regardless of whether the subnets are part 164 of the internal or the external network. Unfortunately the current 165 Mobile IPv4 and IPsec standards alone do not provide such a service 166 [14]. 168 The proposed solution is to use standard Mobile IPv4 when the mobile 169 node is in the internal network, and to use the inner address of a 170 VPN tunnel (VPN-TIA) as a co-located care-of address for Mobile IPv4 171 registration when outside. IPsec-based VPN tunnels require 172 re-negotiation after movement; thus, some additional mechanism must 173 deal with mobility when the MN is outside. 175 The external mobility is provided by another layer of Mobile IPv4 176 underneath IPsec, in effect making IPsec unaware of movement. Thus, 177 the mobile node can freely move in the external network without 178 disrupting the VPN connection. The downside of this approach is that 179 an external home agent is required, and that the packet overhead is 180 considerable (see Section 6). 182 Briefly, when outside, the mobile node: 184 o detects (securely) that it is outside (Section 4); 186 o registers its co-located or foreign agent care-of address with the 187 external home agent; 189 o establishes a VPN tunnel using e.g. IKE (or IKEv2) if security 190 associations are not already available; 192 o registers the VPN tunnel inner address (VPN-TIA) as its co-located 193 care-of address with the internal home agent; this registration 194 request is sent inside the IPsec tunnel. 196 The solution requires some control over the protocol layers in the 197 mobile node. The mobile node must be capable of (1) detecting 198 whether it is inside or outside in a secure fashion, and (2) control 199 the protocol layers accordingly. For instance, if the mobile node is 200 inside, the IPsec layer needs to become dormant. 202 Current Mobile IPv4 and IPsec standards, when used in a suitable 203 combination, are sufficient to implement the solution; no changes are 204 required to existing VPN devices, home agents, or foreign agents. 205 Although the basic solution has a number of shortcomings, especially 206 in terms of overhead and complexity, optimizations that require 207 changes to Mobile IPv4 or IPsec are out of scope of this document. 208 These will be pursued as separate work items. 210 1.2 Scope 212 This document describes a solution for IPv4 only. 214 VPN, in this document, refers to an IPsec-based remote access VPN. 215 Other types of VPNs are out of scope. 217 1.3 Related work 219 Related work has been done on Mobile IPv6 in [15] which discusses the 220 interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6 221 signaling. The draft also discusses dynamic updating of the IPsec 222 endpoint based on Mobile IP signaling packets. 224 The "transient pseudo-NAT" attack, described in [16] and [6], affects 225 any approach which attempts to provide security of mobility signaling 226 in conjunction with NAT devices. In many cases, one cannot assume any 227 co-operation from NAT devices which thus have to be treated as 228 "adversaries" of a sort. 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 that a 240 private network (e.g. another corporate network) other than the 241 mobile node's internal network is considered an external network. 243 FA-CoA: foreign agent care-of address 244 internal network: the trusted network; for instance, a physically 245 secure corporate network where the i-HA is located. 247 inside: in the internal network; each network interface may be 248 independently inside or outside 250 i-FA: Mobile IPv4 foreign agent residing in the internal network 252 i-HA: Mobile IPv4 home agent residing in the internal network; 253 typically has a private address [7] 255 i-HoA: home address of the mobile node in the internal home agent 257 NAI: Network Access Identifier [4] 259 outside: in the external network; each network interface may be 260 independently inside or outside 262 VPN-TIA: VPN tunnel inner address, the address(es) negotiated during 263 IKE phase 2 (quick mode), assigned manually, using IPsec-DHCP, 264 using mode config, or by some other means. Some VPN clients use 265 their current care-of address as their TIA for architectural 266 reasons. 268 VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode 269 IPsec connection, or L2TP combined with IPsec transport 270 connection. 272 x-FA: Mobile IPv4 foreign agent residing in the external network 274 x-HA: Mobile IPv4 home agent residing in the external network 276 x-HoA: home address of the mobile node in the external home agent 278 1.5 Requirement levels 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 282 document are to be interpreted as described in RFC 2119 [2]. 284 1.6 Assumptions and rationale 286 The proposed solution is an attempt to solve the problem described in 287 [1]. The major assumptions and their rationale is summarized below. 289 Changes to existing firewall and VPN deployments should be minimized: 291 o The current deployment of firewalls and IPsec-based VPNs is much 292 larger than corresponding Mobile IPv4 elements. Thus a solution 293 should work within the existing infrastructure to be deployable in 294 the short run. 296 o Current enterprise network deployments typically centralize 297 management of security and network access into a compact DMZ. 299 When mobile node is inside, traffic should not go through the DMZ 300 network: 302 o Routing all mobile node traffic through the DMZ is seen as a 303 performance problem in existing deployments of firewalls. The 304 more sophisticated firewall technology is used (e.g. content 305 scanning), the more serious the performance problem is. 307 o Current deployments of firewalls and DMZs in general have been 308 optimized for the case where only a small minority of total 309 enterprise traffic goes through the DMZ. Furthermore, users of 310 current VPN remote access solutions "switch off" and access their 311 network without going through the DMZ when inside. 313 Home agent inside the enterprise cannot be reached directly from 314 outside, even if the home agent contains IPsec functionality: 316 o Deployment of current combined IPsec/MIPv4 solutions are not 317 common in large installations. 319 o Doing decryption in the home agents "deep inside" the enterprise 320 effectively means having a security perimeter much larger than the 321 typical, compact DMZ used by a majority of enterprises today. 323 o In order to maintain a security level equal to current firewall/ 324 DMZ deployments, every home agent decapsulating IPsec would need 325 to do the same firewalling as the current DMZ firewalls (content 326 scanning, connection tracking, etc). 328 Traffic cannot be encrypted when the mobile node is inside: 330 o There is a considerable performance impact on home agents (which 331 currently do rather light processing), and mobile nodes 332 (especially for small devices). Note that traffic throughput 333 inside the enterprise is typically order(s) of magnitude larger 334 than the remote access traffic through a VPN. 336 o Encryption consumes processing power and has a consequent impact 337 on device battery life. 339 o There is also a usability issue involved; the user needs to 340 authenticate connection to the IPsec layer in the home agent to 341 gain access. For interactive authentication mechanisms (such as 342 SecurID, which is quite widely used) this always means user 343 interaction. 345 o Furthermore, if there is a separate VPN device in the DMZ for 346 remote access, the user needs to authenticate to both devices, and 347 might need to have separate credentials for both. 349 o Current Mobile IPv4 home agents do not typically incorporate IPsec 350 functionality, which is relevant for the proposed solution when we 351 assume zero or minimal changes to existing Mobile IPv4 nodes. 353 o Note, however, that the assumption (no encryption when inside) 354 does not necessarily apply to all solutions in the solution space; 355 if the abovementioned problems were resolved there is no 356 fundamental reason why encryption could not be applied when 357 inside. 359 1.7 Why IPsec lacks mobility 361 IPsec, as currently specified [3] requires that a new IKE negotiation 362 be done whenever an IPsec peer moves (i.e. changes care-of address). 363 There are multiple reasons for the limitation, outlined below. 365 A security association is uni-directional, and identified by a 366 triplet consisting of (1) the destination address (which is the outer 367 address when tunnel mode is used), (2) the security protocol (ESP or 368 AH), and (3) the Security Parameter Index (SPI) ([3], Section 4.1). 369 Although an implementation is not required to use all of these for 370 its own SAs, an implementation cannot assume that a peer does not. 372 When a mobile IPsec peer sends packets to a stationary IPsec peer, 373 there is no problem; the SA is "owned" by the stationary IPsec peer, 374 and therefore the destination address does not need to change. The 375 (outer) source address should be ignored by the stationary peer 376 (although some implementations do check the source address as well). 378 The problem arises when packets are sent from the stationary peer to 379 the mobile peer. The destination address of this SA (SAs are 380 unidirectional) is established during IKE negotiation, and is 381 effectively the care-of address of the mobile peer at time of 382 negotiation. Therefore the packets will be sent to the original 383 care-of address, not a changed care-of address. 385 There is no standardized way of updating the destination address of 386 the SA for the stationary-to-mobile direction -- other than using a 387 new IKE negotiation to create a new pair of SAs. Some vendors have 388 implemented and deployed an implicit mechanism where a properly 389 authenticated inbound packet received by the stationary peer causes 390 the corresponding destination address (mobile peer care-of address) 391 to be updated from the received packet. This allows, in effect, for 392 mobility without signaling, although having minor traffic redirection 393 vulnerabilies. 395 The IPsec NAT traversal mechanism can also be used for limited 396 mobility, but UDP tunneling needs to be used even when there is no 397 NAT in the route between the mobile and the stationary peers. 398 Furthermore, support for changes in current NAT mapping is not 399 required by the NAT traversal specification (draft). Section 7 of [8] 400 states: 402 There are cases where NAT box decides to remove mappings that 403 are still alive (for example, the keepalive interval is too 404 long, or the NAT box is rebooted). To recover from those ends 405 which are NOT behind NAT SHOULD use the last valid 406 authenticated packet from the other end to determine which IP 407 and port addresses should be used. The host behind dynamic 408 NAT MUST NOT do this as otherwise it opens DoS attack 409 possibility, and there is no need for that, because the IP 410 address or port of other host will not change (it is not 411 behind NAT). 413 Keepalives cannot be used for this purposes as they are not 414 authenticated, but any IKE authenticated IKE packet or ESP 415 packet can be used to detect that the IP address or the port 416 has changed. 418 Also, if no NAT is detected during IKE negotiation, UDP encapsulation 419 is not used, and consequently the endpoint updating mentioned above 420 is not available. 422 In summary, although the IPsec standard does not as such prevent 423 mobility (in the sense of updating security associations on-the-fly), 424 there is no standardized mechanism (explicit or implicit) for doing 425 so. Therefore it is assumed throughout this document that any change 426 in the addresses comprising the identity of an SA requires IKE 427 re-negotiation, which implies too heavy computation and too large 428 latency for useful mobility. 430 A standard "mobile IPsec" would be an effective replacement for the 431 external Mobile IPv4 layer proposed in this document. However, even 432 if such a standard existed, there would still be the problem of 433 networks where the only available access is through a Mobile IPv4 434 foreign agent. 436 2. Topology 438 The following figure describes an example network topology 439 illustrating the relationship between the internal and external 440 networks, the possible locations of the mobile node ("MN" in 441 parenthesis). The access modes (described later in Section 3) 442 available to the mobile node from each location are also shown in 443 curly braces. 445 (MN) {fvc} {home} (MN) [i-HA] 446 ! \ / 447 .--+---. .-+---+-. 448 ( ) ( ) 449 `--+---' [VPN] `--+----' 450 \ ! ! 451 [R/FA] [x-HA] .--+--. [R] 452 \ / ( DMZ ) ! 453 .-+-------+--. `--+--' .-----+------. 454 ( ) ! ( ) 455 ( external net +---[R]----[FW]----[R]--+ internal net ) 456 ( ) ( ) 457 `--+---------' `---+---+----' 458 / / \ 459 [DHCP] [R] [DHCP] [R] [R] [i-FA] 460 \ / \ / \ / 461 .+--+---. .-+-+--. .--+--+-. 462 ( ) ( ) ( ) 463 `---+---' `--+---' `---+---' 464 ! ! ! 465 (MN) {cvc} (MN) {c} (MN) {f} 467 Figure: Basic topology, possible MN locations and access modes 469 The internal network is typically a multi-subnetted network which 470 uses private addressing [7]. Subnets may contain internal home 471 agent(s) (typically using private addresses), DHCP server(s), and/or 472 foreign agent(s). Current IEEE 802.11 wireless LANs are typically 473 deployed in the external network or the DMZ because of security 474 concerns. 476 The external network term used in this document includes the public 477 Internet, and private networks other than the mobile node's internal 478 network. 480 The de-militarized zone (DMZ) is a tiny network typically containing 481 servers that need to be accessed from both internal and external 482 networks; for instance, VPN devices. 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, although this is not typical. 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. (Thus, reverse tunneling SHOULD always 502 be used.) 504 o Trusted foreign agents (in this context referring to foreign 505 agents connected to the internal network using an IPsec tunnel) 506 are not shown. Trusted foreign agents are logically part of the 507 internal network. 509 o The figure represents a "canonical" topology where each functional 510 entity is illustrated as a separate device. However, it is 511 possible that in a physical network several functions are 512 co-located in a single device (for instance, the x-HA and VPN 513 functionalities). In fact, all three server components (x-HA, VPN, 514 and i-HA) may be co-located in a single physical device. 516 The following issues are also important when considering enterprise 517 mobile users: 519 o Some firewalls are configured to block ICMP messages and/or 520 fragments. Such firewalls (routers) cannot be detected reliably. 522 o Some networks contain transparent application proxies, especially 523 for the HTTP protocol. Like firewalls, such proxies cannot be 524 detected reliably in general. IPsec and Mobile IPv4 are 525 incompatible with such networks. 527 3. Access modes 529 In every possible location described in Section 2 the mobile node can 530 establish a connection to its i-HA by using a suitable "access mode". 531 An access mode is here defined to consist of: 533 1. a composition of the mobile node networking stack (i-MIP or 534 x-MIP/VPN/i-MIP); and 536 2. registration mode(s) of i-MIP and x-MIP (if used); i.e. 537 co-located care-of address or foreign agent care-of address. 539 Each possible access mode is encoded as "xyz", where: 541 o "x" indicates whether the x-MIP layer is used, and if used, the 542 mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence 543 indicates not used); 545 o "y" indicates whether the VPN layer is used ("v" indicates VPN 546 used, absence indicates not used); 548 o "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c" 549 indicates co-CoA). 551 This results in four access modes: 553 c: i-MIP w/ co-CoA 554 f: i-MIP w/ FA-CoA 555 cvc: x-MIP w/ co-CoA, VPN-TIA as i-MIP co-CoA 556 fvc: x-MIP w/ FA-CoA, VPN-TIA as i-MIP co-CoA 558 This notation is more useful when optimizations to protocol layers 559 are considered. The notation is preserved here so that work on the 560 optimizations can refer to a common notation. 562 Whenever a mobile node obtains either a co-CoA (using e.g. DHCP) or a 563 FA-CoA (from a foreign agent advertisement), the following steps 564 (conceptually) take place: 566 o The mobile node detects whether the subnet where the care-of 567 address was obtained belongs to the internal or the external 568 network using the method described in Section 4 (or a vendor 569 specific mechanism fulfilling the requirements described). 571 o The mobile node performs necessary registrations and other 572 connection setup signaling for the protocol layers (in the 573 following order): 575 * x-MIP (if used); 577 * VPN (if used); and 579 * i-MIP. 581 Note that these two tasks are intertwined to some extent: detection 582 of internal network results in a successful registration to the i-HA 583 using the proposed network detection algorithm, for instance. An 584 improved network detection mechanism not based on Mobile IPv4 585 registration messages might not have this side-effect. 587 The following subsections describe the different access modes and the 588 requirements for registration and connection setup phase. 590 3.1 Access mode: 'c' 592 This access mode is standard Mobile IPv4 [5] with a co-located 593 address, except that: 595 o the mobile node MUST detect that it is in the internal network; 596 and 598 o the mobile node MUST re-register periodically (with a configurable 599 interval) to ensure it is still inside the internal network (see 600 Section 5). 602 The registration request SHOULD have T-bit reverse tunneling) set. 603 Reverse tunneling allows Mobile IPv4 to be used even in the presence 604 of ingress filtering. Since some site-to-site VPN tunnels perform 605 ingress filtering as a side effect of IPsec policy processing, 606 reverse tunneling should be used to increase interoperability. 608 3.2 Access mode: 'f' 610 This access mode is standard Mobile IPv4 [5] with a foreign agent 611 care-of address, except that 613 o the mobile node MUST detect that it is in the internal network; 614 and 616 o the mobile node MUST re-register periodically (with a configurable 617 interval) to ensure it is still inside the internal network (see 618 Section 5). 620 The registration request SHOULD request reverse tunneling (see 621 Section 3.1). 623 3.3 Access mode: 'cvc' 625 Steps: 627 o The mobile node obtains a care-of address from e.g. a DHCP server. 629 o The mobile node detects it is outside and registers with the x-HA 630 (possibly as a side effect of the detection process), where 632 * D-bit MUST be set (co-located) 634 * T-bit SHOULD be set (reverse tunneling) 636 o If the mobile node does not have an existing IPsec security 637 association, it uses IKE to set up an IPsec security association 638 with the VPN gateway, using the x-HoA as the IP address for IKE/ 639 IPsec communication. The VPN-TIA is assigned in some manner (or 640 chosen by the MN). VPN capability negotiation is done at the same 641 time. 643 o The mobile node sends a MIPv4 RRQ to the i-HA, registering the 644 VPN-TIA as a co-located care-of address, where 646 * D-bit MUST be set (co-located) 648 * T-bit MUST be set (reverse tunneling) 650 3.4 Access mode: 'fvc' 652 Steps: 654 o The mobile node obtains a foreign agent advertisement from the 655 local network. 657 o The mobile node detects it is outside and registers with the x-HA 658 (possibly as a side effect of the detection process), where 660 * D-bit MUST NOT be set (foreign agent) 662 * T-bit SHOULD be set (reverse tunneling) 664 o If necessary, the mobile node uses IKE to set up an IPsec 665 connection with the VPN gateway, using the x-HoA as the IP address 666 for IKE/IPsec communication. The VPN-TIA is assigned in some 667 manner (or chosen by the MN). VPN capability negotiation is done 668 at the same time. 670 o The mobile node sends a MIPv4 RRQ to the i-HA, registering the 671 VPN-TIA as a co-located care-of address, where 673 * D-bit MUST be set (co-located) 675 * T-bit MUST be set (reverse tunneling) 677 3.5 NAT traversal 679 NAT devices may affect each layer independently (and even all three 680 layers at the same time). Mobile IPv4 NAT traversal MUST be used 681 for x-MIP and i-MIP layers, while IPsec NAT traversal [8][9] MUST be 682 used for VPN layer. 684 Note that NAT traversal for the internal MIPv4 layer may be necessary 685 even when there is no separate NAT device between the VPN gateway and 686 the internal network. Some VPN implementations NAT VPN tunnel inner 687 addresses before routing traffic to the intranet. Sometimes this is 688 done to make a deployment easier, but in some cases this approach 689 makes VPN client implementation easier. Mobile IPv4 NAT traversal is 690 required to establish a MIPv4 session in this case. 692 4. Internal network detection 694 Secure detection of the internal network is security critical: if the 695 mechanism fails for some reason, plaintext traffic may be sent to an 696 untrusted network. In other words, the overall security 697 (confidentiality and integrity of user data) is a minimum of IPsec 698 security and the internal network detection mechanism security. For 699 this reason, a set of requirements relevant to security are described 700 in this section. 702 In addition to detecting entry into the internal network, the mobile 703 node must also detect when it leaves the internal network. Entry into 704 the internal network is easier security-wise: the mobile node can 705 take all the time it needs to ensure that it is inside the internal 706 network before sending any plaintext traffic. Exit from the internal 707 network is more difficult to detect, and the MN may accidentally leak 708 plaintext packets if the event is not detected properly. 710 Several events cause the mobile node to exit the internal network, 711 for instance: 713 o a routing change upstream; 715 o a reassociation of 802.11 on layer 2 which the mobile node 716 software does not detect; 718 o a physical cable disconnect and reconnect which the mobile node 719 software does not detect. 721 Whether the mobile node can detect such changes in the current 722 connection reliably depends on the implementation. For instance, 723 some mobile nodes may be implemented as pure layer three entities. 724 Even if the mobile node software has access to layer two information, 725 such information is not trustworthy security-wise (and depends on the 726 network interface driver). 728 If the mobile node does not detect these events properly, it may leak 729 plaintext traffic into an untrusted network. A number of approaches 730 can be used to detect exit from the internal network, ranging from 731 frequent re-registration to the use of layer two information. 733 A mobile node MUST implement a detection mechanism fulfilling the 734 requirements described in Section 4.2; this ensures that basic 735 security requirements are fulfilled. The basic algorithm described in 736 Section 4.3 is one way to do that, but alternative methods may be 737 used instead or in conjunction. The assumptions that the 738 requirements and the proposed mechanism rely upon are described in 739 Section 4.1. 741 4.1 Assumptions 743 The firewall MUST be configured to block traffic originating from 744 external networks going to the i-HA. In other words, if the mobile 745 node succeeds in registering with the i-HA directly (without using 746 IPsec), the mobile node may safely infer that it is connected to the 747 trusted internal network, and may therefore use plaintext traffic. 749 The firewall MAY be configured to block registration traffic to the 750 x-HA originating from within the internal network, which makes the 751 network detection algorithm simpler and more robust. However, as the 752 registration request is basically UDP traffic, an ordinary firewall 753 (even a stateful one) would typically allow the registration request 754 to be sent, and a registration reply to be received through the 755 firewall. 757 4.2 Implementation requirements 759 Any mechanism used to detect the internal network MUST fulfill the 760 following requirements. 762 4.2.1 Connection status change 764 When the mobile node detects that its connection status on a certain 765 network interface changes, the mobile node MUST: 767 o immediately stop relaying user data packets; 769 o detect whether this interface is connected to the internal or the 770 external network; 772 o resume data traffic only after the internal network detection and 773 necessary registrations and VPN tunnel establishment have been 774 completed. 776 The mechanism used to detect a connection status change depends on 777 the mobile node implementation and the access mode. The connection 778 status is considered to change whenever any of the following happens: 780 o when the interface is connected to the internal network, the i-HA 781 can no longer be reached using a re-registration; 783 o the next hop router is no longer reachable (e.g. ARP fails); 785 o when using an FA, FA advertisements from the FA used for 786 registration are no longer received; or 788 o layer two or other such information indicates that the physical 789 connection status has changed. 791 The mobile node MUST detect the first event, i.e. failure to 792 re-register when inside. Detecting the other events is RECOMMENDED. 794 4.2.2 Registration-based internal network detection 796 The mobile node MUST NOT infer that an interface is connected to the 797 internal network unless a successful registration has been completed 798 through that particular interface and the connection status of the 799 interface has not changed since. 801 4.2.3 Registration-based internal network monitoring 803 Some leak of plaintext packets to a (potentially) untrusted network 804 cannot always be completely prevented; this depends heavily on the 805 client implementation. In some cases the client cannot detect such a 806 change (for instance if the subnet is reconnected to another place in 807 the network topology in its entirety). 809 To bound the maximum amount of time that such a leak may persist, the 810 mobile node must fulfill the following security requirements when 811 inside: 813 o The mobile node MUST NOT send or receive a user data packet (i.e. 814 any IPv4 packet other than a Mobile IPv4 signaling packet) if more 815 than T_MONITOR seconds has elapsed since last successful 816 (re-)registration with the i-HA. 818 o If more than T_MONITOR seconds has elapsed, data packets MUST be 819 either dropped or queued. If the packets are queued, the queues 820 MUST NOT be processed until the re-registration has been 821 successfully completed without a connection status change. 823 o The T_MONITOR parameter MUST be configurable, and have the default 824 value of 60 seconds. This default is a trade-off between traffic 825 overhead and a reasonable bound to exposure. 827 A simple approach to fulfill the requirement is to start 828 re-registration every T_MONITOR-N seconds when inside (where N is a 829 grace period which ensures that re-registration is completed before 830 T_MONITOR seconds are up). This approach is reasonable for a wide 831 range of mobile nodes (e.g. laptops), but has unnecessary overhead 832 when the mobile node is idle (not sending or receiving packets). If 833 re-registration does not complete before T_MONITOR seconds are up, 834 data packets must be queued or dropped as specified above. Note that 835 re-registration packets must be sent even if bi-directional user data 836 traffic is being relayed: data packets are no substitute for an 837 authenticated re-registration. 839 To minimize traffic overhead when the mobile node is idle, 840 re-registrations can be stopped when no traffic is being sent or 841 received. If the mobile node subsequently receives or needs to send a 842 packet, the packet must be dropped or queued (as specified above) 843 until a re-registration with the i-HA has been successfully 844 completed. This "relaxed re-registration" approach, although adding 845 some packet processing complexity, may be appropriate for small 846 battery powered devices which may be idle much of the time. (Note 847 that ordinary re-registration before the mobility binding lifetime is 848 exhausted should still be done.) 850 T_MONITOR is required to be configurable so that an administrator can 851 determine the required security level for the particular deployment. 852 Configuring T_MONITOR to a very small value (i.e. in the order of few 853 seconds) is not practical; alternative mechanisms need to be 854 considered if such confidence is required. 856 The re-registration mechanism is a worst case fallback mechanism. If 857 additional information (such as layer two triggers) are available to 858 the mobile node, the mobile node SHOULD use the triggers to detect 859 when it has (potentially) moved and restart the detection process to 860 minimize exposure. 862 Note that re-registration is required by Mobile IPv4 by default 863 (except for the untypical case of an infinite binding lifetime); 864 however, the re-registration interval may be much larger when using 865 an ordinary Mobile IPv4 client. Shorter re-registration interval is 866 usually not an issue, because the internal network is typically a 867 fast, wired network, and the shortened re-registration interval 868 applies only when the mobile node is inside the internal network. 869 Furthermore, battery powered devices may use the "relaxed 870 re-registration" approach to conserve power when no traffic is being 871 sent or received. When outside, the ordinary Mobile IPv4 872 re-registration process (based on binding lifetime) is used. 874 4.2.4 Handling of network interfaces 876 The mobile node implementation MUST track each network interface 877 separately. Successful registration with the i-HA through interface 878 X does not imply anything about the status of interface Y. 880 4.3 Proposed algorithm 882 When the MN detects that it has changed its point of network 883 attachment (on a certain interface), it issues two simultaneous 884 registration requests, one to the i-HA and another to the x-HA. These 885 registration requests are periodically retransmitted if reply 886 messages are not received. 888 Registration replies are processed as follows: 890 o If a response from the x-HA is received, the MN stops 891 retransmitting its registration request to the x-HA and determines 892 it is outside. However, the MN MUST keep on retransmitting its 893 registration to the i-HA for a period of time. The MN MAY 894 postpone the IPsec connection setup for some period of time 895 ("detection period") while it waits for a response from the i-HA. 897 o If a response from the i-HA is received, the MN MUST determine 898 that it is inside. If a previous registration reply from the x-HA 899 has been received, the MN SHOULD de-register with the x-HA. In 900 any case, the MN MUST stop retransmitting its registration 901 requests to both i-HA and x-HA. 903 o If a response from the x-HA is received while the MN has 904 successfully registered with the i-HA, the MN SHOULD de-register 905 with the x-HA. 907 If the MN ends up detecting that it is inside, it MUST re-register 908 periodically (regardless of binding lifetime). The re-registration 909 interval and related parameters (e.g. for retransmission) MUST be 910 configurable, as they are security related parameters (see Section 911 4.2.3). If the re-registration fails, the MN MUST stop sending and 912 receiving plaintext traffic, and MUST restart the detection 913 algorithm. 915 Plaintext re-registration messages are always addressed either to the 916 x-HA or the i-HA, not to both. This is because the MN knows, after 917 initial registration, whether it is inside or outside. (However, 918 when the mobile node is outside, it re-registers independently with 919 the x-HA using plaintext, and with the i-HA through the VPN tunnel.) 921 The "detection period" is OPTIONAL, and may be useful in avoiding 922 aborted IKE sessions due to timing of i-HA and x-HA registration 923 reply messages. Aborted IKE sessions may be a problem in some cases 924 because IKE does not provide a reliable, standardized, and 925 mandatory-to-implement mechanism for terminating a session cleanly. 927 If the x-HA is not reachable from inside (i.e. the firewall 928 configuration is known), a detection period of zero is preferred, as 929 it minimizes connection setup overhead and causes no timing problems. 930 Should the assumption have been invalid and a response from the i-HA 931 received after a response from the x-HA, the MN SHOULD re-register 932 with the i-HA directly. 934 Note that it is possible that an i-HA is initially unreachable for 935 some time, but later becomes reachable (consider e.g. a routing 936 problem in the internal network). To eventually detect the i-HA, the 937 MN MAY send periodic registration attempts to the i-HA even after 938 determining initially that it is outside. The period of such 939 re-registration attempts should be in the order of minutes (e.g. 10 940 minutes), and configurable. 942 4.4 Implementation issues 944 When the MN uses a parallel detection algorithm and is using an FA, 945 the MN sends two registration requests through the same FA with the 946 same MAC address (or equivalent) and possibly even the same home 947 address. Although this is not in conflict with existing 948 specifications, it is not a usual scenario; hence some FA 949 implementations may not work properly in such a situation. However, 950 practical testing against deployed foreign agents seems to indicate 951 that a majority of foreign agents handle this situation. 953 When the x-HA and i-HA addresses are the same, the scenario is even 954 more difficult for the FA, and it is almost certain that existing FAs 955 do not deal with the situation correctly. Therefore, it is required 956 that x-HA and i-HA addresses MUST be different. This requirement is 957 automatically satisfied if the x-HA has a public address. 959 The mobile node MAY use the following hints to determine that it is 960 inside, but MUST verify reachability of the i-HA anyway: 962 o a domain name in a DHCPDISCOVER / DHCPOFFER message; 964 o a NAI in a foreign agent advertisement; 966 o a list of default gateway MAC addresses which are known to reside 967 in the internal network (i.e. configured as such, or have been 968 previously verified to be inside). 970 For instance, if the MN has reason to believe it is inside, it MAY 971 postpone sending of registration request to the x-HA for some time. 972 Similarly, if the MN has a reason to believe it is outside, it may 973 start IPsec connection setup immediately after receiving a 974 registration reply from the x-HA. However, should the MN receive a 975 registration reply from the i-HA after IPsec connection setup has 976 been started, the MN SHOULD still switch to using the i-HA directly. 978 4.5 Rationale 979 4.5.1 Firewall configuration requirements 981 The assumption that the i-HA cannot be reached from the external 982 network is, in practice, unavoidable. Suppose the assumption is not 983 made, i.e. the i-HA is reachable from some external networks. As a 984 result, a successful registration with the i-HA (without IPsec) 985 cannot be used as a secure indication that the mobile node is inside. 986 A possible solution to the obvious security problem would be to 987 define and deploy a secure internal network detection mechanism based 988 on e.g. signed FA advertisement or signed DHCP messages. 990 However, unless the mechanism is defined for both FA and DHCP 991 messages and is deployed in every internal network, it has limited 992 applicability. In other words, the mobile node MUST NOT assume it is 993 in the internal network unless it receives a signed FA or DHCP 994 message (regardless of whether it can register directly with the i-HA 995 or not!). If it receives an unsigned FA or DHCP message, it MUST use 996 IPsec; otherwise the mobile node can be easily tricked into using 997 plaintext. 999 Assuming that all FA and DHCP servers in the internal network are 1000 upgraded to support such a feature does not seem realistic; it is 1001 highly desirable to be able to take advantage of existing DHCP and FA 1002 deployments. Similar analysis seems to apply regardless of what kind 1003 of additional security mechanism is defined. 1005 4.5.2 Registration-based internal network monitoring 1007 This issue also affects IPsec client security. However, as IPsec 1008 specifications take no stand on how and when the client applies 1009 IPsec, the issue is out of scope for IPsec. Because this document 1010 describes an algorithm and requirements for (secure) internal network 1011 detection, the issue is in scope of the document. 1013 The current requirement for internal network monitoring was added as 1014 a fallback mechanism. It seems to be the best what can be done with 1015 only layer three mechanisms. 1017 4.5.3 No encryption when inside 1019 If encryption was applied also when MN was inside, there would be no 1020 security reason to monitor the internal network periodically. Why, 1021 then, not simply mandate encryption in the internal network as well? 1023 Some rationale for why encryption cannot be applied when the MN is 1024 inside was given in Section 1.6. In short, the main issues are (1) 1025 power consumption; (2) extra CPU load, especially because internal 1026 networks are typically switched networks and a lot of data may be 1027 routinely transferred; (3) existing HA devices do not typically 1028 integrate IPsec functionality; (4) (IPsec) encryption requires user 1029 authentication, which may be interactive in some cases (e.g. SecurID) 1030 and thus a usability issue; and (5) user may need to have separate 1031 credentials for VPN devices in the DMZ and the HA. 1033 4.6 Improvements 1035 The registration process can be improved in many ways. One simple way 1036 is to make the x-HA detect whether a registration request came from 1037 inside or outside. If it came from inside, the x-HA can simply drop 1038 the registration request, thus effectively "firewalling" the request. 1040 This approach is feasible without protocol changes in scenarios where 1041 a corporation owns both the VPN and the x-HA. The x-HA can simply 1042 determine based on incoming interface identifier (or the router which 1043 relayed the packet) whether the registration request came from inside 1044 or not. 1046 In other scenarios protocol changes may be needed. Such changes are 1047 out of scope of this document. 1049 5. Requirements 1051 5.1 Mobile node requirements 1053 The mobile node MUST implement an internal network detection 1054 algorithm fulfilling the requirements set forth in Section 4.2. 1056 The mobile node MUST support access modes: c, f, cvc, fvc (Section 1057 3). 1059 The mobile node SHOULD support Mobile IPv4 NAT traversal [6] for both 1060 internal and external Mobile IP. 1062 The mobile node SHOULD support IPsec NAT traversal [8][9]. 1064 When the mobile node has direct access to the i-HA, it SHOULD use 1065 only the inner Mobile IPv4 layer to minimize firewall and VPN impact. 1067 5.2 VPN device requirements 1069 The VPN security policy MUST allow communication using UDP to the 1070 internal home agent(s), with home agent port 434 and any remote port. 1071 The security policy SHOULD allow IP-IP to internal home agent(s) in 1072 addition to UDP port 434. 1074 The VPN device SHOULD implement the IPsec NAT traversal mechanism 1075 described in [8][9]. 1077 5.3 Home agent requirements 1079 The home agent SHOULD implement the Mobile IPv4 NAT traversal 1080 mechanism described in [6]. (This also refers to the i-HA: NAT 1081 traversal is required to support VPNs that NAT VPN tunnel addresses 1082 or block IP-IP traffic.) 1084 6. Analysis 1086 This section provides a comparison against guidelines described in 1087 Section 6 of the problem statement [1] and additional analysis of 1088 packet overhead with and without the optional mechanisms. 1090 6.1 Comparison against guidelines 1092 Preservation of existing VPN infrastructure 1094 o The proposed solution does not mandate any changes to existing VPN 1095 infrastructure, other than possibly changes in configuration to 1096 avoid stateful filtering of traffic. 1098 Software upgrades to existing VPN clients and gateways 1100 o The solution described does not require any changes to VPN 1101 gateways or Mobile IPv4 home agents or foreign agents. 1103 IPsec protocol 1105 o Proposed solution does not require any changes to existing IPsec 1106 or key exchange standard protocols, and does not require 1107 implementation of new protocols in the VPN device. 1109 Multi-vendor interoperability 1111 o The proposed solution provides easy multi-vendor interoperability 1112 between server components (VPN device, foreign agents and home 1113 agents). Indeed, these components need not be aware of each 1114 other. 1116 o The mobile node networking stack is somewhat complex to implement, 1117 which may be an issue for multi-vendor interoperability. 1119 MIPv4 protocol 1121 o The solution adheres to the MIPv4 protocol. 1123 o The solution requires the use of two parallel MIPv4 layers. 1125 Handoff overhead 1127 o The solution provides a mechanism to avoid VPN tunnel SA 1128 renegotiation upon movement by using the external MIPv4 layer. 1130 Scalability, availability, reliability, and performance 1131 o The solution complexity is linear with the number of MNs 1132 registered and accessing resources inside the intranet. 1134 o Additional overhead is imposed by the solution. 1136 Functional entities 1138 o The solution does not impose any new types of functional entities 1139 or required changes to existing entities. However, an external HA 1140 device is required. 1142 Implications of intervening NAT gateways 1144 o The solution leverages existing MIPv4 NAT traversal [6] and IPsec 1145 NAT traversal [8][9] solutions and does not require any new 1146 functionality to deal with NATs. 1148 Security implications 1150 o The solution requires a new mechanism to detect whether the mobile 1151 node is in the internal or the external network. The security of 1152 this mechanism is critical in ensuring that the security level 1153 provided by IPsec is not compromised by a faulty detection 1154 mechanism. 1156 o When the mobile node is outside, the external Mobile IPv4 layer 1157 may allow some traffic redirection attacks that plain IPsec does 1158 not allow. Other than that, IPsec security is unchanged. 1160 o More security considerations are described in Section 7. 1162 6.2 Packet overhead 1164 The maximum packet overhead depends on access mode as follows: 1166 o f: 0 octets 1168 o c: 20 octets 1170 o fvc: 77 octets 1172 o cvc: 97 octets 1174 The overhead consists of the following: 1176 o IP-IP for i-MIPv4: 20 octets 1177 o IPsec ESP: 57 octets total, consisting of: 20 (new IP header), 1178 4+4+8 = 16 (SPI, sequence number, cipher initialization vector), 1179 7+2 = 9 (padding, padding length field, next header field), 12 1180 (ESP authentication trailer) 1182 o IP-IP for x-MIPv4: 20 octets 1184 When IPsec is used, a variable amount of padding is present in each 1185 ESP packet. The figures were computed for a cipher with 64-bit block 1186 size, padding overhead of 9 octets (next header field, padding length 1187 field, and 7 octets of padding, see Section 2.4 of [10]), and ESP 1188 authentication field of 12 octets (HMAC-SHA1-96 or HMAC-MD5-96). 1189 Note that an IPsec implementation MAY pad with more than a minimum 1190 amount of octets. 1192 NAT traversal overhead is not included, and adds 8 octets when IPsec 1193 NAT traversal [8][9] is used and 12 octets when MIP NAT traversal [6] 1194 is used. For instance, when using access mode cvc, the maximum NAT 1195 traversal overhead is 12+8+12 = 32 octets. Thus, the worst case 1196 scenario (with the abovementioned ESP assumptions) is 129 octets for 1197 cvc. 1199 6.3 Latency considerations 1201 The following terms are used: 1203 i-RTT: round trip time to i-HA 1204 x-RTT: round trip time to x-HA 1205 i-TP: total processing time (MN & HA) for one i-HA round trip 1206 x-TP: total processing time (MN & HA) for one x-HA round trip 1207 DP-T: "detection period" when MN is outside 1208 VPN-T: VPN connection setup time 1209 DET-T: time to detect a change in network connection 1210 DHCP-T: time to obtain co-located care-of address using DHCP 1211 FA-T: time to obtain a foreign agent care-of address 1213 In the analysis below, packet loss is ignored. DHCP is used as an 1214 example; any method of obtaining a co-located care-of address is 1215 equivalent. Note that i-RTT and x-RTT always refer to the round trip 1216 time from the current location. Thus, i-RTT is typically "large" when 1217 the mobile node is outside, and "small" when inside. 1219 The basic network detection algorithm has no "memory"; thus 1220 connection setup latency is only dependent on the current access 1221 network, not whether the previous access network was outside or 1222 inside. 1224 When the mobile node is inside, connection setup latency is 1225 determined simply by the latency of registration with the i-HA, which 1226 is typically simply (i-RTT + i-TP). When a foreign agent is used to 1227 register a co-located care-of address, and a NAT is detected, the 1228 latency is 2*(i-RTT + i-TP) (see [6] Section 4.11). The "detection 1229 period" does not affect latency because the mobile node SHOULD use 1230 the i-HA directly if the i-HA replies. 1232 When the mobile node is outside, connection setup latency is 1233 typically (x-RTT + x-TP + DP-T + VPN-T + i-RTT + i-TP), where VPN-T 1234 is omitted if an IPsec connection already exists. When a foreign 1235 agent is used to register a co-located care-of address to the x-HA, 1236 and a NAT is detected, the latency is (2*(x-RTT + x-TP) + DP-T + 1237 VPN-T + i-RTT + i-TP). Since each step of the connection setup builds 1238 on the previous one, the steps always proceed in strict sequence and 1239 no parallellism is possible. 1241 The total latency from change in network connection to bi-directional 1242 packet flow is the sum of DET-T, min(DHCP-T, FA-T), and the 1243 connection setup time. For instance, when outside, typically: (DET-T 1244 + min(DHCP-T, FA-T) + x-RTT + x-TP + DP-T + VPN-T + i-RTT + i-TP). 1246 Because the network detection uses parallel registration to x-HA and 1247 i-HA, there is no considerable latency impact from the parallel 1248 registration as such, except of course the small delay imposed on the 1249 second registration request because sending is sequential in reality. 1250 However, detection period (DP-T) increases total latency directly. 1252 The mobile node may improve latency when outside by two means: 1254 o sending the registration request most likely to succeed first, 1255 thus avoiding the small delay caused by sequential sending; and 1257 o using a detection period of zero. 1259 These two can be done based on heuristics about the network, e.g. 1260 addresses, MAC address of the default gateway (which the mobile node 1261 may remember from previous access), based on the previous access 1262 network (i.e. optimize for inside-inside and outside-outside 1263 movement), etc. 1265 6.4 Firewall state considerations 1267 A separate firewall device or an integrated firewall in the VPN 1268 gateway typically performs stateful inspection of user traffic. The 1269 firewall may, for instance, track TCP session status and block TCP 1270 segments not related to open connections. Other stateful inspection 1271 mechanisms also exist. 1273 Firewall state poses a problem when the mobile node moves between the 1274 internal and external networks. The mobile node may, for instance, 1275 initiate a TCP connection while inside, and later go outside while 1276 expecting to keep the connection alive. From the point of view of 1277 the firewall, the TCP connection has not been initiated, as it has 1278 not witnessed the TCP connection setup packets, thus potentially 1279 resulting in connectivity problems. 1281 When the VPN-TIA is registered as a co-located care-of address with 1282 the i-HA, all mobile node traffic appears as IP-IP for the firewall. 1283 Typically firewalls don't continue inspection beyond the IP-IP 1284 tunnel, but it is not inconceivable that some firewalls may do that. 1286 In summary, the firewall must allow traffic coming from and going 1287 into the IPsec connection to be routed, even though they may not have 1288 successfully tracked the connection state. How this is done is out 1289 of scope of this document. 1291 6.5 Intrusion detection systems (IDSs) 1293 Many firewalls incorporate intrusion detection systems, which monitor 1294 traffic for unusual patterns and clear signs of attack. Since traffic 1295 from a mobile node implementing this specification is UDP to i-HA 1296 port 434, and possibly IP-IP traffic to the i-HA address, existing 1297 IDSs may treat the traffic differently than ordinary VPN remote 1298 access traffic. Like firewalls, IDSs are not standardized, so it is 1299 impossible to guarantee interoperability with any particular IDS 1300 system. 1302 6.6 Implementation of mobile node 1304 Implementation of the mobile node requires the use of three tunneling 1305 layers, which may be used in various configurations depending on 1306 whether that particular interface is inside or outside. Note that it 1307 is possible that one interface is inside and another interface is 1308 outside, which requires a different layering for each interface at 1309 the same time. 1311 For multi-vendor implementation, the IPsec and Mobile IPv4 layers 1312 need to interoperate in the same mobile node. This implies that a 1313 flexible framework for protocol layering (or protocol-specific APIs) 1314 are required. 1316 6.7 Non-IPsec VPN protocols 1318 The proposed solution works also for VPN tunneling protocols that are 1319 not IPsec-based, provided that the mobile node is provided IPv4 1320 connectivity with an address suitable for registration. However, such 1321 VPN protocols are not explicitly considered. 1323 6.8 Shortcomings for enterprise use 1325 The proposed solution has the following shortcomings for enterprise 1326 use: 1328 o Networks which provide only HTTP access (sometimes found in 1329 corporate networks) cannot be used for remote access. 1331 o Fragments are filtered by some routers. MIP NAT traversal [6] 1332 solves some, but not all, fragment related issues. 1334 However, these are not part of the problem statement. 1336 7. Security considerations 1338 7.1 Internal network detection 1340 If the mobile node mistakenly believes it is in the internal network 1341 and sends plaintext packets, it compromises IPsec security. For this 1342 reason, the overall security (confidentiality and integrity) of user 1343 data is a minimum of (1) IPsec security, and (2) security of the 1344 internal network detection mechanism. 1346 Security of the internal network detection relies on a successful 1347 registration with the i-HA. For standard Mobile IPv4 [5] this means 1348 HMAC-MD5 and Mobile IPv4 replay protection. 1350 When the connection status of an interface changes, an interface 1351 previously connected to the trusted internal network may suddenly be 1352 connected to an untrusted network. Although the same problem is also 1353 relevant to IPsec-based VPN implementations, the problem is 1354 especially relevant in the scope of this specification. 1356 In most cases, mobile node implementations are expected to have layer 1357 two information available, making connection change detection both 1358 fast and robust. To cover cases where such information is not 1359 available (or fails for some reason), the mobile node is required to 1360 periodically re-register with the internal home agent to verify that 1361 it is still connected to the trusted network. It is also required 1362 that this re-registration interval be configurable, thus giving the 1363 administrator a parameter by which potential exposure may be 1364 controlled robustly even for the worst case. 1366 7.2 Mobile IPv4 versus IPsec 1368 MIPv4 and IPsec have different goals and approaches for providing 1369 security services. MIPv4 typically uses a shared secret for 1370 authentication of (only) signaling traffic, while IPsec typically 1371 uses IKE (an authenticated Diffie-Hellman exchange) to set up session 1372 keys. Thus, the overall security properties of a combined MIPv4 and 1373 IPsec system depend on both mechanisms. 1375 In a "dual HA" solution the external MIPv4 layer provides mobility 1376 for IPsec traffic. If the security of MIPv4 is broken in this 1377 context, traffic redirection attacks against the IPsec traffic are 1378 possible. However, such routing attacks do not affect other IPsec 1379 properties (confidentiality, integrity, replay protection, etc), 1380 because IPsec does not consider the network between two IPsec 1381 endpoints to be secure in any way. 1383 Because MIPv4 shared secrets are usually configured manually, they 1384 may be weak if easily memorizable secrets are chosen, thus opening up 1385 redirection attacks described above. Note that a weak secret in the 1386 i-HA is fatal to security, as the mobile node can be fooled into 1387 dropping encryption if the i-HA secret is broken. 1389 Assuming the MIPv4 shared secrets have sufficient entropy, there are 1390 still at least the following differences and similarities between 1391 MIPv4 and IPsec worth considering: 1393 o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" 1394 attack described in [16] and [6], assuming that NAT traversal is 1395 enabled (which is typically the case). 1397 o When considering a "pseudo NAT" attack against standard IPsec and 1398 standard MIP (with NAT traversal), redirection attacks against MIP 1399 may be easier because: 1401 * MIPv4 re-registrations typically occur more frequently than 1402 IPsec SA setups (although this may not be the case for mobile 1403 hosts). 1405 * It suffices to catch and modify a single registration request, 1406 whereas attacking IKE requires that multiple IKE packets are 1407 caught and modified. 1409 o There may be concerns about mixing of algorithms. For instance, 1410 IPsec may be using HMAC-SHA1-96, while MIP is always using 1411 HMAC-MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore, 1412 while IPsec algorithms are typically configurable, MIPv4 clients 1413 typically use only HMAC-MD5 or prefix+suffix MD5. Although this is 1414 probably not a security problem as such, it is more difficult to 1415 communicate to users. 1417 o When IPsec is used with a PKI, the key management properties are 1418 superior to those of basic MIPv4. Thus, adding MIPv4 to the system 1419 makes key management more complex. 1421 o In general, adding new security mechanisms increases overall 1422 complexity and makes the system more difficult to understand. 1424 8. Intellectual property rights 1426 Birdstep Technology has submitted patent application(s) related to 1427 the dual mobile IP design for VPN gateway traversal. Birdstep's 1428 objective is to seek intellectual property protection for its mobile 1429 IP client implementation of such a design. If any standards arising 1430 from this document are or become protected by one or more patents 1431 assigned to Birdstep Technology, and if any claims of any issued 1432 Birdstep patents are necessary for practicing such a standard, any 1433 party will be able to obtain a license from Birdstep to use any such 1434 patent claims under reasonable, non-discriminatory terms, with 1435 reciprocity, to implement and fully comply with the standard. 1437 Intel may or may not have patents or patent applications related to 1438 the non-mandatory mechanisms described in this document. 1440 9. Acknowledgements 1442 This document is a joint work of the contributing authors (in 1443 alphabetical order): 1445 - Farid Adrangi (Intel Corporation) 1446 - Nitsan Baider (Check Point Software Technologies, Inc.) 1447 - Gopal Dommety (Cisco Systems) 1448 - Eli Gelasco (Cisco Systems) 1449 - Dorothy Gellert (Nokia Corporation) 1450 - Espen Klovning (Birdstep) 1451 - Milind Kulkarni (Cisco Systems) 1452 - Henrik Levkowetz (ipUnplugged AB) 1453 - Frode Nielsen (Birdstep) 1454 - Sami Vaarala (Netseal) 1455 - Qiang Zhang (Liqwid Networks, Inc.) 1457 The authors would like to thank MIP/VPN design team, especially Mike 1458 Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent 1459 Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan 1460 O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans 1461 Sjostrand, and Serge Tessier for their continuous feedback and 1462 helping us improve this draft. Special thanks to Radia Perlman for 1463 giving the document a thorough read and a security review. Tom Hiller 1464 pointed out issues with battery powered devices. We would also like 1465 to thank the previous Mobile IP working group chairs (Gabriel 1466 Montenegro, Basavaraj Patil, and Phil Roberts) for important feedback 1467 and guidance. 1469 References 1471 [1] Adrangi, F., Kulkarni, M., Dommety, G., Gelasco, E., Zhang, Q., 1472 Vaarala, S., Gellert, D., Baider, N. and H. Levkowetz, "Problem 1473 Statement and Solution Guidelines for Mobile IPv4 Traversal 1474 Across IPsec-based VPN Gateways 1475 (draft-ietf-mobileip-vpn-problem-statement-guide-00e, work in 1476 progress)", January 2003. 1478 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1479 Levels", RFC 2119, March 1997. 1481 [3] Kent, S. and R. Atkinson, "Security Architecture for the 1482 Internet Protocol", RFC 2401, November 1998. 1484 [4] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 1485 2486, January 1999. 1487 [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 1488 2002. 1490 [6] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network 1491 Address Translation (NAT) Devices", RFC 3519, April 2003. 1493 [7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. 1494 Lear, "Address Allocation for Private Internets", RFC 1918, BCP 1495 5, February 1996. 1497 [8] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe, 1498 "Negotiation of NAT-Traversal in the IKE 1499 (draft-ietf-ipsec-nat-t-ike-05, work in progress)", January 1500 2003. 1502 [9] Huttunen, A., Swander, B., Stenberg, M., Volpe, V. and L. 1503 DiBurro, "UDP Encapsulation of IPsec packets 1504 (draft-ietf-ipsec-udp-encaps-06, work in progress)", January 1505 2003. 1507 [10] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1508 (ESP)", RFC 2406, November 1998. 1510 [11] Nuopponen, A. and S. Vaarala, "Mobile IPv4 coexistence with 1511 IPsec remote access tunnelling 1512 (draft-nuopponen-vaarala-mipvpn-00, work in progress)", July 1513 2002. 1515 [12] Adrangi, F., Iyer, P., Zhang, Q. and N. Baider, "Mobile IPv4 1516 Traversal Across IPsec-based VPN Gateways 1517 (draft-adrangi-mobileip-mipvpn-traversal, work in progress)", 1518 January 2003. 1520 [13] Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A., 1521 Zhang, Q. and J. Lau, "Mobile IPv4 Traversal Across IPsec-based 1522 VPN Gateways (draft-adrangi-mobileip-vpn-traversal-02)", July 1523 2002. 1525 [14] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage", 1526 December 2002. 1528 [15] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 1529 Protect Mobile IPv6 Signaling between Mobile Nodes and Home 1530 Agents (draft-ietf-mobileip-mipv6-ha-ipsec-01, work in 1531 progress)", October 2002. 1533 [16] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how 1534 NATs are even more evil than you believed 1535 (draft-dupont-transient-pseudonat-01, work in progress)", 1536 December 2002. 1538 Author's Address 1540 Sami Vaarala 1541 Netseal 1542 Niittykatu 6 1543 Espoo 02201 1544 FINLAND 1546 Phone: +358 9 435 310 1547 EMail: sami.vaarala@iki.fi 1549 Appendix A. Packet flow examples 1551 A.1 Connection setup for access mode 'cvc' 1553 The following figure illustrates connection setup when the mobile 1554 node is outside and using a co-located care-of address. IKE 1555 connection setup is not shown in full, and involves multiple round 1556 trips (4.5 round trips when using main mode followed by quick mode). 1558 MN-APP MN x-HA VPN i-HA CN 1559 ! ! ! ! ! ! 1560 ! ! -------> ! ! ! ! 1561 ! ! rrq ! ! ! ! 1562 ! ! -----------------------------X ! ! rrq not 1563 ! ! rrq ! ! ! ! received 1564 ! ! ! ! ! ! by i-HA 1565 ! ! <------- ! ! ! ! 1566 ! ! rrp ! ! ! ! 1567 ! ! ! ! ! ! 1568 ! [wait for detection period for response from i-HA] ! 1569 ! [may also retransmit to i-HA, depending on config] ! no rrp 1570 ! ! ! ! ! ! from i-HA 1571 ! ! ==(1)==> ! ! ! ! 1572 ! ! ike {1a}! -------> ! ! ! 1573 ! ! ! ike ! ! ! 1574 ! ! ! <------- ! ! ! 1575 ! ! <==(1)== ! ike ! ! ! 1576 ! ! ike ! ! ! ! 1577 : : : : : : 1578 : : : : : : 1579 ! ! ! ! ! ! 1580 ! ! ==(2)==> ! ! ! ! 1581 ! ! rrq {2a}! ==(1)==> ! ! ! 1582 ! ! ! rrq {2b}! -------> ! ! 1583 ! ! ! ! rrq {2c}! ! 1584 ! ! ! ! <------- ! ! 1585 ! ! ! <==(1)== ! rrp ! ! 1586 ! ! <==(2)== ! rrp ! ! ! 1587 ! ! rrp ! ! ! ! 1588 ! ! ! ! ! ! 1589 [[--- connection setup ok, bidirectional connection up ---]] 1590 ! ! ! ! ! ! 1591 ! -------> ! ! ! ! ! 1592 ! pkt {3a}! ==(3)==> ! ! ! ! 1593 ! ! pkt {3b}! ==(2)==> ! ! ! 1594 ! ! ! pkt {3c}! ==(1)==> ! ! 1595 ! ! ! ! pkt {3d}! -------> ! 1596 ! ! ! ! ! pkt {3e}! 1597 ! ! ! ! ! <------- ! 1598 ! ! ! ! <==(1)== ! pkt ! 1599 ! ! ! <==(2)== ! pkt ! ! 1600 ! ! <==(3)== ! pkt ! ! ! 1601 ! <------ ! pkt ! ! ! ! 1602 ! pkt ! ! ! ! ! 1603 : : : : : : 1604 : : : : : : 1606 The notation "==(N)==>" or "<==(N)==" indicates that the innermost 1607 packet has been encapsulated N times, using IP-IP, ESP, or MIP NAT 1608 traversal. 1610 Packets marked with {xx} are shown in more detail below. Each area 1611 represents a protocol header (labeled). Source and destination 1612 addresses or ports are shown underneath the protocol name when 1613 applicable. Note that there are no NAT traversal headers in the 1614 example packets. 1616 Packet {1a} 1617 .------------------------------------. 1618 ! IP ! IP ! UDP ! IKE ! 1619 ! co-CoA ! x-HoA ! 500 ! ! 1620 ! x-HA ! VPN-GW ! 500 ! ! 1621 `------------------------------------' 1623 Packet {2a} 1624 .--------------------------------------------------------. 1625 ! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ ! 1626 ! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! ! 1627 ! x-HA ! VPN-GW ! ! i-HA ! 434 ! ! 1628 `--------------------------------------------------------' 1630 Packet {2b} 1631 .----------------------------------------------. 1632 ! IP ! ESP ! IP ! UDP ! MIP RRQ ! 1633 ! x-HoA ! ! VPN-TIA ! ANY ! ! 1634 ! VPN-GW ! ! i-HA ! 434 ! ! 1635 `----------------------------------------------' 1637 Packet {2c} 1638 .----------------------------. 1639 ! IP ! UDP ! MIP RRQ ! 1640 ! VPN-TIA ! ANY ! ! 1641 ! i-HA ! 434 ! ! 1642 `----------------------------' 1644 Packet {3a} 1645 .-------------------. 1646 ! IP ! user ! 1647 ! i-HoA ! protocol ! 1648 ! CN ! ! 1649 `-------------------' 1651 Packet {3b} 1652 .------------------------------------------------------- - 1653 ! IP ! IP ! ESP ! IP ! IP ! user \ 1654 ! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../ 1655 ! x-HA ! VPN-GW ! ! i-HA ! CN ! \ 1656 `------------------------------------------------------- - 1657 - - -----------------. 1658 \..user ! ESP ! 1659 / protocol ! trailer ! 1660 \ ! ! 1661 - - -----------------' 1663 Packet {3c} 1664 .--------------------------------------------------------. 1665 ! IP ! ESP ! IP ! IP ! user ! ESP ! 1666 ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer ! 1667 ! VPN-GW ! ! i-HA ! CN ! ! ! 1668 `--------------------------------------------------------' 1670 Packet {3d} 1671 .------------------------------. 1672 ! IP ! IP ! user ! 1673 ! VPN-TIA ! i-HoA ! protocol ! 1674 ! i-HA ! CN ! ! 1675 `------------------------------' 1677 Packet {3e} 1678 .-------------------. 1679 ! IP ! user ! 1680 ! i-HoA ! protocol ! 1681 ! CN ! ! 1682 `-------------------' 1684 Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is 1685 shown below for comparison. 1687 Packet {3b} (with NAT traversal headers) 1688 .------------------------------------------------- - 1689 ! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \ 1690 ! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! / 1691 ! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \ 1692 `------------------------------------------------- - 1693 <=== external MIPv4 ====> <=== IPsec ESP ======== = = 1695 - - ------------------------------------------------ - 1696 \..ESP ! IP ! UDP ! MIP ! IP ! user \ 1697 / ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../ 1698 \ ! i-HA ! 434 ! data ! CN ! \ 1699 - - ------------------------------------------------ - 1700 = ===> <==== internal MIPv4 ====> <== user packet == = 1702 - - -----------------. 1703 \..user ! ESP ! 1704 / protocol ! trailer ! 1705 \ ! ! 1706 - - -----------------' 1707 = = ======> <= ESP => 1709 The following diagram illustrates what happens when the i-HA response 1710 is delayed beyond detection period (and is received while IKE is 1711 on-going). 1713 MN-APP MN x-HA VPN i-HA CN 1714 ! ! -------> ! ! ! ! 1715 ! ! rrq ! ! ! ! 1716 ! ! -----------------------------X ! ! rrq not 1717 ! ! rrq ! ! ! ! received 1718 ! ! ! ! ! ! by i-HA 1719 ! ! <------- ! ! ! ! 1720 ! ! rrp ! ! ! ! 1721 ! ! ! ! ! ! 1722 ! [wait for detection period for response from i-HA] ! 1723 ! [retranmissions to i-HA] ! ! no rrp 1724 ! ! ! ! ! ! from i-HA 1725 ! ! ==(1)==> ! ! ! ! 1726 ! ! ike {1a}! -------> ! ! ! 1727 ! ! ! ike ! ! ! 1728 ! ! ! <------- ! ! ! 1729 ! ! <==(1)== ! ike ! ! ! 1730 ! ! ! ! ! ! 1731 : : : : : : 1732 ! ! <----------------------------- ! ! late rrp 1733 ! ! rrp ! ! ! ! 1734 ! ! ! ! ! ! 1735 ! [bidirectional connection with i-HA up] ! ! 1736 ! [abort ike, de-register with x-ha] ! ! 1737 ! ! ! ! ! ! 1738 ! ! ! <------- ! ! ! 1739 ! ! <==(1)== ! ike ! [ike packets may] 1740 ! ! ike ! ! [arrive for some time] 1741 ! [drop] ! ! ! ! 1742 ! ! ! [peer not responding] ! 1743 ! ! ! [retransmit for some time] ! 1744 ! ! ! ! ! ! 1745 ! ! -------> ! ! ! ! 1746 ! ! rrq ! ! ! ! 1747 ! ! (dereg) ! ! ! ! 1748 ! ! ! ! ! ! 1749 ! ! <------- ! ! [after de-reg, x-HA] 1750 ! ! rrp ! <------- ! [drops ike packets] 1751 ! ! ! ike ! ! ! 1752 ! ! [drop] ! ! ! 1753 ! ! ! ! ! ! 1754 ! ! ==(1)========================> ! ! 1755 ! ! pkt ! ! ! -------> ! 1756 ! ! ! ! ! pkt ! 1757 ! ! ! ! ! ! 1758 ! ! ! ! ! <------- ! 1759 ! ! <==(1)======================== ! pkt ! 1760 ! ! pkt ! ! ! ! 1761 : : : : : : 1762 : : : : : : 1764 In the diagram above, the IKE session in the VPN device eventually 1765 times out. Some IKE implementations support aborting a session 1766 (ISAKMP exchange) in some way; if so, the IKE state is dropped 1767 cleanly. 1769 Note that it is possible to receive the registration reply from the 1770 i-HA after a registration request has been sent to the i-HA through 1771 the VPN tunnel (or indeed, even after a reply for the latter 1772 registration has been received). This case is dealt with by ordinary 1773 Mobile IPv4 means. 1775 A.2 Connection setup for access mode 'fvc' 1777 The diagram below illustrates connection setup in access mode fvc. 1779 MN-APP MN x-FA x-HA VPN i-HA CN 1780 ! ! ! ! ! ! ! 1781 ! ! -------> ! ! ! ! ! 1782 ! ! rrq ! -------> ! ! ! ! 1783 ! ! ! rrq ! ! ! ! 1784 ! ! ! ! ! ! ! 1785 ! ! -------> ! ! ! ! ! 1786 ! ! rrq ! -----------------------------X ! ! 1787 ! ! ! rrq ! ! ! ! 1788 ! ! ! ! ! ! ! 1789 ! ! ! <------- ! ! ! ! 1790 ! ! <------- ! rrp ! ! ! ! 1791 ! ! rrp ! ! ! ! ! 1792 ! ! ! ! ! ! ! 1793 ! [wait for detection period for response from i-HA] ! 1794 ! [may also retransmit to i-HA, depending on config] ! 1795 ! ! ! ! ! ! ! 1796 ! ! -------> ! ! ! ! ! 1797 ! ! ike ! ==(1)==> ! ! ! ! 1798 ! ! ! ike ! -------> ! ! ! 1799 ! ! ! ! ike ! ! ! 1800 ! ! ! ! <------- ! ! ! 1801 ! ! ! <==(1)== ! ike ! ! ! 1802 ! ! <------- ! ike ! ! ! ! 1803 ! ! ike ! ! ! ! ! 1804 : : : : : : : 1805 : : : : : : : 1806 ! ! ! ! ! ! ! 1807 ! ! ! ! ! ! ! 1808 ! ! ==(1)==> ! ! ! ! ! 1809 ! ! rrq ! ==(2)==> ! ! ! ! 1810 ! ! ! rrq ! ==(1)==> ! ! ! 1811 ! ! ! ! rrq ! -------> ! ! 1812 ! ! ! ! ! rrq ! ! 1813 ! ! ! ! ! <------- ! ! 1814 ! ! ! ! <==(1)== ! rrp ! ! 1815 ! ! ! <==(2)== ! rrp ! ! ! 1816 ! ! <==(1)== ! rrp ! ! ! ! 1817 ! ! rrp ! ! ! ! ! 1818 ! ! ! ! ! ! ! 1819 ! [[--- connection setup ok, bidirectional connection up ---]] ! 1820 ! ! ! ! ! ! ! 1821 ! -------> ! ! ! ! ! ! 1822 ! pkt ! ==(2)==> ! ! ! ! ! 1823 ! ! pkt ! ==(3)==> ! ! ! ! 1824 ! ! ! pkt ! ==(2)==> ! ! ! 1825 ! ! ! ! pkt ! ==(1)==> ! ! 1826 ! ! ! ! ! pkt ! -------> ! 1827 ! ! ! ! ! ! pkt ! 1828 ! ! ! ! ! ! <------- ! 1829 ! ! ! ! ! <==(1)== ! pkt ! 1830 ! ! ! ! <==(2)== ! pkt ! ! 1831 ! ! ! <==(3)== ! pkt ! ! ! 1832 ! ! <==(2)== ! pkt ! ! ! ! 1833 ! <------- ! pkt ! ! ! ! ! 1834 ! pkt ! ! ! ! ! ! 1835 : : : : : : : 1836 : : : : : : : 1838 Appendix B. Changes 1840 Changes from -02 to -03: 1842 o Remaining issues from security review worked into document. 1844 o Short rationale for why (a) IPsec is not mobile, and (b) the 1845 essential problem statement assumptions added. 1847 o Minor wording changes (IETF 57 comments). 1849 o Internal network monitoring section revised with "relaxed 1850 re-registration" approach to improve applicability to battery 1851 powered devices. 1853 o IPR section needs to refer to on-line rights (and current text 1854 moved on-line). Not done yet. 1856 Changes from -01 to -02: 1858 o Packet flow examples added. 1860 o Explicit IDS reference added. 1862 o Requirement levels adjusted; NAT traversal requirements changed 1863 from MUST to SHOULD and other changes. 1865 o MN no longer required to use i-HA directly whenever available (in 1866 some cases that may not be desired). 1868 o IPR section revised. 1870 o Latency considerations section added. 1872 o External HA reachability assumption refined; if firewall properly 1873 configured, handover performance can be improved. This is now 1874 mentioned in the detection section. 1876 o Overhead section simplified, only base solution discussed. 1878 o Proposed solutions section removed from appendix. 1880 o Strawmen of optimizations removed from appendix, references to 1881 optimizations removed from text. 1883 Changes from -00 to -01: 1885 o First description of proposed solution based on basic and 1886 optimized dual HA drafts, as well as IPsec endpoint update 1887 mechanism. 1889 o List of proposed solutions in -00 included in appendix. 1891 Intellectual Property Statement 1893 The IETF takes no position regarding the validity or scope of any 1894 intellectual property or other rights that might be claimed to 1895 pertain to the implementation or use of the technology described in 1896 this document or the extent to which any license under such rights 1897 might or might not be available; neither does it represent that it 1898 has made any effort to identify any such rights. Information on the 1899 IETF's procedures with respect to rights in standards-track and 1900 standards-related documentation can be found in BCP-11. Copies of 1901 claims of rights made available for publication and any assurances of 1902 licenses to be made available, or the result of an attempt made to 1903 obtain a general license or permission for the use of such 1904 proprietary rights by implementors or users of this specification can 1905 be obtained from the IETF Secretariat. 1907 The IETF invites any interested party to bring to its attention any 1908 copyrights, patents or patent applications, or other proprietary 1909 rights which may cover technology that may be required to practice 1910 this standard. Please address the information to the IETF Executive 1911 Director. 1913 Full Copyright Statement 1915 Copyright (C) The Internet Society (2003). All Rights Reserved. 1917 This document and translations of it may be copied and furnished to 1918 others, and derivative works that comment on or otherwise explain it 1919 or assist in its implementation may be prepared, copied, published 1920 and distributed, in whole or in part, without restriction of any 1921 kind, provided that the above copyright notice and this paragraph are 1922 included on all such copies and derivative works. However, this 1923 document itself may not be modified in any way, such as by removing 1924 the copyright notice or references to the Internet Society or other 1925 Internet organizations, except as needed for the purpose of 1926 developing Internet standards in which case the procedures for 1927 copyrights defined in the Internet Standards process must be 1928 followed, or as required to translate it into languages other than 1929 English. 1931 The limited permissions granted above are perpetual and will not be 1932 revoked by the Internet Society or its successors or assignees. 1934 This document and the information contained herein is provided on an 1935 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1936 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1937 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1938 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1939 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1941 Acknowledgment 1943 Funding for the RFC Editor function is currently provided by the 1944 Internet Society.