idnits 2.17.00 (12 Aug 2021) /tmp/idnits53956/draft-adrangi-mipv4-midbox-traversal-00.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: ---------------------------------------------------------------------------- == There are 66 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 29) being 72 lines == It seems as if not all pages are separated by form feeds - found 2 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: - The NATÆed network MUST provide DHCP service to the foreign subnet or a mobile node MUST be capable of self-assigning or acquiring by other means, a non-routable care-of address when it roams behind the NAT. - The NATÆed network MAY NOT include a foreign agent. - The NATÆed network MAY NOT be in the same administrative domain as the MN, MIP Proxy and HA. - The NATÆed network MUST be configured with the IP addresses reserved for private Internets by IANA ([RFC1918], [LOCAL-LINK]). - If the NATÆed network is multi-subnetted, the routers within that network cannot be compromised. - The HA SHOULD NOT be modified. - MNÆs home network MUST be in a routable IP address domain. This address domain MAY be behind a firewall/DMZ. - A FA MAY NOT be available in the ISP access or core network. - Security implications should not be worse than direct comm. With HA. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The MIP Proxy maintains a registration binding cache similar to the one specified by [RFC2002] for a HA, in order to forward the registration replies and subsequent MIPv4 data traffic. In addition, the MIP Proxy MUST also record the UDP port number (learned form the parameter registration extension) for the UDP tunnel between the MN and the MIP Proxy in the registration binding cache. The MIP Proxy MUST not manage registration lifetimes and MUST NOT reinitiate a registration request with a HA prior to its expiration. A MN MUST continue to manage Registration lifetimes as specified in [RFC2002]. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The solution is derived based on the following assumptions and applicability criteria: - End-to-end IPsec tunnel mode MUST be applied to MIPv4 data flows; i.e. between the MN and the VPN gateway at the edge of its home network. - MIPv4 registration packets MAY NOT require IPsec tunnel as they are authenticated and integrity protected. However, they MUST be terminated inside the DMZ to enable authenticated firewall traversal. - FA-assisted routing and MN co-located modes of operation MUST be supported. - The MN MUST be configured with the MIP Proxy and the VPN gatewayÆs external IP addresses, and route the MIPv4 traffic through the MIP Proxy when it is outside the corporate intranet. - The MN SHOULD be able to determine if it has roamed outside the corporate network by some method (e.g., by comparing its current COA against address blocks used by the corporate intranet). - The MN MUST be able to determine when it should exercise its key exchange protocol to establish the IPsec tunnel SA to the VPN gateway. -- 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 (July 2001) is 7615 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: 'LOCAL-LINK' is mentioned on line 382, but not defined ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 1701 -- Possible downref: Normative reference to a draft: ref. 'MIPv4-SEC-GUIDE' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROUTE-OPT' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Farid Adrangi 3 INTERNET DRAFT Prakash Iyer 4 Intel Corp. 5 Date: July 2001 6 Expires: January 2002 8 Mobile IPv4 Traversal Across NAT and VPN Gateways 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please 33 check the "1id-abstracts.txt" listing contained in the 34 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 35 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 36 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 37 Coast), or ftp.isi.edu (US West Coast). 39 Abstract 41 Wireless LANs or hot spots are starting to be widely deployed 42 in Enterprise Intranets and public areas such as airports, 43 coffee shops, shopping malls etc. based on IPv4. This combined 44 with the availability of multi-mode networked devices and 45 applications that can take advantage of continuous mobility and 46 constant reachability, is driving the need for Mobile IP in 47 these networks. At the same time, middleboxes (NAT and VPN 48 gateways for example) are also seeing widespread usage. Mobile 49 IPv4 has known functional and performance limitations in the 50 presence of these middleboxes. This draft proposes a solution 51 framework that enables seamless operation of Mobile IPv4 across 52 middleboxes without requiring any changes to the middleboxes 53 themselves. Although the solution is generically extensible, 55 Expires January 2002 56 the draft specifically focuses on NAT and VPN traversal. The 57 solution has no link layer dependencies and can be applied to 58 other 802.3-compatible physical media as well. 60 Table Of Contents 62 1. Introduction....................................................3 63 2. Terminology.....................................................4 64 3. Acronyms........................................................4 65 4. The MIP Proxy...................................................4 66 4.1. Surrogate MN Functionality....................................5 67 4.2. Surrogate HA Functionality....................................5 68 4.3. Deploying a MIP Proxy.........................................6 69 4.4. Discovering a MIP Proxy.......................................6 70 4.5. MIP Proxy Redundancy..........................................6 71 5. MIPv4 Traversal Through NAT Gateways............................6 72 5.1. NAT Traversal Problem Statement..............................6 73 5.2. Assumptions and Applicability.................................7 74 5.3. Using the MIP Proxy for NAT Traversal.......................8 75 5.3.1. When does a MN register with the MIP Proxy?................8 76 5.3.1.1. Selection of the COA Field in the Registration Request 77 Payload............................................................9 78 5.3.1.2. Discovery Registration Extension.........................10 79 5.3.2. MIPv4 registration protocol between MN and HA..............10 80 5.3.2.1. Establishing UDP Tunnel Parameters for MIPv4 Data Traffic11 81 5.3.2.2. Discovering the MNÆs actual home agent by the MIP Proxy..11 82 5.3.2.3. Parameter Registration Extension.........................12 83 5.3.2.4. MIPv4 Registration Request Packet Flow From MN to HA.....12 84 5.3.2.5. MIPv4 Registration Reply Packet Flow From HA to MN.......13 85 5.3.3. MIPv4 data traffic from MN to CN...........................14 86 5.3.4. MIPv4 data traffic from CN to MN...........................15 87 5.4. Summary of changes on MIPv4 components required by this 88 solution..........................................................16 89 5.4.1. Required Changes to a MN...................................16 90 5.4.2. Required Configuration for the MIP Proxy...................16 91 5.5. Performance Implications of MIP Proxy assisted NAT Traversal.16 92 5.6. Implications of Twice NAT between the MN and MIP Proxy.......16 93 6. MIPv4 Traversal Through IPsec VPN Gateways.....................16 94 6.1. IPsec VPN Traversal Problem Statement........................17 95 6.2. Integration of MIPv4 and IPsec...............................17 96 6.3. Assumptions and Applicability................................18 97 6.4. Solution Considerations......................................18 98 6.4.1. Fast Handoffs..............................................18 99 6.4.2. Preserve Existing VPN Infrastructure.......................18 100 6.4.3. Preserve Existing DMZ Traversal Policies...................19 101 6.5. Deploying the MIP Proxy to support VPN Traversal.............19 102 6.5.1. Mobile IPv4 Registration...................................19 103 6.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA.....19 104 6.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN.......20 105 6.5.1.3. DMZ Configuration Requirements for MIPv4 Registration 106 Packets...........................................................20 107 6.5.2. Mobile IPv4 Data Processing................................21 109 Adrangi, Iyer 110 Expires January 2002 111 6.5.2.1. MIPv4 Data Traffic from MN to CN.........................21 112 6.5.2.2. MIPv4 Data Traffic from CN to MN.........................23 113 6.5.3. Support For Route Optimization.............................24 114 6.6. Key Management and SA Preservation...........................24 115 6.7. DMZ and VPN Gateway Configuration Requirements...............25 116 6.8. Supporting Other IPsec-based VPN Configurations..............25 117 6.9. Considerations for Integrating the MIP Proxy and VPN Gateway.25 118 7. Using the MIP Proxy for combined NAT and VPN Traversal.........25 119 7.1. MIPv4 Registration Message Flow..............................26 120 7.1.1. MIPv4 Registration Requests................................26 121 7.1.2. MIPv4 Registration Replies.................................26 122 7.2. MIPv4 Data Flow..............................................27 123 7.2.1. Data Flow from the MN to the CN............................27 124 7.2.2. Data Flow from the CN to the MN............................28 125 8. Security Implications..........................................29 126 9. Acknowledgements...............................................29 127 10. Patents.......................................................29 128 11. References....................................................29 130 1. Introduction 132 The deployment of 802.3-based wired LANs and wireless LAN hot 133 spots and WAN packet data networks based on 2.5G and 3G 134 technologies and the availability of multi-mode networked 135 devices is driving new application scenarios that require 136 Mobile IPv4 support. These networks are also seeing widespread 137 use of NAT and VPN gateways. For example, many Enterprises are 138 deploying wireless LANs outside their corporate DeMilitarized 139 Zone (DMZ), requiring mobile nodes to "VPN" back into the 140 Intranet, from NATÆed subnets. Wireless WAN operators are 141 setting up to offer routable IPv4 addresses to corporate 142 clients for remote access back to their Enterprise networks, 143 while offering NAT-based access to their core network and the 144 Internet to consumers. NAT and firewall-enabled residential 145 networks are another example where mobile nodes could encounter 146 such middleboxes. Mobile IPv4 has known functional and 147 performance limitations, traversing these middleboxes. It is 148 often unacceptable to deploy workarounds that require any 149 software or hardware changes to these middleboxes or compromise 150 their functionality in any way. 152 The solution proposed in this draft introduces a logical 153 component called the MIP Proxy to enable seamless Mobile IPv4 154 functionality across such middleboxes, without requiring any 155 changes to these middleboxes. 157 The important sections of this draft are organized as follows: 158 Section 4 describes the MIP proxy. 159 Section 5 discusses seamless traversal through NAT gateways. 160 Section 6 discusses seamless traversal through VPN gateways. 161 These two solutions can be deployed independently or in 162 combination depending on specific network configurations, as 163 discussed in section 7. 165 2. Terminology 167 Administrative Domain: 168 A Mobile IP administrative domain specifies the Mobile IP 169 security parameters for one or more home agents and their 170 corresponding mobile nodes. The security parameters are used 171 for authentication or encryption to provide a secure channel 172 for the Mobile IP control and data traffic between the home 173 agent and mobile nodes. 175 Actual Home Agent: 176 It is the mobile nodeÆs real home agent, as defined by 177 [RFC2002]. 179 NAT-Router: 180 It is an IPv4 Router with NAT functionality. 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 183 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 184 "OPTIONAL" in this draft are to be interpreted as described in 185 [RFC2119]. 187 3. Acronyms 189 GRE: Generic Routing Encapsulation 190 ISP: Internet Service provider 191 MIPv4: Mobile IP for IPv4 192 MIPv6: Mobile IP for IPv6 193 NAT: Network Address Translator 195 MN-Perm: Permanent home address of the MN 196 MN-COA: Co-located care-of address of the MN 197 MIPP-Priv: MIP Proxy interface address on the private (HA) side 198 MIPP-Pub: MIP Proxy interface address on the public side 199 NATGW-Priv: NAT gatewayÆs IP address on the private (LAN) side 200 NATGW-Pub: NAT gatewayÆs IP address on the public (WAN) side 201 IP-D: IP Destination Address 202 IP-S: IP source Address 203 VPNGW-Pub: VPN Gateway Public/External IP Address 204 VPNGW-Priv: VPN Gateway Private/Intranet IP Address 206 4. The MIP Proxy 208 The MIP Proxy is a functional entity that is introduced in the 209 path between a MN and itÆs corresponding HA as depicted in the 210 figure below. The MIP Proxy serves two primary functions: that 211 of a surrogate MN and a surrogate HA to essentially "stitch" an 212 end-to-end connection between a MN and itÆs HA. A single MIP 213 Proxy can serve multiple MNs and HAs and can consequently be 214 associated with multiple home subnets. The MIP Proxy does not 215 replace any existing HAs. The MIP Proxy MUST belong to the same 216 administrative domain as any of its associated home agents. It 217 MUST share SAs for various MIPv4 registration extensions with 218 its associated HA(s). 220 +----+ 221 | MN |------ +----+ 222 +----+ | |--| HA | 223 . . . | | +----+ 224 +----+ | +----------+ | +----+ 225 | MN |------------| MIP Proxy|----------|--| HA | 226 +----+ | +----------+ | +----+ 227 . . . | | +----+ 228 +----+ | |--| HA | 229 | MN |----- +----+ 230 +----+ 232 Figure 4.0 : MIP Proxy serving multiple MNs and HAs 234 A MIP Proxy MAY support additional functionality in the context 235 of support for a specific type of middlebox. For NAT and VPN 236 gateways, additional functionality, if any, is described in 237 relevant sections of this draft. 239 The MIP Proxy will nominally run on a dual-homed host. It MAY 240 be possible to instantiate the MIP Proxy on a singly homed 241 host. 243 4.1. Surrogate MN Functionality 245 One of the primary functions of the MIP Proxy is to serve as a 246 MNÆs surrogate when it roams into a foreign network. 248 As a surrogate MN, the MIP Proxy MUST perform the following MN 249 compliant functions: 251 - It MUST perform registration request and reply protocol, 252 specified by [RFC2002] 253 - It MUST perform reverse tunneling, defined by [RFC3024] 254 - It MUST perform authentication mechanism(s) for the MN and 255 HA, required by [RFC2002] 256 - It MUST perform replay protection for registration request, 257 defined by [RFC2002] 259 The MIP Proxy MUST NOT perform the following MN functions: 261 - It MUST NOT perform agent solicitation, defined by [RFC2002] 262 - It MUST NOT perform any functions related to agent discovery, 263 defined by [RFC2002] 264 - It MUST NOT perform registration retransmission, defined by 265 [RFC2002] 266 - It MUST NOT perform move detection mechanisms, defined by 267 [RFC2002] 269 4.2. Surrogate HA Functionality 270 The other primary function of the MIP Proxy is to serve as a 271 surrogate HA to a roaming MN that is outside its home network, 272 and with an intervening middlebox such as a NAT or VPN gateway. 274 As a surrogate HA, the MIP Proxy MUST perform the following MN 275 compliant functions: 277 - It MUST perform registration request and reply protocol, 278 defined by [RFC2002] 279 - It MUST perform authentication mechanism(s) for the (MN & HA 280 and the HA & FA), required by [RFC2002] 281 - It MUST maintain registration binding table, defined by 282 [RFC2002] 283 - It MUST perform replay protection for registration request, 284 defined by [RFC2002] 286 The MIP Proxy MUST NOT perform the following MN functions: 288 - It MUST NOT perform agent advertisement, defined by [RFC2002] 289 - It MUST NOT perform gratuitous ARP, defined by [RFC2002] 290 - It MUST NOT perform Proxy ARP, defined by [RFC2002] 291 - It MUST NOT perform Route Optimization [ROUTE-OPT] 293 4.3. Deploying a MIP Proxy 295 A MIP Proxy MAY be deployed in a public network serving 296 multiple HAs in that network as conceptually depicted in the 297 figure above. It MUST be deployed in a DMZ to supported 298 authenticated firewall traversal for MIPv4 packets traversing 299 the DMZ from an MN with an intervening NAT gateway in itÆs 300 foreign network. It MUST be deployed in parallel with an IPsec- 301 compatible VPN gateway in a DMZ. Trivially, a subset of the MIP 302 Proxy functionality MAY be co-located with a HA if appropriate. 304 The MIP Proxy MAY be located in the same or a different subnet 305 from any of its associated home agents. 307 4.4. Discovering a MIP Proxy 309 A MN MUST be statically configured with the MIPP-Pub address of 310 the MIP Proxy. Dynamic discovery of the MIP ProxyÆs public IP 311 address is outside the scope of this draft. 313 4.5. MIP Proxy Redundancy 315 A MIP Proxy redundancy protocol is desirable to effect high 316 availability in public and Enterprise deployment. Details of 317 such a protocol are beyond the current scope of this draft. 319 5. MIPv4 Traversal Through NAT Gateways 321 5.1. NAT Traversal Problem Statement 322 When an MN roams from its home network (which may or may not be 323 in a routable IP address space) to a foreign network behind a 324 NAT gateway, it acquires a non-routable care-of address (most 325 likely through [DHCP]). The acquired non-routable care-of 326 address is passed to the HA through a registration request. 327 This causes the MN to lose its connectivity to its home 328 network, since the HA will not be able to forward the MNÆs 329 packets to the non-routable care-of address. The scenario is 330 depicted in Figure 5.1 below. 332 +-------------------+ +-------------------------+ 333 | Foreign network | | Home Network | 334 | +----+ | +-----+ | | 335 | | MN | |----| NAT |---| +----+ +----+ +---+ | 336 | +----+ | +-----+ | | MN | | HA | |CN | | 337 | | | +----+ +----+ +---+ | 338 +-------------------+ | | 339 | +---+ | 340 | | FA| | 341 | +---+ | 342 +-------------------------+ 344 Figure 5.1 : MN has moved from its home network to a 345 foreign network 347 Even if we overcome this problem somehow by using the NAT 348 gatewayÆs public routable address in the care-of address field 349 of the registration request, the NAT gateway will not always be 350 able to demultiplex inbound MIPv4 data traffic properly. 351 Consider two MNs behind the NAT gateway registered with the 352 same HA. The inbound IP-in-IP tunneled MIPv4 packets from the 353 HA to the two MNs will have the source and destination IP 354 address, making it difficult for the NAT gateway to route the 355 packets to the appropriate MN. 356 The implications on Minimal IP [RFC2004] and GRE encapsulation 357 [RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling. 359 5.2. Assumptions and Applicability 361 The solution proposed in the draft is targeted toward network 362 environments where the following are true. 363 - The NATÆed foreign network SHOULD NOT be modified. This 364 implies that no software or hardware changes to the NAT gateway 365 are feasible and adding a new routing entity (dedicated to 366 MIPv4 nodes) to such a network is unacceptable. Most 367 residential and small business networks are typical examples of 368 such NATÆed networks, wherein an embedded broadband router 369 (supporting local DHCP and NAT) is employed and additional 370 resources such as a routable IP address and/or a system are not 371 obtainable. 372 - The NAT gateway is capable of doing address and port mapping. 374 - The NATÆed network MUST provide DHCP service to the foreign 375 subnet or a mobile node MUST be capable of self-assigning or 376 acquiring by other means, a non-routable care-of address when 377 it roams behind the NAT. 378 - The NATÆed network MAY NOT include a foreign agent. 379 - The NATÆed network MAY NOT be in the same administrative 380 domain as the MN, MIP Proxy and HA. 381 - The NATÆed network MUST be configured with the IP addresses 382 reserved for private Internets by IANA ([RFC1918], [LOCAL- 383 LINK]). 384 - If the NATÆed network is multi-subnetted, the routers within 385 that network cannot be compromised. 386 - The HA SHOULD NOT be modified. 387 - MNÆs home network MUST be in a routable IP address domain. 388 This address domain MAY be behind a firewall/DMZ. 389 - A FA MAY NOT be available in the ISP access or core network. 390 - Security implications should not be worse than direct comm. 391 With HA. 393 Applicability in other network environments has not been 394 verified; however it is not explicitly precluded. Furthermore, 395 the proposed solution MAY be used in combination with other NAT 396 traversal solutions as appropriate. 398 If the MNÆs home network is in a non-routable IP address 399 domain, an appropriate solution (outside the scope of this 400 draft) MUST be deployed to make the home network accessible 401 from an external public or private network. 403 5.3. Using the MIP Proxy for NAT Traversal 405 The MIP Proxy acts as an intermediate node between a MN in 406 foreign network behind NAT and itÆs HA. MIPv4 registration 407 requests from the MN are sent to the MIP Proxy, instead of the 408 actual HA. The MIP Proxy terminates the registration request 409 and validates the payload. If the registration request is 410 acceptable, the MIP Proxy creates a new registration request 411 and forwards it to the HA on behalf of the MN. The registration 412 response from the HA is translated into a new response from the 413 MIP Proxy back to the MN. 415 All subsequent MIPv4 data traffic between the MN and the MIP 416 Proxy SHOULD be encapsulated in a UDP tunnel, in order to help 417 the NAT gateway demultiplex return inbound MIPv4 traffic 418 NAT/NAPT mechanisms. 420 The solution is detailed in the following sections. 422 5.3.1. When does a MN register with the MIP Proxy? 424 A mobile node MUST register with the MIP Proxy when it roams to 425 a foreign network behind a NAT gateway. Mechanisms to detect 426 the presence of a NAT gateway are beyond the scope of this 427 draft. 429 5.3.1.1. Selection of the COA Field in the Registration Request Payload 431 As explained in the problem statement, the use of a non-routable 432 address as the COA causes the MN to lose its connectivity to its 433 home network. Therefore, the MN MUST use the NAT gatewayÆs 434 routable (WAN) as the COA in its registration payload. The MN 435 MAY be configured with the NAT gatewayÆs routable IP address a 436 priori. However, if this is not feasible, it is imperative for 437 the MN to use a secured discovery scheme to realize the NAT 438 gatewayÆs routable address to avoid potential Denial-of-Service 439 (DoS) attacks. The following diagrams show one possible method 440 for dynamically discovering and verifying the NAT gatewayÆs 441 routable address. 443 MN NAT MIP Proxy 444 |Registration | | 445 |Request (COA=0) | | 446 |-----------------> |Registration | 447 | |Request | 448 | |-------------->| 449 | | | 450 | |Registration | 451 | | Reply With | 452 | | Reject | 453 | Registration |<------------ | 454 | Reply With Reject | | 455 | <---------------- | | 456 | | | 458 Figure 5.3a : Discovery of the NAT gatewayÆs routable 459 address 461 MN NAT 462 | | 463 |ICMP echo Message(s) | 464 | | 465 | ----------------------> | 466 |ICMP Reply Message(s) | 467 | | 468 | <----------------------- | 469 | | 471 Figure 5.3b : Verification of the NAT gatewayÆs routable 472 address 474 The NAT gatewayÆs routable address discovery (as depicted in 475 Figure 5.3a) is accomplished as a part of the registration 476 request protocol initiated when the MN roams to a foreign 477 network behind a NAT gateway. The MN MUST send a registration 478 request to the MIP Proxy with the COA set to a zero. As the 479 registration payload contains an invalid COA, the MIP Proxy 480 MUST send a registration reply with error code 134 (Poorly 481 Formatted). The MIP Proxy MUST also include the NAT Discovery 482 extension in its reply (see section 5.3.1.2). The MIP Proxy 483 employs this extension to notify the MN about the possible NAT 484 gatewayÆs routable address, obtained from the source IP address 485 of the registration request. 487 The MN MAY verify this IP address, before it can use it as the 488 COA in its registration payload. With NAT-router gateways, The 489 MN MAY achieve this by analyzing the trace-route log (i.e., a 490 series of ICMP echo and reply messages) from the MN to the 491 possible NAT gatewayÆs routable address obtained form the 492 registration discovery extension. 494 5.3.1.2. Discovery Registration Extension 496 The following shows the format of the NAT Discovery extension 497 used in the registration reply from the MIP Proxy to the MN. 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Length | Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Possible NAT GatewayÆs routable Address | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Type: 180 507 Length: Indicates (in bytes) of the data fields within the 508 extension, excluding the Type and Length bytes. 509 Reserved: For future user. 510 Possible NAT GatewayÆs routable Address: An IP address 512 Once the MN obtains and verifies the NAT gatewayÆs public 513 address, it MUST send a registration request with the COA set 514 to the NAT gatewayÆs routable address. 516 5.3.2. MIPv4 registration protocol between MN and HA 518 Once the MN obtains and verifies the NAT gatewayÆs routable 519 address, the MN MUST register with its actual home agent via 520 the MIP Proxy. Therefore, 521 the normal flow of MIPv4 registration messages between a MN and 522 a HA are altered as depicted in the figure below. 524 MN NAT Gateway MIP Proxy HA 525 |Reg.Request | | | 526 |----------------->|Reg. Request | | 527 | |-----------------> |Reg. Request | 528 | | |----------------->| 529 | | |Reg. Reply | 530 | |Reg. Reply |<-----------------| 531 |Reg. Reply |<----------------- | | 532 |<-----------------| | | 534 Figure 5.3.2 : Mobile IP registration protocol between 535 MN and HA 537 5.3.2.1. Establishing UDP Tunnel Parameters for MIPv4 Data Traffic 539 To support multiple, simultaneous MIPv4 data sessions from MNs 540 behind a NAT gateway to a home network via the same HA, a UDP 541 tunnel MUST be established between the MN and MIP Proxy. The 542 MN MUST use the parameter registration extension (see section 543 5.3.2.3) to notify the MIP Proxy about the UDP port number 544 ought to be used to establish a UDP tunnel for the Mobile IP 545 data traffic between the MN and MIP Proxy. 547 The UDP port number 434 MAY be used to tunnel the data traffic 548 between the MN and MIP Proxy. However, this MAY have some 549 performance implications. If any UDP port numbers other than 550 434 is used, a new entry in the NAT gatewayÆs address/port 551 mapping MUST be created right after a successful registration. 552 This can be done, by sending a NULL UDP packet (i.e, an empty 553 payload) from the MN to the MIP proxy. 555 The mobile node MUST maintain the selected UDP port number for 556 the lifetime of the registration request. The MN SHOULD ensure 557 that the NAT gatewayÆs lifetime for the UDP tunnel port mapping 558 does not expire prior to the expiry of the Registration 559 lifetime. This MAY be done through some sort of periodic 560 KeepAlive messages from the MN to MIP Proxy. 562 5.3.2.2. Discovering the MNÆs actual home agent by the MIP Proxy 564 The MN MUST notify the MIP Proxy about its actual home agent 565 address, via the parameter registration extension. The 566 following shows the parameter registration extension format. 568 5.3.2.3. Parameter Registration Extension 570 The following shows the format of the parameter extension used 571 in the registration request from MN to the MIP Proxy. 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type | Length | Reserved | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Home Agent Address | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | UDP Port Number | Reserved | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 582 Type : 181 583 Length : 584 Indicates (in bytes) of the data fields within the 585 extension, excluding the Type and Length bytes. 586 Reserved: For future use. 587 Home Agent Address: An IP address of the MNÆs actual 588 home agent 589 UDP Port Number: Used to establish UDP tunnel 590 Reserved: For future use. 592 5.3.2.4. MIPv4 Registration Request Packet Flow From MN to HA 594 The MN sends the Registration Request to the MIP Proxy. The 595 intervening NAT gateway modifies the source IP address (and 596 possibly the UDP source port). 598 From MN to the MIP Proxy: 600 +--------------------------------------------------+ 601 |IP-S = MN-COA | Permanent Address = MN-Perm | 602 |IP-D = MIPP-Pub | Home Agent = MIPP-Priv | 603 | | Care-of Address = NATGW-Pub | 604 | | . . . | 605 +--------------------------------------------------+ 607 The NAT gateway modifies the source IP address, and possibly 608 UDP source port number. 610 +--------------------------------------------------+ 611 |IP-S = NATGW-Pub | Permanent Address = MN-Perm | 612 |IP-D = MIPP-Pub | Home Agent = MIPP-Priv | 613 | | Care-of Address = NATGW-Pub | 614 | | . . . | 615 +--------------------------------------------------+ 617 The MIP Proxy terminates and authenticates the Registration 618 Request received from the MN. It then modifies the registration 619 request payload and forwards a new registration request to the 620 HA associated with the MN. The MIP Proxy MUST set the Home 621 Agent and Care-of Address fields of the registration request to 622 the MNÆs actual HA (learned from the parameter registration 623 extension) and the MIP ProxyÆs private address respectively. 624 The packet format is shown below. 626 +--------------------------------------------------+ 627 |IP-S = MIPP-Priv | Permanent Address = MN-Perm | 628 |IP-D = HA | Home Agent = HA | 629 | | Care-of Address = MIPP-Priv | 630 | | . . . | 631 +--------------------------------------------------+ 633 The MIP Proxy maintains a registration binding cache similar to 634 the one specified by [RFC2002] for a HA, in order to forward 635 the registration replies and subsequent MIPv4 data traffic. In 636 addition, the MIP Proxy MUST also record the UDP port number 637 (learned form the parameter registration extension) for the UDP 638 tunnel between the MN and the MIP Proxy in the registration 639 binding cache. The MIP Proxy MUST not manage registration 640 lifetimes and MUST NOT reinitiate a registration request with a 641 HA prior to its expiration. A MN MUST continue to manage 642 Registration lifetimes as specified in [RFC2002]. 644 5.3.2.5. MIPv4 Registration Reply Packet Flow From HA to MN 646 If the actual HA were to accept the registration request, the 647 reply flow sequence will be as follows: 649 From the HA to the MIP Proxy: 650 +--------------------------------------------------+ 651 |IP-S = HA | Home Agent = HA | 652 |IP-D = MIPP-Pri | . . . | 653 +--------------------------------------------------+ 655 From the MIP Proxy to the NAT 656 +-------------------------------------------------+ 657 |IP-S = MIPP-Pub | Home Agent = MIPP-Pub | 658 |IP-D = NAT-Pub | . . . | 659 +-------------------------------------------------+ 661 From the NAT to the MN: 663 +--------------------------------------------------+ 664 |IP-S = NAT-Priv | Home Agent = MIPP-Pub | 665 |IP-D = MN-Perm | . . . | 666 +--------------------------------------------------+ 668 5.3.3. MIPv4 data traffic from MN to CN 670 The normal flow of MIPv4 data flow between a MN and a HA are 671 altered as depicted in the figures below. Note that the data 672 traffic form the MN to MIP Proxy is encapsulated in a UDP 673 tunnel. 675 MN NAT MIP CN 676 Proxy 677 | | | | 678 |IP/UDP/IP| | | 679 |-------> | | | 680 | |IP/UDP/IP| | 681 | |-------> | | 682 | | | IP | 683 | | |------>| 685 Figure 5.3.5 : MIP Proxy forwards data packet directly 686 to CN 688 All MIPv4 data traffic between the MN and MIP Proxy will be 689 encapsulated in a UDP tunnel. The MIP Proxy will strip off the 690 outer IP and UDP headers, and re-encapsulate the detunneled 691 packet in an IP header (from MIPP-Pub to MN or from MIPP-Priv 692 to HA as the case may be) before forwarding it to the MN or HA 693 respectively. The following figures illustrate the traffic flow 694 from the MN to the MIP Proxy, and the MIP Proxy to the actual 695 HA. 697 MIPv4 data packet flow from the MN to the MIP Proxy: 699 +-------------------------------------------------------+ 700 |IP-S=MN-COA |UDP Src Port# |IP Src = MN-Perm | Data | 701 |IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN | | 702 +-------------------------------------------------------+ 704 The intermediate NAT gateway will apply address and port 705 mapping on the packet, and forward the packet, as follows: 707 +-------------------------------------------------------+ 708 |IP-S=NAT-Pub |UDP Src Port# |IP Src = MN-Perm |Data | 709 |IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN | | 710 +-------------------------------------------------------+ 711 MIPv4 data packet flow from the MIP Proxy to CN is as follows: 713 +------------------------------------------------+ 714 | IP-S = MIPP-Pri |IP Src = MN-Perm |Data | 715 | IP-D = CN |IP Dest = CN | | 716 +------------------------------------------------+ 718 5.3.4. MIPv4 data traffic from CN to MN 720 MIPv4 data traffic will be tunneled from the actual HA to the 721 MIP Proxy IP-in-IP tunnel is illustrated in the figure above, 722 however the discussion applies to other MIPv4 encapsulation 723 modes as well). The MIP Proxy strips off the outer IP header, 724 and forwards the inner IP packet to the MN in a UDP tunnel. 726 The following figures illustrate the traffic flow from the CN 727 to the MN (via the actual HA and the MIP Proxy). 729 The data packets from the CN will be sent to the MNÆs permanent 730 address, MN-Perm. 732 +-----------------------------+ 733 | IP-S = CN |Data | 734 | IP-D = MN-Perm | | 735 +-----------------------------+ 737 The MNÆs home agent will intercept the data packet, and will 738 forward it to its current care-of address (i.e., MIP Proxy) as 739 follows: 741 +----------------------------------------------+ 742 | IP-S = HA |IP Src = MN-Perm |Data | 743 | IP-D = MIPP-Priv |IP Dest = CN | | 744 +----------------------------------------------+ 746 From the MIP Proxy to the NAT gateway: 747 +---------------------------------------------------------+ 748 |IP-S = MIPP-Pub |UDP Src Port# |IP Src = MN-Perm |Data | 749 |IP-D = NAT-Pub |UDP Dest Port#|IP Dest = CN | | 750 +---------------------------------------------------------+ 752 The NAT gateway unapplies address and port mapping on the 753 packet, and forwards the packet, as follows: 755 From the NAT gateway to the MN: 756 +----------------------------------------------------------+ 757 | IP-S = MIPP-Pub |UDP Src Port# |IP Src = MN-Perm |Data | 758 | IP-D = MN-COA |UDP Dest Port#|IP Dest = CN | | 759 +----------------------------------------------------------+ 761 5.4. Summary of changes on MIPv4 components required by this solution 763 This solution requires changes on the mobile node, and of 764 course an addition of a new component, the MIP Proxy. 766 5.4.1. Required Changes to a MN 768 - The MN MUST be configured with the static IP address of the 769 MIP Proxy. A mechanism for MIP Proxy discovery MAY be defined 770 in future. 771 - The MN MUST be able to determine if it has roamed to a 772 private address space behind a NAT gateway. 773 - The MN MUST implement the registration extension as specified 774 in this draft. 775 - The MN SHOULD be able to extend the lifetime of the NAT 776 gatewayÆs address and port mapping entries for the UDP tunnel 777 beyond the registration lifetime determined with itÆs HA. 779 5.4.2. Required Configuration for the MIP Proxy 781 - The MIP Proxy MUST be configured with all of the SAs of an MN 782 and a HA that it represents as a surrogate. 783 - The MIP Proxy SHOULD be configured with static IP addresses 784 to avoid periodic reconfiguration on MNs. 786 5.5. Performance Implications of MIP Proxy assisted NAT Traversal 788 - The proposed method creates a layer of indirection (i.e., the 789 MIP Proxy), which MAY have some performance implications. 790 - An eight bytes UDP header is added to the Mobile IP data 791 traffic from the MN to MIP Proxy. 792 - Discovery and verification method of the NAT gatewayÆs public 793 address will degrade the registration hand-off performance. 795 5.6. Implications of Twice NAT between the MN and MIP Proxy 796 The proposed solution MAY not work if Twice NAT is encountered 797 in the path between the MN and the MIP proxy. 799 6. MIPv4 Traversal Through IPsec VPN Gateways 801 A MN whose home network is in a routable IP address space 802 behind a VPN gateway could roam to an external public or 803 private address space. An example would be a user who roams 804 from within a Corporate Intranet to an external wired or 805 wireless hot spot. In this case, the MNÆs HA is located in the 806 Corporate Intranet behind the firewall/DMZ complex, as 807 illustrated in the figure below. 809 It is desirable in this scenario to connect back to the 810 Intranet via a VPN and stay connected even as the user roams 811 from one external IP subnet to another. The integration of 812 MIPv4 and IPsec has not been standardized and several issues 813 have to overcome to support seamless end-to-end IPsec. This 814 draft describes a solution based on the use of the MIP Proxy to 815 enable seamless traversal across IPsec-based VPNs. 817 +----------------+ +-----+ +------+ +-----+ +---------------+ 818 |Foreign network | | | ->|VPN-GW|<---- | | |Home network | 819 |+----+ +----+ | |Outer| | +------+ | |Inner| | +----+ +----+ | 820 || MN | | FA | | |FW | | | |FW | | |HA | | CN | | 821 |+----+ +----+ | | | | +---------+ | | | | +----+ +----+ | 822 | | | | ->|MIP Proxy|<- | | | | 823 +----------------+ +-----+ +---------+ +-----+ | +----+ | 824 ^ ^ | | MN | | 825 |----- Firewall/DMZ ----- | | +----+ | 826 +---------------+ 828 Figure 6.0 : MN has moved from its home network to a foreign 829 network outside the DMZ 831 6.1. IPsec VPN Traversal Problem Statement 833 With respect to Figure 6.0 above, the problem can be summarized 834 in the following 2 scenarios: 836 Scenario 1: The MN could roam into a foreign subnet without a 837 FA and obtain a COA at its point of attachment (via DHCP or 838 other means). In an end-to-end security model, an IPsec tunnel 839 that terminates at the VPN gateway in the DMZ MUST protect the 840 IP traffic originating at the MN. If the IPsec tunnel is 841 associated with the COA, the tunnel SA MUST be refreshed after 842 each subnet handoff which could have some performance 843 implications on real-time applications. 845 Scenario 2: The MN could roam into a foreign subnet with a FA. 846 If the MN were to associate a VPN tunnel with its COA, the FA 847 (which is likely in a different administrative domain) cannot 848 parse the IPsec, will not be able to setup SAs with the MNÆs 849 VPN gateway and will consequently be not able to relay MIPv4 850 packets between the MN and the VPN gateway. 852 6.2. Integration of MIPv4 and IPsec 854 Clearly there are several schemes to apply IPsec to MIPv4 855 packets. [MIPv4-SEC-GUIDE] describes different segments where 856 IPsec could be applied to MIPv4 packets. This draft is based on 857 the premise that the most likely acceptable scenario is the one 858 in which IPsec is applied end-to-end. 860 6.3. Assumptions and Applicability 862 The solution is derived based on the following assumptions and 863 applicability criteria: 864 - End-to-end IPsec tunnel mode MUST be applied to MIPv4 data 865 flows; i.e. between the MN and the VPN gateway at the edge of 866 its home network. 867 - MIPv4 registration packets MAY NOT require IPsec tunnel as 868 they are authenticated and integrity protected. However, they 869 MUST be terminated inside the DMZ to enable authenticated 870 firewall traversal. 871 - FA-assisted routing and MN co-located modes of operation MUST 872 be supported. 873 - The MN MUST be configured with the MIP Proxy and the VPN 874 gatewayÆs external IP addresses, and route the MIPv4 traffic 875 through the MIP Proxy when it is outside the corporate 876 intranet. 877 - The MN SHOULD be able to determine if it has roamed outside 878 the corporate network by some method (e.g., by comparing its 879 current COA against address blocks used by the corporate 880 intranet). 881 - The MN MUST be able to determine when it should exercise its 882 key exchange protocol to establish the IPsec tunnel SA to the 883 VPN gateway. 885 6.4. Solution Considerations 887 In addition to enabling the use of end-to-end IPsec with MIPv4, 888 the use of the MIP Proxy in the DMZ enables a solution that can 889 meet the following criteria: 891 6.4.1. Fast Handoffs 893 To support fast handoffs across IP subnets, it is imperative to 894 keep the key management overhead down to a minimum. In this 895 draft, we propose a mechanism whereby the IPsec tunnel SA can 896 be bound to the invariant permanent IP address of the MN. Doing 897 so, enables the reuse of the SA across IP subnet handoffs and 898 also minimizes the protocol handshake between the VPN gateway, 899 actual HA and the MIP Proxy. 901 6.4.2. Preserve Existing VPN Infrastructure 903 This implies the following: 904 - Preserves the investment in existing VPN gateways 905 - Requires no software upgrades to VPN gateways to explicitly 906 support MIPv4 users 907 - Preserves IPsec VPN security requirements that are not 908 inferior to what is already provided to existing "nomadic 909 computing" remote access users, i.e. for confidentiality, 910 primary and secondary authentication, message integrity, 911 protection against replay attacks and related security services 913 6.4.3. Preserve Existing DMZ Traversal Policies 915 Most Corporate DMZ policies recommend authenticated firewall 916 traversal for protocols that traverse the DMZ. Placing devices 917 outside the outer DMZ firewall to assist with DMZ traversal 918 exposes the device to hackers and is generally not an 919 acceptable solution. IT departments prefer that solutions 920 adhere to and can be accommodated with existing or compliant 921 DMZ ACLs. 923 6.5. Deploying the MIP Proxy to support VPN Traversal 925 As shown in Figure 6.0, the MIP Proxy is deployed in parallel 926 to an existing VPN gateway in the DMZ to support MIPv4. 928 6.5.1. Mobile IPv4 Registration 930 The MN sends MIPv4 registration requests directly to the MIP 931 Proxy. The MIP Proxy terminates and authenticates the 932 registration requests. It then generates a new registration 933 request and forwards it to the corresponding HA. The 934 registration request MUST include the discovery registration 935 extension (see section 5.3.1.2.) to notify the MIP Proxy about 936 the MNÆs actual home agent. The registration replies from the 937 HA will also go through the MIP Proxy bypassing the VPN 938 gateway. Note that the MN and the MIP Proxy MUST share the SA 939 for the MN-HA authentication extension. 941 This solution also works if the MN were to use a FA in the 942 foreign network. 943 A rail-road diagram illustrating the MIPv4 registration process 944 is shown below. 946 MN MIP Proxy HA 947 |Reg. Request | | 948 |-----------------> | | 949 | |Reg. Request | 950 | |----------------->| 951 | |Reg. Reply | 952 | |<-----------------| 953 |Reg. Reply | | 954 |<----------------- | | 956 Figure 6.5.1 : Mobile IP registration protocol between 957 MN and HA 959 6.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA 960 This draft illustrates the sequence from MN to HA via a FA û it 961 can be easily extended to describe the flow for a co-located 962 COA mode MN. 964 From the MN to a FA: 965 +--------------------------------------------------+ 966 |IP-S = MN-Perm | Permanent Address = MN-Perm | 967 |IP-D = FA_COA | Home Agent = MIPP-Pub | 968 | | Care-of Address = FA COA | 969 | | . . . | 970 +--------------------------------------------------+ 972 From the FA to the MIP Proxy: 973 +--------------------------------------------------+ 974 |IP-S = FA COA | Permanent Address = MN-Perm | 975 |IP-D = MIPP-Pub | Home Agent = MIPP-Pub | 976 | | Care-of Address = FA COA | 977 | | . . . | 978 +--------------------------------------------------+ 980 From the MIP Proxy to the actual HA: 981 +--------------------------------------------------+ 982 |IP-S = MIPP-Priv | Permanent Address = MN-Perm | 983 |IP-D = HA | Home Agent = HA | 984 | | Care-of Address = MIPP-Priv | 985 | | . . . | 986 +--------------------------------------------------+ 988 6.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN 990 If the actual HA were to accept the registration request, the 991 reply flow sequence will be as follows: 993 From the HA to the MIP Proxy: 994 +--------------------------------------------------+ 995 |IP-S = HA | Home Agent = HA | 996 |IP-D = MIPP-Priv | . . . | 997 +--------------------------------------------------+ 999 From the MIP Proxy to the FA: 1000 +--------------------------------------------------+ 1001 |IP-S = MIPP-Pub | Home Agent = MIPP-Pub | 1002 |IP-D = FA | . . . | 1003 +--------------------------------------------------+ 1005 From the FA to the MN: 1006 +--------------------------------------------------+ 1007 |IP-S = FA | Home Agent = MIPP-Pub | 1008 |IP-D = MN-Perm | . . . | 1009 +--------------------------------------------------+ 1011 6.5.1.3. DMZ Configuration Requirements for MIPv4 Registration Packets 1012 The DMZ ACLs MUST be setup for the following: 1013 - Inbound UDP registration packets (destination port = 434 and 1014 destination address = MIPP-Pub) MUST be permitted. 1015 - The DMZ inner firewall MUST permit the forwarding of 1016 registration request and reply packets from the MIP Proxy to 1017 one or more HAs. 1019 6.5.2. Mobile IPv4 Data Processing 1021 The following railroad diagram illustrates the sequence of 1022 steps to establish secured MIPv4 traffic between a MN and a CN. 1023 The process initially occurs in 3 sequential steps: MIPv4 1024 registration, IPsec tunnel SA establishment and MIPv4 data 1025 forwarding. Registration and SA refreshes may subsequently 1026 occur independent of each other. 1028 MIPv4 Registration- see Figure 6.5.1 1029 Note that the VPN gateway is not involved in the MIPv4 1030 Registration process. 1032 IPsec Tunnel SA Establishment: 1033 MN VPN Gateway 1034 | | 1035 |IKE Phase 1 (ISAKMP SA) <----------> | 1036 | | 1037 |IKE Phase 2 (Tunnel SA) <----------> | 1038 | | 1040 Note that the MIP proxy is not involved in the Tunnel SA 1041 establishment and will not be involved in SA refreshes. 1043 The data forwarding is described in the following 2 sub- 1044 sections. 1046 6.5.2.1. MIPv4 Data Traffic from MN to CN 1048 The MN generates an IP packet from the MN-Perm interface and 1049 destined to the CN. This packet is encapsulated in an IPsec-ESP 1050 tunnel from MN-Perm to VPNGW-Pub. The packet in turn is 1051 encapsulated in an IP header from MN COA to the MIP Proxy. The 1052 MIP Proxy strips off the outermost IP header and forwards the 1053 inner IP packet (which is from the MNÆs permanent address to 1054 the VPN gateway) to the VPN gateway. The VPN gateway in turn 1055 processes the IPsec VPN tunnel, strips off the IP and ESP 1056 headers and forwards the inner most IP packet to the 1057 destination CN. The railroad diagram depicts the packet flow 1058 sequence, followed by a description of packets as they traverse 1059 the network. 1061 MN FA MIP Proxy VPN Gateway HA CN 1062 | | | | | | 1063 |------>| | | | | 1064 | | -------> | | | | 1065 | | | ------------> | | | 1066 | | | | ------------------> | 1068 From the MN to MIP Proxy: IP-IP-ESP-IP-TCP/UDP-Data 1069 From MIP Proxy to VPN: IP-ESP-IP 1070 From VPN Gateway to CN: IP 1072 The packet flow from the MN to the CN is described below. The 1073 analysis assumes than the MN employs reverse tunneling to the 1074 HA (which is the MIP Proxy in this case) and that packets are 1075 routed via a FA. 1077 From the MN to the FA: 1078 +-------------------------------------------------------------+ 1079 |IP-S=MN-Perm |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 1080 |IP-D=MIPP-Pub|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 1081 | | |VPNGW-Pub | | | 1082 +-------------------------------------------------------------+ 1083 In this case, the layer-2 destination address is set to the MAC 1084 address of the FA. 1086 From the FA to the MIP Proxy: 1087 +-------------------------------------------------------------+ 1088 |IP-S=FA COA |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 1089 |IP-D=MIPP-Pub|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 1090 | | |VPNGW-Pub | | | 1091 +-------------------------------------------------------------+ 1092 Clearly, the FA does not need to know the IPsec tunnel SA to 1093 process the packet. 1095 From the MIP Proxy to the VPN gateway: 1096 The MIP Proxy strips off the outermost IP header and forwards 1097 the packet to the VPN gatewayÆs outer interface using the 1098 layer-2 address corresponding to VPNGW-Pub. 1099 +-----------------------------------------------+ 1100 |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 1101 |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 1102 | |VPNGW-Pub | | | 1103 +-----------------------------------------------+ 1105 From the VPN gateway to the CN: 1106 The VPN gateway completes IPsec tunnel processing on the 1107 packet, strips off the outermost IP and ESP headers and 1108 forwards the encapsulated IP datagram to the CN. 1109 +---------------------+ 1110 |IP-S=MN-Perm| Data | 1111 |IP-D=CN | | 1112 +---------------------+ 1114 6.5.2.2. MIPv4 Data Traffic from CN to MN 1116 The outbound MIPv4 data traffic destined to the MNÆs co-located 1117 address is always tunneled to the MIP Proxy (which appears as a 1118 surrogate MN to the actual HA). The MIP Proxy forwards the 1119 inner IP packet (with MN-Perm as the destination address) to 1120 the VPN gateway. The VPN gateway applies the IPsec ESP tunnel 1121 SA on the packet. The VPN gateway forwards the packet back to 1122 the MIP Proxy on its MIPP-Pub interface û this is accomplished 1123 by a routing table update on the VPN gateway. The MIP Proxy in 1124 turn tunnels the IPsecÆed packet to the MNÆs COA. The railroad 1125 diagram depicts the packet flow sequence, followed by a 1126 description of packets as they traverse the network. 1128 MN FA MIP Proxy VPN Gateway HA CN 1129 | | | | | | 1130 | | | | | <------ | 1131 | | | <------------------------ | | 1132 | | | ------------> | | | 1133 | | | <----------- | | | 1134 | | <--------| | | | 1135 | <-----| | | | | 1137 From the HA to the MIP Proxy: IP-IP 1138 From the MIP Proxy to the VPN gateway: IP 1139 From the VPN gateway to the MIP Proxy: IP-ESP-IP 1140 From the MIP Proxy to the MN: IP-IP-ESP-IP 1142 The packet flow from the CN to the MN is described below. 1143 From the CN to the actual HA: 1144 +---------------------+ 1145 |IP-S=CN | Data | 1146 |IP-D=MN-Perm| | 1147 +---------------------+ 1148 The CN sets the layer-2 destination address to that of the 1149 actual HA. 1151 From the actual HA to the MIP Proxy: 1152 +------------------------------------+ 1153 |IP-S=HA |IP-S=CN | Data | 1154 |IP-D=MIPP-Priv|IP-D=MN-Perm| | 1155 +------------------------------------+ 1157 From the MIP Proxy to the VPN gateway: 1158 The MIP Proxy strips off the outermost IP header and forwards 1159 the packet to the VPNGW-Priv interface using the corresponding 1160 layer-2 address. 1161 +---------------------+ 1162 |IP-S=CN | Data | 1163 |IP-D=MN-Perm| | 1164 +---------------------+ 1166 From the VPN gateway to the MIP Proxy: 1167 The VPN gateway applies an IPsec ESP tunnel SA to the IP packet 1168 and forwards it back to the MIP Proxy on the MIPP-Pub interface 1169 based on its routing table. 1170 +-------------------------------------------------+ 1171 |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | 1172 |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1173 | |MN-Perm | | | 1174 +-------------------------------------------------+ 1176 From the MIP Proxy to the FA: 1177 The MIP Proxy adds an outer encapsulating IP header to the FA 1178 COA. 1179 +-----------------------------------------------------------+ 1180 |IP-S=MIPP-Pub|IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN |Data| 1181 |IP-D=FA COA |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1182 | | |MN-Perm | | | 1183 +-----------------------------------------------------------+ 1185 From the FA to the MN: 1186 The FA strips off the outermost IP header and forwards the 1187 packet to the MN. 1188 +-------------------------------------------------+ 1189 |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | 1190 |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1191 | |MN-Perm | | | 1192 +-------------------------------------------------+ 1194 The MN terminates the IPsec tunnel and processes the MIPv4 data 1195 as always. 1197 6.5.3. Support For Route Optimization 1199 The MIP Proxy MUST NOT support Route Optimization [ROUTE-OPT]. 1200 However, the Route Optimization between the correspondent node 1201 and the mobile nodeÆs actual home agent MAY be performed. 1203 6.6. Key Management and SA Preservation 1205 The scheme described in the previous section binds the IPsec 1206 tunnel SA to the normally invariant permanent IP address of the 1207 MN. This implies that the tunnel SA can be preserved even when 1208 the MN changes its co-located COA or connects via a FA in a 1209 different IP subnet. The SA however must be refreshed prior to 1210 its lifetime expiration. Also, many VPN gateway implementations 1211 support some keep-alive mechanism to detect the presence of a 1212 VPN client and "retire" the SA if the VPN client is not 1213 detected for a period of time. If an MN loses link connectivity 1214 for a period extending the keep-alive timeout interval, it MUST 1215 reestablish the tunnel SA, regardless of whether it reconnects 1216 to the same IP subnet or not. 1218 The scheme also preserves any secondary authentication 1219 mechanisms that may be in the place to authenticate a remote 1220 access user. 1222 6.7. DMZ and VPN Gateway Configuration Requirements 1224 The solution described in this section makes the following 1225 assumptions on the configurability of the VPN gateway and the 1226 DMZ ACLs: 1227 - It MUST be possible to configure the VPN gatewayÆs routing 1228 table to deliver the outbound IPsecÆed MIPv4 packets destined 1229 to MN-Perm to the MIP ProxyÆs MIP-Pub interface, if MIP Proxy 1230 is not co-located with the VPN gateway. 1231 - The outer firewall MUST allow inbound tunneled IP packets 1232 destined to the MIP Proxy 1233 - The MIP Proxy MUST be able to forward packets (destined to 1234 MN) to VPN gateway via layer 2 mechanism. This implies that 1235 the MIP Proxy and VPN Gateway MUST be on the same subnet. 1237 6.8. Supporting Other IPsec-based VPN Configurations 1239 The scheme currently described in this draft assumes a native 1240 IPsec VPN scheme extended to support secondary authentication 1241 schemes. Its applicability to other IPsec VPN configurations 1242 such as L2TP over IPsec transport and ESP-in-UDP tunneling is 1243 yet to be determined. 1245 6.9. Considerations for Integrating the MIP Proxy and VPN Gateway 1247 The MIP Proxy as described in this draft is a logical 1248 functional component and as such can be deployed in the DMZ in 1249 one of 2 possible ways: 1250 - As a standalone device in parallel with the VPN gateway as 1251 depicted in Figure 6.0. This decouples support for MIPv4 users 1252 from any software or hardware upgrades to the VPN gateway 1253 itself and also enables multi-vendor interoperability. The 1254 scheme however adds some overhead to the end-to-end 1255 communication path between an MN and a CN and requires minimal 1256 support from the VPN gateway software (i.e. a mechanism to make 1257 routing table updates). 1258 - Integrated as a software component with the VPN gateway. This 1259 clearly reduces the communication overhead but tightly couples 1260 support for MIPv4 users with any software upgrades to the VPN 1261 gateway itself. 1263 7. Using the MIP Proxy for combined NAT and VPN Traversal 1264 The discussion in the draft would be incomplete without 1265 describing a scenario in which a MN roams into a foreign NATÆed 1266 network and has to connect back to itÆs home network which is 1267 behind a DMZ. Many Enterprises are deploying wireless LANs as a 1268 private NATÆed network outside their DMZ-users that roam into 1269 such a network will be forced to VPN back into their Intranet. 1270 Such a scenario can be supported with the MIP Proxy enabling 1271 simultaneous NAT and VPN traversal. The network configuration 1272 would be a combination of Figures X and Y. The analysis assumes 1273 that there is no FA in the NATÆed network. 1275 7.1. MIPv4 Registration Message Flow 1276 7.1.1. MIPv4 Registration Requests 1277 From the MN to the NAT gateway: 1278 +-----------------------------------------------+ 1279 |IP-S=MN-Perm | Permanent Address = MN-Perm | 1280 |IP-D=MIPP-Pub | Home Agent = MIPP-Pub | 1281 | | Care-of Address = NATGW-Pub | 1282 | | . . . | 1283 +-----------------------------------------------+ 1285 Please see the discussion in section 5 for possible mechanisms 1286 for an MN to determine the NAT gatewayÆs external (public) 1287 routable IP address. 1289 From the NAT gateway to the MIP Proxy: 1290 The NAT gateway performs source address and source UDP port 1291 translation before forwarding the packet to the MIP Proxy. 1293 +-----------------------------------------------+ 1294 |IP-S=NATGW-Pub | Permanent Address = MN-Perm | 1295 |IP-D=MIPP-Pub | Home Agent = MIPP-Pub | 1296 | | Care-of Address = NATGW-Pub | 1297 | | . . . | 1298 +-----------------------------------------------+ 1300 From the MIP Proxy to the actual HA: 1301 The MIP Proxy terminates and authenticates the registration 1302 request (as described in previous sections). It then creates a 1303 new registration request and forwards it to the actual HA. 1305 +-----------------------------------------------+ 1306 |IP-S=MIPP_Priv | Permanent Address = MN-Perm | 1307 |IP-D=HA | Home Agent = HA | 1308 | | Care-of Address = MIPP-Priv | 1309 | | . . . | 1310 +-----------------------------------------------+ 1312 7.1.2. MIPv4 Registration Replies 1313 From the actual HA to the MIP Proxy: 1315 +--------------------------------------+ 1316 |IP-S=HA | Home Agent = HA | 1317 |IP-D=MIPP-Priv | . . . | 1318 +--------------------------------------+ 1320 From the MIP Proxy to the NAT gateway: 1321 +--------------------------------------+ 1322 |IP-S=MIPP-Pub | Home Agent = MIPP-Pub| 1323 |IP-D=NATGW-Pub | . . . | 1324 +------------------------------- ------+ 1326 From the NAT gateway to the MN: 1327 +----------------------------------------+ 1328 |IP-S=NATGW-Priv | Home Agent = MIPP-Pub | 1329 |IP-D=MN COA | . . . | 1330 +----------------------------------------+ 1332 7.2. MIPv4 Data Flow 1334 Reverse tunneling is assumed in the packet flow descriptions 1335 that follow. 1337 7.2.1. Data Flow from the MN to the CN 1339 From MN to the NAT gateway: 1340 +----------------------------------------------------------------+ 1341 |IP-S=MN-Priv | UDP |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm|Data | 1342 |IP-D=MIPP-Pub| |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 1343 | | | |VPNGW-Pub | | | 1344 +----------------------------------------------------------------+ 1346 From the NAT gateway to the MIP Proxy: 1347 +----------------------------------------------------------------+ 1348 |IP-S=NATGW-Pub| UDP |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm|Data| 1349 |IP-D=MIPP-Pub | |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 1350 | | | |VPNGW-Pub | | | 1351 +----------------------------------------------------------------+ 1352 From the MIP Proxy to the VPN gateway: 1353 +-----------------------------------------------+ 1354 |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 1355 |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 1356 | |VPNGW-Pub | | | 1357 +-----------------------------------------------+ 1359 From the VPN gateway to the CN: 1360 +---------------------+ 1361 |IP-S=MN-Perm| Data | 1362 |IP-D=CN | | 1363 +---------------------+ 1365 7.2.2. Data Flow from the CN to the MN 1367 From the CN to the actual HA: 1368 +---------------------+ 1369 |IP-S=CN | Data | 1370 |IP-D=MN-Perm| | 1371 +---------------------+ 1373 From the actual HA to the MIP Proxy: 1374 +------------------------------------+ 1375 |IP-S=HA |IP-S=CN | Data | 1376 |IP-D=MIPP-Priv|IP-D=MN-Perm| | 1377 +------------------------------------+ 1379 From the MIP proxy to the VPN gateway: 1380 The MIP proxy strips off the outer IP header and forwards the 1381 packet on the layer-2 address for VPNGW-Priv. 1382 +---------------------+ 1383 |IP-S=CN | Data | 1384 |IP-D=MN-Perm| | 1385 +---------------------+ 1387 From the VPN gateway to the MIP Proxy: 1388 +-------------------------------------------------+ 1389 |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | 1390 |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1391 | |MN-Perm | | | 1392 +-------------------------------------------------+ 1394 From the MIP Proxy to the NAT gateway: 1395 +------------------------------------------------------------------+ 1396 |IP-S=MIPP-Pub | UDP |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN |Data| 1397 |IP-D=NATGW-Pub| |IP-D=NM-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1398 | | | |MN-Perm | | | 1399 +------------------------------------------------------------------+ 1400 From the NAT gateway to MN: 1401 +-------------------------------------------------------------------+ 1402 |IP-S=NATGW-Priv| UDP |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN |Data| 1403 |IP-D=MN-Priv | |IP-D=NM-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1404 | | | |MN-Perm | | | 1405 +-------------------------------------------------------------------+ 1407 8. Security Implications 1409 The MIP Proxy is a functional entity that MUST be implemented on a 1410 secure device especially if it is deployed in the DMZ. The MIP Proxy 1411 is assumed to belong to the same (security) administrative domain as 1412 the MN and the actual HA. The protocol extensions specified in the 1413 draft do not introduce any new vulnerabilities to the mobile IP 1414 protocol. 1416 9. Acknowledgements 1418 The authors would like to thank Mike Andrews and Changwen Liu of 1419 Intel Corporation for their review and feedback on this draft. 1421 10. Patents 1423 Intel Corporation is in the process of filing one or more patent 1424 applications that may be relevant to this IETF draft. 1426 11. References 1427 [RFC2002] RFC 2002 : IP mobility support 1428 [RFC3024] RFC 3024 : Reverse tunneling for mobile IP 1429 [RFC2004] RFC 2004 : Minimal encapsulation within IP 1430 [RFC1701] RFC 1701 : Generic Routing encapsulation 1431 [RFC2119] RFC 2119 : Key words for use in RFCs to Indicate 1432 Requirement Levels 1433 [RFC1918] RFC 1918 : Address Allocation for Private Internets 1434 [DHCP] RFC 2131 : Dynamic Host Configuration Protocol 1435 [MIPv4-SEC-GUIDE] draft-bpatil-mobileip-sec-guide-01.txt - 1436 Requirements / Implementation Guidelines for Mobile IP using IP 1437 Security 1438 [[LOCAL-LINK] : Dynamic Configuration of Iv4 Link-Local Addresses, 1439 1440 [ROUTE-OPT] : Route Optimization in Mobile IP, 1443 Authors: 1445 Farid Adrangi 1446 Intel Corporation 1447 2111 N.E. 25th Avenue 1448 Hillsboro, OR 1449 USA 1451 Phone: 503-712-1791 1452 Email: farid.adrangi@intel.com 1454 Prakash Iyer 1455 Intel Corporation 1456 2111 N.E. 25th Avenue 1457 Hillsboro, OR 1458 USA 1460 Phone: 503-264-1815 1461 Email: prakash.iyer@intel.com