idnits 2.17.00 (12 Aug 2021) /tmp/idnits60703/draft-adrangi-mobileip-vpn-traversal-02.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 74 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 1 longer page, the longest (page 27) being 59 lines 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 a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 194: '...gateway in the DMZ MUST protect the IP...' RFC 2119 keyword, line 196: '...A, the tunnel SA MUST be refreshed aft...' RFC 2119 keyword, line 226: '...s. The MIP Proxy SHOULD belong to the ...' RFC 2119 keyword, line 228: '...sponding MNs. It MUST share SAs for va...' RFC 2119 keyword, line 235: '... dual-homed host. The MIP Proxy MAY be...' (93 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: - MIPv4 registration packets MAY NOT require an IPsec tunnel as they are authenticated and integrity protected. However, they MUST be terminated inside the DMZ to enable authenticated firewall traversal. == 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: VPN gateway must insert a route for the home network(s) to point to the MIP Proxy. This route MUST not be redistributed via an IGP. == 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: A MN may roam into a network served by a trusted FA. The trusted FA refers to a FA that has SA with the VPN-GW or a FA whose hosting network has SA with VPN-GW and an IPsec tunnel will be established between the FA or its hosting network and the VPN-GW while necessary to protect any traffic between. In this case, the MN MUST use the NAI extension in the FA route advertisement or other mechanisms which are out of the scope of this draft to determine that the FA is a trusted FA. The MN MUST not use the MIP Proxy in this scenario, the FA is responsible for properly tunneling the traffic including the MIP signaling and data through the VPN-GW. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '15' on line 1394 looks like a reference -- Missing reference section? '11' on line 1385 looks like a reference -- Missing reference section? '1' on line 1366 looks like a reference -- Missing reference section? '5' on line 1373 looks like a reference -- Missing reference section? '2' on line 1367 looks like a reference -- Missing reference section? '14' on line 1392 looks like a reference -- Missing reference section? '10' on line 1383 looks like a reference -- Missing reference section? '12' on line 1387 looks like a reference -- Missing reference section? '13' on line 1389 looks like a reference -- Missing reference section? '3' on line 1369 looks like a reference -- Missing reference section? '4' on line 1371 looks like a reference -- Missing reference section? '6' on line 1375 looks like a reference -- Missing reference section? '7' on line 1377 looks like a reference -- Missing reference section? '8' on line 1379 looks like a reference -- Missing reference section? '9' on line 1381 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Farid Adrangi 2 INTERNET DRAFT Prakash Iyer 3 Intel Corp. 4 Date: July 17 2002 5 Expires: January 2003 Kent Leung 6 Milind Kulkarni 7 Alpesh Patel 8 Cisco Systems 10 Qiang Zhang 11 Liqwid Networks 13 Joe Lau 14 Hewlett Packard 15 Corp. 17 Mobile IPv4 Traversal Across IPsec-based VPN Gateways 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance 22 with all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet 25 Engineering Task Force (IETF), its areas, and its working 26 groups. Note that other groups may also distribute working 27 documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- 32 Drafts as reference material or to cite them other than as "work 33 in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 To view the entire list of current Internet-Drafts, please 42 check the "1id-abstracts.txt" listing contained in the 43 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 44 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 45 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 46 Coast), or ftp.isi.edu (US West Coast). 48 Abstract 50 Multi-subnetted IEEE 802.11 WLAN networks are being widely 51 deployed in Enterprise Intranets û(in many cases requiring a 52 VPN tunnel to connect back and access Intranet resources), and 53 public areas such as airports, coffee shops, convention centers 54 and shopping malls. Many of these WLAN networks also employ NAT 55 to translate between non-routable and routable IPv4 care-of 56 (point of attachment) addresses. WWAN networks such as those 57 based on GPRS, 1xRTT and eventually EDGE, 1xEV, CDMA2000 and 58 UMTS are also starting to see deployment. These deployments are 59 paving the way for applications and usage scenarios requiring 60 TCP/IP session persistence and constant reachability while 61 connecting back to a secured (VPN protected), target ôhomeö 62 network. This in turn drives the need for a mobile VPN solution 63 that is multi-vendor interoperable, providing seamless access 64 with persistent VPN sessions - through NAT gateways when 65 needed. This draft proposes a solution framework that enables 66 efficient, seamless operation of Mobile IPv4 when combined with 67 an IPsec-based VPN and supporting NAT traversal when needed. 68 The solution has no link layer dependencies and can be applied 69 to other 802.3-compatible wired and wireless physical media as 70 well. 72 Table Of Contents 73 1. Introduction....................................................3 74 1.2. Goals.........................................................3 75 1.3. Problem Description...........................................4 76 1.4. Solution Overview.............................................5 77 1.4.1. Assumptions and Applicability...............................5 78 1.5. Terminology...................................................6 79 1.6. Acronyms......................................................6 80 2. Registration....................................................6 81 2.1. Authentication................................................7 82 2.2. Registration Request Process..................................7 83 2.2.1. Registration Request Bits...................................7 84 2.2.2. Registration Request Fields.................................8 85 2.2.3. Registration Request Extensions.............................8 86 2.2.4. Registration Request Validity Check.........................8 87 2.3. Registration Reply Process....................................9 88 2.3.1. Registration Reply Fields...................................9 89 2.4. Registration Reply Initiated by the MIP Proxy................10 90 2.4.1. New Registration Reply Codes...............................10 91 2.5. Mobile Node Considerations...................................10 92 2.5.1. Location Detection.........................................10 93 2.5.2. New Configuration Requirement..............................10 94 2.5.3. HA Parameter Extension.....................................10 95 2.6. MIP Proxy Considerations.....................................11 96 2.6.1. Algorithm for location detection...........................11 97 2.6.2. Simultaneous Mobility Binding..............................12 98 2.6.3. Mobile IP NAI Extension....................................13 99 2.6.4. Dynamic HA Assignment......................................13 100 2.6.5. Pending Registration List..................................13 101 2.6.6. Mobility Bindings..........................................14 102 2.6.7. Handling ICMP Error Messages...............................14 103 2.7. MIPv4 Registration Packet Flow...............................14 104 2.7.1. MIPv4 Registration Request Packet Flow from MN to HA.......14 105 2.7.2. MIPv4 Registration Reply Packet Flow from HA to MN.........15 106 3. Functions Not Performed By The MIP Proxy.......................15 107 4. MIP Proxy Integration with VPN.................................16 108 4.1. One-Box Integration..........................................16 109 4.1.1. Redundancy.................................................16 110 4.2. Two-Box Integration..........................................17 111 4.2.1. Two-Box Integration Requirements...........................17 112 5. MIPv4 Data Traffic Routing Through VPN.........................17 113 5.1. Establishment of Secured MIPv4 Traffic.......................17 114 5.2. Association Between VPN Inner and MN Home IP Address.........17 115 5.3. MIPv4 Data Traffic from MN on External Network to CN.........18 116 5.4. MIPv4 Data Traffic from CN to MN on External Network.........20 117 5.5. Key Management and SA Preservation...........................22 118 5.6. Supporting Other IPsec-based VPN Configurations..............22 119 5.7 Routing Considerations........................................22 120 5.7.1. Broadcast / multicast Datagrams............................22 121 5.7.2. MN Registration through a Trusted FA.......................23 122 6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways...........23 123 6.1. MIPv4 Registration Message Flow..............................24 124 6.1.1. MIPv4 Registration Requests................................24 125 6.1.2. MIPv4 Registration Replies.................................24 126 6.2. MIPv4 Data Flow..............................................25 127 6.2.1. Data Flow from the MN to the CN............................25 128 6.2.2. Data Flow from the CN to the MN............................25 129 7. Security Implications..........................................26 130 8. Acknowledgements...............................................26 131 9. Intellectual Property Rights...................................27 132 10. Revision History..............................................27 133 11. References....................................................27 135 1. Introduction 137 The problem statement and solution requirements for MIPv4 138 traversal across VPN gateways are articulated in [15]. To 139 understand the motivation and rationale for the solution proposed 140 in this draft, we strongly encourage the audience to read [15] 141 first. 143 This draft introduces a logical component called the Mobile IP 144 Proxy (MIP Proxy) to enable seamless Mobile IPv4 functionality 145 across VPN gateways, without requiring any IPsec VPN protocol 146 changes to VPN gateways. The solution aims specifically at 147 extending the use of deployed IPsec-based VPN gateways, a feature 148 that is much desired by corporate IT departments. The solution 149 also leverages [11] to support Mobile traversal across ôNAT and 150 VPNö gateways. The ôNAT and VPNö refers to a network topology 151 where Mobile IP traffic has to traverse one or more NAT gateway(s) 152 followed by a VPN gateway in the path to its final destination. 153 While the discussion in this draft is limited to IPsec-based VPN 154 gateways, it should be compatible with other IP-based VPN 155 solutions as well. 157 1.2. Goals 158 A MN whose home network is in a protected IP address space behind 159 a VPN gateway could roam to an external public or private address 160 space. An example would be a user who roams from within a 161 Corporate Intranet to an external wired or wireless hot spot. In 162 this case, the MNÆs HA is located in the Corporate Intranet 163 behind the firewall/DMZ complex (i.e, the HA is not directly 164 reachable by the MN), as illustrated in Figure 1.2. 166 It is desirable in this scenario to connect back to the Intranet 167 via a VPN while maintaining the transport connections prior to 168 the move, and stay connected as the user roams from one external 169 IP subnet to another outside the DMZ, or the user decides to roam 170 back inside the DMZ. 172 +----------------+ +-----+ +------+ +-----+ +---------------+ 173 |Foreign network | | | ->|VPN-GW|<---- | | |Home network | 174 |+----+ +----+ | |Outer| | +------+ | |Inner| | +----+ +----+ | 175 || MN | | FA | |--|FW |--| |--|FW |-| |HA | | CN | | 176 |+----+ +----+ | | | | +---------+ | | | | +----+ +----+ | 177 | | | | ->|MIP Proxy|<- | | | | 178 |+----+ | +-----+ +---------+ +-----+ | +----+ | 179 ||NAT | | ^ ^ | | MN | | 180 |+----+ | |----- Firewall/DMZ ----- | | +----+ | 181 +----------------+ +---------------+ 183 Figure 1.2 û MN moves from its home network to a foreign network 184 outside the DMZ 186 1.3. Problem Description 188 With respect to Figure 1.2 above, the problem can be summarized 189 in the following 3 scenarios: 191 Scenario 1: The MN could roam into a foreign subnet without a FA 192 and obtain a COA at its point of attachment (via DHCP or other 193 means). In an end-to-end security model, an IPsec tunnel that 194 terminates at the VPN gateway in the DMZ MUST protect the IP 195 traffic originating at the MN. If the IPsec tunnel is associated 196 with the COA, the tunnel SA MUST be refreshed after each subnet 197 handoff which could have undesirable performance implications on 198 real-time applications. 200 Scenario 2: The MN could roam into a foreign subnet with a FA. If 201 the MN were to associate a VPN tunnel with its COA, the FA (which 202 is likely in a different administrative domain) cannot parse the 203 IPsec and will not be able to setup SAs with the MNÆs VPN gateway 204 and will consequently not be able to relay MIPv4 packets between 205 the MN and the VPN gateway. 207 Scenario 3: The MN could roam into a NATÆed network that may or 208 may not employ a FA. In this scenario, the MIPv4 traffic has to 209 traverse a NAT followed by a VPN gateway. The problem statement 210 and solution for MIPv4 traversal across NAT gateways is 211 articulated in [11]. 213 1.4. Solution Overview 215 The solution introduces a new Mobile IP logical entity, called 216 Mobile IP Proxy (MIP Proxy). With respect to Figure 1.2 above, 217 the MIP Proxy is placed in the DMZ, co-located or running in 218 parallel with the VPN. The MIP Proxy is in the path between a MN 219 outside the DMZ and its corresponding actual HA. 221 The MIP Proxy serves two primary functions: that of a surrogate 222 MN and a surrogate HA to essentially ôstitchö an end-to-end 223 connection between the MN and its actual HA. A single MIP Proxy 224 can serve multiple MNs and HAs and can consequently be associated 225 with multiple home subnets. The MIP Proxy does not replace any 226 existing HAs. The MIP Proxy SHOULD belong to the same 227 administrative domain as any of its associated home agents and 228 their corresponding MNs. It MUST share SAs for various MIPv4 229 registration extensions with its associated HA(s). 231 The MIP Proxy will nominally run on a dual-homed host - one of 232 its interfaces on the private (LAN) side, and the other on the 233 public (WAN) side. The MIP Proxy can be instantiated on a singly 234 homed host - however in this document we assume that the MIP 235 Proxy is instantiated on a dual-homed host. The MIP Proxy MAY be 236 implemented as a standalone device or combined with a VPN 237 gateway. 239 1.4.1. Assumptions and Applicability 241 The solution is derived based on the following assumptions and 242 applicability criteria: 244 - An end-to-end IPsec tunnel mode MUST be applied to MIPv4 data 245 flows; i.e. between the MN and the VPN gateway at the edge of 246 its home network. 248 - MIPv4 registration packets MAY NOT require an IPsec tunnel as 249 they are authenticated and integrity protected. However, they 250 MUST be terminated inside the DMZ to enable authenticated 251 firewall traversal. 253 - The DMZ outer firewall MUST allow inbound tunneled IP packets 254 destined to the MIP Proxy. 256 - The DMZ outer firewall MUST permit inbound UDP registration 257 packets (destination port = 434 and destination address = MIP 258 Proxy interface on the public (WAN) side). 260 - The DMZ inner firewall MUST permit the forwarding of 261 registration request and reply messages from the MIP Proxy to 262 one or more HAs. 264 1.5. Terminology 266 Administrative Domain: 267 In the context of this draft an administrative domain is the 268 entity that specifies security parameters for Mobile IP 269 registration extensions for one or more Home Agents and their 270 corresponding mobile nodes. The administrative domain also 271 manages policies that govern negotiation of security associations 272 for VPN sessions that terminate or initiate at the edge of the 273 network under its jurisdiction. 275 Actual Home Agent: 276 It is the mobile nodeÆs real home agent, as defined by [1]. 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 279 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 280 "OPTIONAL" in this draft are to be interpreted as described in 281 [5]. 283 1.6. Acronyms 285 DMZ: De-Militarized Zone 286 FA-COA: Foreign Agent care-of address 287 FA-Routed: FAÆs interface address on the routed network 288 FA-Visited: FAÆs interface address on the visited network 289 GRE: Generic Routing Encapsulation 290 IP-D: IP Destination Address 291 IP-S: IP source Address 292 ISP: Internet Service provider 293 MIPv4: Mobile IP for IPv4 294 MIPv6: Mobile IP for IPv6 295 MN-COA: Co-located care-of address of the MN 296 MN-Perm: Permanent home address of the MN 297 MIPP-Priv: MIP Proxy interface address on the private (HA) side 298 MIPP-Pub: MIP Proxy interface address on the public (Internet) 299 side 300 NAT: Network Address Translation 301 NATGW-Priv: NAT gatewayÆs IP address on the private (LAN) side 302 NATGW-Pub: NAT gatewayÆs IP address on the public (WAN) side 303 VPNGW-Priv: VPN Gateway Private/Intranet IP Address 304 VPNGW-Pub: VPN Gateway Public/External IP Address 306 2. Registration 308 The MN roaming outside the DMZ sends MIPv4 registration requests 309 directly to the MIP Proxy. The registration messages are not 310 protected by an IPsec tunnel, and MUST be excluded from the tunnel 311 SA applied to flows between the MN and any correspondent hosts via 312 the VPN gateway. The MIP Proxy terminates and authenticates the 313 registration requests. It then generates a new registration 314 request and forwards it to the corresponding actual HA. The 315 registration replies from the actual HA will also go through the 316 MIP Proxy bypassing the VPN gateway. 318 A railroad diagram illustrating the MIPv4 registration process is 319 shown below. 321 MN MIP Proxy HA 322 |Reg. Request | | 323 |-------------> | | 324 | |Reg. Request | 325 | |-------------> | 326 | |Reg. Reply | 327 | |<------------- | 328 |Reg. Reply | | 329 |<--------------| | 331 Figure 2. û Mobile IP registration protocol between 332 MN and HA 334 2.1. Authentication 336 Each MN and the MIP proxy MUST share the SA for the MN-HA 337 authentication extension. The MIP Proxy MUST authenticate 338 received Registration Requests or Replies before processing them. 339 The mechanisms to share SAs are beyond the current scope of this 340 draft. 2.2. Registration Request Process 342 The MIP Proxy MUST relay all valid Registration Requests received 343 from a MN to its actual HA, after updating its pending 344 registration request list. Here, relaying means that the MIP 345 Proxy creates a new Registration Request on the behalf of the MN 346 and sends it to the MNÆs actual HA. The MIP Proxy MUST be 347 compliant with [1], and it MUST adhere to the rules specified in 348 the following sub-sections in creating the new Registration 349 Request. 351 2.2.1. Registration Request Bits 353 - The new Registration Request header MAY have the same æMÆ, 354 æGÆ, rsv bit values included in the Registration Request 355 received from the MN. 357 - The æBÆ bit in new Registration Request header MUST be set 358 ifthe æBÆ bit in the Registration Request received from the MN 359 is set and the MIP Proxy supports broadcast. 361 - The æDÆ bit in the new Registration Request MUST NOT be set, 362 if the æBÆ bit is set. Although the surrogate MN side of the 363 MIP Proxy always uses a co-located care-of address (i.e, MIPP- 364 Priv), this restriction is enforced to cause the actual HA to 365 encapsulate a broadcast or a multicast IP datagram in a unicast 366 datagram addressed to the MNÆs home address, and then tunnel 367 this encapsulated datagram to the MIP Proxy (i.e, MIPP-Priv). 368 Otherwise, the MIP Proxy will not be able to route the 369 broadcast or multicast IP datagrams received from the HA(s), as 370 it cannot determine to which MN the packet should be routed. 372 - The æTÆ bit in the new Registration Request MUST be set, if 373 the MIP Proxy may route the MIPv4 data traffic received from 374 the MN to CN in reverse tunneling mode. 376 - The new Registration Request MUST NOT set the æSÆ bit, as the 377 actual HA will always have the same care-of address (MIPP-Priv) 378 for all its MNs roaming outside the DMZ. Please see section 379 2.7.1. for more details. 381 2.2.2. Registration Request Fields 383 - The new Registration Request header MUST have equal or 384 smaller lifetime value included in the registration request 385 received from the MN. 387 - The new Registration Request header MUST have the same 388 identification value included in the Registration Request 389 received from the MN. 391 - The new Registration Request header MUST have the same Home 392 Address value included in the Registration Request received 393 from the MN. 395 - The new Registration Request headerÆs HA address field MUST 396 be set to the MNÆs actual HA address. 398 - The new Registration Request headerÆs care-of address field 399 MUST be set to MIPP-Priv. 401 2.2.3. Registration Request Extensions 403 - The new Registration Request MUST contain all Registration 404 extensions included in the Registration Request received from 405 the MN, with the exception of the ones specific to the MN and 406 the MIP Proxy protocol negotiation and the authentication 407 extension protecting the registration message between the MN 408 and the MIP Proxy. 410 - The new Registration Request MUST include the MN-HA 411 authentication extension. 413 2.2.4. Registration Request Validity Check 415 When a Registration Request is received from a MN, the MIP 416 proxy MUST validate the registration request and respond to a 417 malformed registration request as a HA would, as specified in 418 [1]. In addition, the MIP proxy MUST also check the 419 Registration Request for the following: 421 - The æTÆ bit MUST be set in the Registration Request. If not, 422 the MIP Proxy MUST return a Registration Reply to the MN with 423 an appropriate error code specified in[2]. 425 - The MIP proxy MUST check for the existence of the HA 426 Parameter extension, specified in section 2.6.3. In the absence 427 of a valid HA Parameter extension, the MIP proxy MUST return a 428 Registration Reply to the MN with an appropriate error code 429 specified in section 2.4.1 if MIP Proxy cannot determine an 430 appropriate HA to service the MN. 432 2.3. Registration Reply Process 434 The MIP proxy MUST relay Registration Replies received from 435 actual HAs to appropriate MNs. Here, relaying means that the MIP 436 Proxy creates a new Registration Reply on the behalf of the MNÆs 437 actual HA and sends it to the MN. The MIP proxy MUST update its 438 record of mobility bindings associated with a MN, before relaying 439 the registration reply to the MN. 441 In processing a registration reply, the MIP proxy MUST be 442 compliant with [1]. And, it MUST adhere to the rules specified in 443 the following sub-sections. 445 2.3.1. Registration Reply Fields 447 - The new Registration Reply header MUST have the same Code 448 value as in the Registration Reply received from the MNÆs 449 actual HA, except when MIP Proxy received accepted Registration 450 Reply from the actual HA but cannot service the MN (eg. create 451 mobility binding, route, tunnel). In this case, insufficient 452 resource (133) error code should be set in the Registration 453 Reply to the MN. 455 - The new Registration Reply header MUST have the same lifetime 456 value as in the Registration Reply received from the MNÆs 457 actual HA. If the lifetime value is zero, the MIP Proxy should 458 also retire the entry/entries in its mobility-binding list for 459 the MN, as specified in [1]. 461 - The new Registration Reply header MUST have the same Home 462 Address value as in the Registration Reply received from the 463 MNÆs actual HA. 465 - The new Registration Reply headerÆs Home Agent address field 466 MUST be set to MIPP-Pub. 468 - The new Registration Reply header MUST have the same 469 identification value as the Registration Reply received from 470 the MNÆs actual HA. 472 - The new Registration Reply MUST contain all non- 473 authentication extensions included in the Registration Reply 474 received from the MNÆs actual HA. 476 - The new Registration Reply MUST include the ôMN-HAö 477 authentication extension. 479 - The new Registration Reply MAY include the ôFA-HAö 480 authentication extension, as needed. 482 2.4. Registration Reply Initiated by the MIP Proxy 484 The MIP proxy MAY deny a Registration Request for various 485 reasons. If so, the MIP Proxy MUST use an appropriate 486 registration denied code, specified in the following section. 488 2.4.1. New Registration Reply Codes 490 The following values are defined for use within the Code field. 492 Registration denied by the MIP Proxy: 494 200 missing HA Parameter extension 495 201 non zero HA address Required in HA Parameter extension 496 202 home agent unreachable (when ICMP unreachable received) 497 203 MISSING-NAI 498 204 MISSING-HOMEADDR 499 205 MISSING-HOME-AGENT 500 206 ASSIGNED-HOME-AGENT 502 2.5. Mobile Node Considerations 504 2.5.1. Location Detection 506 Location detection is done by MIP Proxy and MN is aware of its 507 location as per the response from MIP Proxy. Please see 508 section 2.6.1 for more details. 510 2.5.2. New Configuration Requirement 512 A mobile node MUST be configured with the MIPP-Pub, unless 513 dynamic MIPP-Pub discovery is used, which is outside the scope 514 of this draft. 516 2.5.3. HA Parameter Extension 518 When a MN registers with the MIP Proxy, it MUST include the 519 non-skippable HA Parameter extension. This extension is used 520 to indicate the IP address of the actual HA to the MIP Proxy. 521 HA address in the extension MAY be set to zero, to request 522 dynamic HA assignment û please see section 2.7.3. for more 523 details. 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type | Length | Sub-Type |Reserved | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Home Agent Address | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Type : To be assigned by IANA (non-skippable) 533 Length : 534 Indicates the length (in bytes) of the data fields 535 within the extension, excluding the Type and Length 536 bytes. 537 Sub-Type: To be assigned by IANA 538 Reserved: For future use. 539 Home Agent Address: IP address of the MNÆs actual HA 541 2.6. MIP Proxy Considerations 543 2.6.1. Algorithm for location detection 545 MN always communicates to the MIP Proxy (public address), 546 whether on internal or external network. MIP Proxy detects 547 location of MN either by 1) care-of address in the 548 Registration Request or source address if MN registers using 549 NAT traversal or 2) inside or outside interface receiving the 550 Registration Request. 552 As per #1 above, MIP Proxy does location detection based on 553 care-of-address in Registration Request. Internal addresses 554 (enterprise private and public addresses) are known at the 555 MIP Proxy and so MIP Proxy can determine if the care-of- 556 address is internal. If the Registration Request from MN 557 indicates NAT traversal (mismatch of source and care-of- 558 address), MIP Proxy uses the source address to determine the 559 location of MN. 561 If the network design can guarantee that internal traffic 562 reaches the MIP Proxy on internal interface and external 563 traffic reaches the MIP Proxy on external interface, then the 564 MIP Proxy can interpret the MNÆs location based on the 565 interface on which it receives Registration Request, as 566 mentioned in #2 above. 568 Regardless of location detection algorithm, if the 569 Registration Request originates from external network, MIP 570 Proxy forwards the Registration Request to the appropriate 571 HA. If the Registration Request originates from internal 572 network, MIP Proxy rejects the Registration Request with 573 error code 206. This informs MN to use the HA address 574 specified in HA Parameter Extension. 576 If MN is registering using dynamic HA assignment (HA address 577 in HA Parameter Extension set to zero) and if MN is 578 registering from internal network, MIP Proxy selects the home 579 agent and puts that address in home agent field in HA 580 Parameter Extension in Registration Reply with error code 581 206. If MN is registering using dynamic HA assignment from 582 external network, HA includes the home agent address in HA 583 Parameter Extension in Registration Reply (if successful). 585 If MN receives a Registration Reply with code set to 206, MN 586 interprets as being in internal network and registers 587 directly with the home agent. If MN is behind NAT in internal 588 network, it will register with the specified home agent using 589 UDP tunnel extension. The home agent in this case SHOULD 590 support NAT traversal. 592 When MN re-registers due to a change in care-of-address, MN 593 always registers with the MIP Proxy and includes the HA 594 Parameter extension. If MN is just renewing its registration, 595 MN registers with HA or MIP Proxy, the entity with which it 596 last registered. 598 HA Parameter Extension is always present in both Registration 599 Request and Registration Reply. 601 2.6.2. Simultaneous Mobility Binding 603 The MIP proxy MAY support simultaneous mobility bindings, 604 regardless of if a MNÆs actual HA supports this feature or not. 606 When a Registration Request with an æSÆ bit set (i.e. 607 simultaneous binding requested by a MN) is received, the MIP 608 proxy MUST NOT set the æSÆ bit in the new Registration Request, 609 whether or not it support simultaneous mobility bindings. 611 If the MIP Proxy supports simultaneous bindings and it receives 612 a Registration Request with an æSÆ set, it MUST set the 613 lifetime value in the relayed Registration Request to the 614 maximum of the remaining lifetime values of all existing 615 mobility bindings for this MN and the lifetime value of the new 616 Registration Request received from the MN. Any subsequent 617 Registration Request refreshes received for any of the existing 618 simultaneous mobility bindings MUST follow the same rule with 619 respect to setting the lifetime value in the Registration 620 Request to be relayed to the MNÆs actual home agent. 622 When the Registration Reply is received from the MNÆs actual 623 HA, the lifetime value in the mobility bindings list for this 624 MN MUST be set to the lesser value of the accepted lifetime 625 (reflected in the Registration Reply) and the existing lifetime 626 (the request lifetime through the Registration Request) in the 627 mobility bindings list of the MIP proxy. 629 If the MIP Proxy does not support simultaneous bindings and it 630 receives a Registration with an æSÆ bit set, it MUST send a 631 Registration Reply to the MN as specified in[1]. 633 2.6.3. Mobile IP NAI Extension 635 The MIP proxy MAY support the Mobile IP NAI extension, 636 specified in [14]. 638 If the MIP Proxy receives a Registration Request whose Home 639 Address is zero and includes the Mobile IP NAI extension, it 640 MUST use NAI instead in its pending registration request list. 641 If the Registration Reply has a non-zero Home Address and 642 includes the Mobile IP NAI extension, the MIP Proxy MUST update 643 its mobility bindings list for this MN, and relay the 644 Registration Reply to the MN. 646 The MIP Proxy MUST do the following validity checks, if it 647 supports the Mobile IP NAI extension. 649 - If Home Address is zero in the Registration Request and the 650 MIP Proxy does not support the Mobile IP NAI extension, the MIP 651 Proxy MUST silently discard the Request since there is no SA. 653 - If the MIP Proxy receives a Registration Request with a value 654 of zero in the Home Address field and no NAI extension, it MUST 655 silently discard the Request since there is no SA. 657 - If the Registration Reply from the MNÆs actual HA does not 658 include the Mobile Node NAI extension, the MIP proxy SHOULD 659 send the Registration Reply to the mobile node with an error 660 code indicating MISSING-NAI, as defined in section 2.4.1. 662 - If the Registration Reply from the MNÆs actual HA includes a 663 zero Home Address or zero Home Agent address, the MIP proxy 664 SHOULD send the Registration Reply to the mobile node with an 665 error code indicating MISSING-HOMEADDR or MISSING-HOME-AGENT, 666 as defined in section 2.4.1. 668 2.6.4. Dynamic HA Assignment 670 The MIP proxy MAY support dynamic HA assignment in conjunction 671 with dynamic home address assignment for a MN. If the MN sends 672 a Registration Request with the Home Agent field set to zero in 673 the HA Parameter extension and includes a valid NAI extension, 674 the MIP Proxy can dynamically assign a HA from a pool of HA IP 675 addresses. The selection of a HA is beyond the scope of this 676 draft. The selected HA MUST support the NAI extension in the 677 Registration Request. However, this scheme is NOT intended to 678 support dynamic HA handovers. 680 2.6.5. Pending Registration List 681 For each pending registration, the MIP Proxy maintains the 682 following information: 684 - The IP destination address of the actual HA 685 - The care-of address in the received Registration Request 686 - The identification in the received Registration Request 687 - The lifetime in the received Registration Request, and 688 - The remaining Lifetime of the pending registration 690 2.6.6. Mobility Bindings 692 The MIP Proxy MUST maintain a mobility binding list similar to 693 the one specified in [1] for a HA, in order to forward the 694 registration replies and subsequent MIPv4 data traffic. The MIP 695 Proxy updates its binding table, when a successful Registration 696 Reply is received from an actual HA. 698 For each mobility binding entry, the MIP Proxy maintains the 699 following information: 701 - The IP destination address of the actual HA 702 - The home address of the MN 703 - NAI if in the received Registration Request 704 - The care-of address in the received Registration Request 705 - The identification in the received Registration Request 706 - The lifetime in the received Registration Request, and 708 The MIP Proxy MUST also use the same methods defined in [1] for 709 deleting or retiring the entries in its mobility-binding 710 list(s). 712 2.6.7. Handling ICMP Error Messages 714 When the MIP Proxy sends a Registration Request to an actual HA 715 on the behalf of a MN, it may receive an ICMP error message 716 indicating that the actual HA is not reachable for a specific 717 reason (i.e., network unreachable, host unreachable, port 718 unreachable, protocol unreachable). If so, the MIP Proxy MUST 719 send a Registration Reply to the MN with Code indicating why 720 the actual HA was not reachable. 722 2.7. MIPv4 Registration Packet Flow 724 2.7.1. MIPv4 Registration Request Packet Flow from MN to HA 726 This draft illustrates the sequence from MN to HA via a FA û it 727 can be easily extended to describe the flow for a co-located 728 COA mode MN. 730 From the MN to a FA: 731 +--------------------------------------------------+ 732 |IP-S = MN-Perm | Permanent Address = MN-Perm | 733 |IP-D = FA-Visited| Home Agent = MIPP-Pub | 734 | | Care-of Address = FA-COA | 735 | | . . . | 736 +--------------------------------------------------+ 738 From the FA to the MIP Proxy: 739 +--------------------------------------------------+ 740 |IP-S = FA-Routed | Permanent Address = MN-Perm | 741 |IP-D = MIPP-Pub | Home Agent = MIPP-Pub | 742 | | Care-of Address = FA-COA | 743 | | . . . | 744 +--------------------------------------------------+ 745 From the MIP Proxy to the actual HA: 746 +--------------------------------------------------+ 747 |IP-S = MIPP-Priv | Permanent Address = MN-Perm | 748 |IP-D = HA | Home Agent = HA | 749 | | Care-of Address = MIPP-Priv | 750 | | | 751 +--------------------------------------------------+ 753 2.7.2. MIPv4 Registration Reply Packet Flow from HA to MN 755 If the actual HA were to accept the registration request, the 756 reply flow sequence will be as follows: 758 From the HA to the MIP Proxy: 759 +--------------------------------------+ 760 |IP-S = HA | Home Agent = HA | 761 |IP-D = MIPP-Priv | | 762 +--------------------------------------+ 764 From the MIP Proxy to the FA: 765 +-----------------------------------------------+ 766 |IP-S = MIPP-Pub | Home Agent = MIPP-Pub | 767 |IP-D = FA-Routed | . . . | 768 +-----------------------------------------------+ 770 From the FA to the MN: 771 +-----------------------------------------------+ 772 |IP-S = FA-Visited| Home Agent = MIPP-Pub | 773 |IP-D = MN-Perm | . . . | 774 +-----------------------------------------------+ 776 3. Functions Not Performed By The MIP Proxy 778 The MIP Proxy MUST NOT perform the following HA functions, as 779 defined in [1]: 781 - It MUST NOT generate agent advertisements 782 - It MUST NOT send gratuitous ARPs 783 - It MUST NOT perform Proxy ARP 784 - It MUST NOT support Route Optimization [10] 786 The MIP proxy MUST NOT perform the following MN functions, as 787 specified by [1]: 789 - It MUST NOT generate agent solicitations or functions pertaining 790 to agent discovery 791 - It MUST NOT implement any move detection mechanisms 792 - The MIP Proxy MUST NOT manage registration lifetimes and MUST 793 NOT reinitiate a registration request with the actual HA prior to 794 its expiration. 796 4. MIP Proxy Integration with VPN 798 The MIP Proxy as described in this draft is a logical functional 799 entity and as such can be integrated with VPN in 2 possible ways, 800 which are one-box and two-box solutions. 802 4.1. One-Box Integration 804 Integrated as a software component with the VPN gateway. This 805 clearly reduces the communication overhead but tightly couples 806 support for MIPv4 users with any software upgrades to the VPN 807 gateway itself. Figure 4.1. depicts a network stack resulted 808 from the one-box integration of the MIP proxy with the VPN 809 gateway. Please note that IPsec and the MIP Proxy layers can be 810 combined into one layer (tightly coupled integration), or they 811 can be layered as shown in figure 4.1. (loosely coupled 812 integration). 814 +------------+ 815 | TCP/IP | 816 +------------+ 817 | IPsec | 818 +------------+ 819 | MIP Proxy | 820 +------------+ 821 | Link Layer | 822 +------------+ 823 | Physical | 824 | Layer | 825 +------------+ 827 Figure 4.1. û One-Box Integration of MIP Proxy with VPN 829 4.1.1. Redundancy 831 A MIP Proxy redundancy protocol is desirable to effect high 832 availability in public and Enterprise deployments, when two box 833 solution approach is used. Details of such a protocol are 834 beyond the current scope of this draft. 836 4.2. Two-Box Integration 838 Implemented as a standalone device deployed in parallel with the 839 VPN gateway as depicted in Figure 1.2. This decouples support for 840 MIPv4 users from any software or hardware upgrades to the VPN 841 gateway itself and also enables multi-vendor interoperability. 842 The scheme however adds some overhead to the end-to-end 843 communication path between a MN and a CN. 845 4.2.1. Two-Box Integration Requirements 847 - It MUST be possible to configure the VPN gatewayÆs routing 848 table to deliver the outbound IPsecÆed MIPv4 packets destined 849 to MN-Perm to the MIP ProxyÆs MIP-Pub interface. 851 - The MIP Proxy MUST be able to forward packets (destined to 852 MN) to VPN gateway via layer 2 mechanism. This implies that 853 the MIP Proxy and VPN Gateway MUST be on the same subnet. 855 5. MIPv4 Data Traffic Routing Through VPN 857 This section describes MIPv4 data traffic flow through VPN with 858 the aid of the MIP Proxy. For clarity, this section assumes a 859 two-box solution approach. 861 5.1. Establishment of Secured MIPv4 Traffic 863 There are two steps that MUST be successfully completed in order 864 to establish secured MIPv4 traffic between a MN and a CN. 866 The first step is that the MN MUST complete MIPv4 registration 867 with its actual home agent through the MIP Proxy, as discussed in 868 section 2. The second step is that the MN MUST establish IPsec 869 tunnel SA to the VPN gateway through the MIP Proxy, as shown in 870 Figure 3.a. Any subsequent registration and SA refreshes may 871 occur independent of each other. 873 MN MIP Proxy VPN Gateway 874 | IKE-Phase 1/MIPv4 | 875 | --------------> | IKE-phase 1 | 876 | |-----------------> | 877 | | IKE-phase 2 | 878 | IKE-Phase 2/MIPv4|<-------------------| 879 | <---------------- | | 881 Figure 3.a û IPsec Tunnel SA Establishment 882 (Two Box Solution) 884 The data forwarding is described in the following 2 sub-sections. 886 5.2. Association Between VPN Inner and MN Home IP Address 887 To support continuous mobility and constant reachability, the 888 tunnel inner IP address assigned to a MN MUST be the same as the 889 home IP address. 891 5.3. MIPv4 Data Traffic from MN on External Network to CN 893 The MN generates an IP packet from the MN-Perm interface and 894 destined to the CN. This packet is encapsulated in an IPsec-ESP 895 tunnel from MN-Perm to VPNGW-Pub. The packet in turn is 896 encapsulated in an IP header from MN-COA or FA-COA to the MIP 897 Proxy. The MIP Proxy strips off the outermost IP header and 898 forwards the inner IP packet (which is from the MNÆs permanent 899 address to the VPN gateway) to the VPN gateway. The VPN gateway 900 in turn processes the IPsec VPN tunnel, strips off the IP and ESP 901 headers and forwards the inner most IP packet to the destination 902 CN. The MIP Proxy MUST perform the following validity checks on 903 received MIP data packets whose destination IP address is set to 904 MIPP-Pub (i.e., packets received from outside the DMZ). 906 - The received packet MUST be encapsulated by an appropriate 907 method (e.g., IP-in-IP, Minimal Encapsulation, GRE) that the 908 MIP Proxy supports 909 - The inner IP packetÆs destination IP address MUST be set to 910 a VPN gateway IP address that the MIP Proxy supports 911 - An ESP header MUST follow the inner IP header 913 If any of above validity checks fail, then the MIP Proxy MUST 914 silently drop the packet. 916 The packet routing from the MIP Proxy to the CN may differ 917 depending on whether the CN belongs to any of ômobility subnetsö 918 that the MIP Proxy supports. The following railroad diagrams 919 depict the packet flow sequence for both cases, followed by a 920 description of packets as they traverse the network. 922 MN FA MIP Proxy VPN Gateway HA CN 923 | | | | | | 924 | ----> | | | | | 925 | | -----> | | | | 926 | | | ------------> | | | 927 | | | | -----------------> | 929 Figure 5.2a û Packet flow from MN to CN, where the CN does not 930 belong to any of ôMobility subnetsö that the MIP Proxy supports 932 From the MN to FA: IP-ESP-IP-Data 933 From the FA to MIP Proxy: IP-IP-ESP-IP-Data 934 From MIP Proxy to VPN: IP-ESP-IP-Data 935 From VPN Gateway to CN: IP-Data 936 MN FA MIP Proxy VPN Gateway HA CN 937 | | | | | | 938 | ----> | | | | | 939 | | -----> | | | | 940 | | | ------------> | | | 941 | | | <----------- | | | 942 | | | -------------------------->| | 943 | | | | |-------->| 944 | | | OR | 945 | | |-----------------------------------> | 947 Figure 5.2b û Packet flow from MN to CN, where the CN belongs to 948 a ôMobility subnetö that the MIP Proxy supports 950 From the MN to FA: IP-ESP-IP-Data 951 From the FA to MIP Proxy: IP-IP-ESP-IP-Data 952 From MIP Proxy to VPN: IP-ESP-IP-Data 953 From VPN Gateway to MIP Proxy: IP-Data 954 (forwarded back to the MIP Proxy using via Network route 955 installed on the VPN gateway) 957 Reverse tunneling delivery method is used: 958 ------------------------------------------ 959 From MIP Proxy to HA: IP-IP-Data 960 From HA to CN: IP-Data 962 Non-Reverse Tunneling delivery method is used: 963 ---------------------------------------------- 964 From MIP Proxy to CN: IP-Data 966 The packet flow analysis from the MN to the CN is described 967 below. The analysis assumes that the CN does not belong to any 968 ômobility subnetsö that the MIP Proxy supports. 970 From the MN to the FA: 971 +------------------------------------------------+ 972 | IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 973 | IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 974 | |VPNGW-Pub | | | 975 +------------------------------------------------+ 976 In this case, the layer-2 destination address is set to the MAC 977 address of the FA. 979 From the FA to the MIP Proxy: 980 +--------------------------------------------------------------+ 981 |IP-S=FA-Routed|IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 982 |IP-D=MIPP-Pub |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 983 | | |VPNGW-Pub | | | 984 +--------------------------------------------------------------+ 985 Clearly, the FA does not need to know the IPsec tunnel SA to 986 process the packet. FA only reverse tunnel traffic to the MIP 987 Proxy. 989 From the MIP Proxy to the VPN gateway: 990 The MIP Proxy strips off the outermost IP header and forwards the 991 packet (whose destination address is set to VPNGW-Pub) to the VPN 992 gateway. 993 +-----------------------------------------------+ 994 |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 995 |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 996 | |VPNGW-Pub | | | 997 +-----------------------------------------------+ 999 From the VPN gateway to the CN: 1000 The VPN gateway completes IPsec tunnel processing on the packet, 1001 strips off the outermost IP and ESP headers and forwards the 1002 original IP datagram to the CN. 1004 +---------------------+ 1005 |IP-S=MN-Perm| Data | 1006 |IP-D=CN | | 1007 +---------------------+ 1009 5.4. MIPv4 Data Traffic from CN to MN on External Network 1011 The outbound MIPv4 data traffic destined to the MNÆs co-located 1012 address is always tunneled to the MIP Proxy (which appears as a 1013 surrogate MN to the actual HA). The MIP Proxy forwards the inner 1014 IP packet (with MN-Perm as the destination address) to the VPN 1015 gateway. The VPN gateway applies the IPsec ESP tunnel SA on the 1016 packet. The VPN gateway forwards the packet back to the MIP Proxy 1017 on its MIPP-Pub interface û this is accomplished by a routing 1018 table update on the VPN gateway. The MIP Proxy in turn tunnels 1019 the IPsecÆed packet to the MNÆs COA. The railroad diagram 1020 depicts the packet flow sequence, followed by a description of 1021 packets as they traverse the network. 1023 MN FA MIP Proxy VPN Gateway HA CN 1024 | | | | | | 1025 | | | | | <------ | 1026 | | | <------------------------- | | 1027 | | | -----------> | | | 1028 | | | <----------- | | | 1029 | | <------ | | | | 1030 | <--- | | | | | 1032 From CN to the HA: IP-Data 1033 From the HA to the MIP Proxy: IP-IP-Data 1034 From the MIP Proxy to the VPN gateway: IP-Data 1035 From the VPN gateway to the MIP Proxy: IP-ESP-IP-Data 1036 From the MIP Proxy to the FA: IP-IP-ESP-IP-Data 1037 From the FA to the MN: IP-ESP-IP-Data 1038 The packet flow from the CN to the MN is described below. 1039 From the CN to the actual HA: 1040 +---------------------+ 1041 |IP-S=CN | Data | 1042 |IP-D=MN-Perm| | 1043 +---------------------+ 1045 The packet is intercepted by the actual HA, as the MN has moved 1046 outside its home subnet. 1048 From the actual HA to the MIP Proxy: 1050 +------------------------------------+ 1051 |IP-S=HA |IP-S=CN | Data | 1052 |IP-D=MIPP-Priv|IP-D=MN-Perm| | 1053 +------------------------------------+ 1055 From the MIP Proxy to the VPN gateway: 1056 The MIP Proxy strips off the outermost IP header and forwards the 1057 packet to the VPNGW-Priv interface using the corresponding layer- 1058 2 address. 1060 +---------------------+ 1061 |IP-S=CN | Data | 1062 |IP-D=MN-Perm| | 1063 +---------------------+ 1065 From the VPN gateway to the MIP Proxy: 1066 The VPN gateway applies an IPsec ESP tunnel SA to the IP packet 1067 and forwards it back to the MIP Proxy on the MIPP-Pub interface 1068 based on its routing table. 1070 +-------------------------------------------------+ 1071 |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | 1072 |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1073 | |MN-Perm | | | 1074 +-------------------------------------------------+ 1076 From the MIP Proxy to the FA: 1077 The MIP Proxy adds an outer encapsulating IP header to the FA 1078 COA. 1079 +--------------------------------------------------------+ 1080 |IP-S=MIPP-Pub|IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data| 1081 |IP-D=FA-COA |IP-D=MN-Perm |VPNGW-Pub to|IP-D= | | 1082 | | |MN-Perm | MN-Perm| | 1083 +--------------------------------------------------------+ 1084 From the FA to the MN: 1085 The FA strips off the outermost IP header and forwards the packet 1086 to the MN. 1087 +-------------------------------------------------+ 1088 |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | 1089 |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1090 | |MN-Perm | | | 1091 +-------------------------------------------------+ 1093 The MN terminates the IPsec tunnel and processes the MIPv4 data 1094 as always. 1096 5.5. Key Management and SA Preservation 1098 The MIPv4 data traffic routing described in the previous section 1099 binds the IPsec tunnel SA to the normally invariant permanent 1100 (home) IP address of the MN. This implies that the tunnel SA can 1101 be preserved even when the MN changes its co-located COA or 1102 connects via a FA in a different IP subnet. The SA however must 1103 be refreshed prior to its lifetime expiration. Also, many VPN 1104 gateway implementations support some keep-alive mechanism to 1105 detect the presence of a VPN client and ôretireö the SA if the 1106 VPN client is not detected for a period of time. If a MN loses 1107 link connectivity for a period extending the keep-alive timeout 1108 interval, it MUST reestablish the tunnel SA, regardless of 1109 whether it reconnects to the same IP subnet or not. 1111 The scheme also preserves any secondary authentication mechanisms 1112 that may be in the place to authenticate a remote access user. 1114 5.6. Supporting Other IPsec-based VPN Configurations 1116 The scheme currently described in this draft assumes a native 1117 IPsec VPN scheme extended to support secondary authentication 1118 schemes. However the solution should apply to L2TP over IPsec 1119 transport [12] and ESP-in-UDP VPN [13] configurations as well. 1121 Note that ESP-in-UDP VPN is not necessary when Mobile IP UDP 1122 tunnels [11] are in use. 1124 5.7 Routing Considerations 1126 VPN gateway must insert a route for the home network(s) to point 1127 to the MIP Proxy. This route MUST not be redistributed via an 1128 IGP. 1130 On the MIP Proxy, packets that come from a MIP tunnel (on either 1131 the Public or Private interface) must be forwarded (via layer-two 1132 mechanism) to the VPN Gateway for IPSec tunnel 1133 encapsulation/decapsulation. 1135 5.7.1. Broadcast / multicast Datagrams 1136 When an actual HA receives a broadcast or a multicast datagram, 1137 it forwards the datagram to the MIP proxy for any qualified MNs 1138 outside the DMZ. 1140 Since the MIP proxy always unsets the æDÆ bit in a Registration 1141 Request that it sends to the actual HA on the behalf of the MN 1142 (see section 2.2.1), the actual home agent applies double 1143 encapsulation on broadcast or multicast packets that need to be 1144 forwarded to the MN, as specified in [1]. When the MIP Proxy 1145 receives the double encapsulated packets from an actual HA, it 1146 decapsulates the outer IP header, and then forwards the packet 1147 to the VPN as shown below. 1149 From Actual HA to the MIP Proxy: 1150 +--------------------------------------------------+ 1151 |IP-S=HA |IP-S=HA | IP-S=CN | Data | 1152 |IP-D=MIPP-Priv|IP-D=MN | IP-D=Bcast or | | 1153 | | | IP-D=Mcast | | 1154 +--------------------------------------------------+ 1156 From the MIP Proxy to VPN: 1157 +-----------------------------------+ 1158 |IP-S=HA | IP-S=CN | Data | 1159 |IP-D=MN | IP-D=Bcast or | | 1160 | | IP-D=Mcast | | 1161 +-----------------------------------+ 1163 5.7.2. MN Registration through a Trusted FA 1165 A MN may roam into a network served by a trusted FA. The 1166 trusted FA refers to a FA that has SA with the VPN-GW or a FA 1167 whose hosting network has SA with VPN-GW and an IPsec tunnel 1168 will be established between the FA or its hosting network and 1169 the VPN-GW while necessary to protect any traffic between. In 1170 this case, the MN MUST use the NAI extension in the FA route 1171 advertisement or other mechanisms which are out of the scope of 1172 this draft to determine that the FA is a trusted FA. The MN 1173 MUST not use the MIP Proxy in this scenario, the FA is 1174 responsible for properly tunneling the traffic including the 1175 MIP signaling and data through the VPN-GW. 1177 6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways 1179 This section extends MIPv4 VPN traversal solution described in 1180 section 5 to support MIPv4 traversal across ôNAT and VPNö 1181 scenario, in which MN has to traverse one or more NAT gateway(s) 1182 followed by a VPN gateway in the path to its final destination. 1184 A solution for MIPv4 traversal across intervening NAT gateways is 1185 provided in [11] through a MN/HA protocol extension. The solution 1186 cannot be directly applied here, since the MNÆs home agent is not 1187 directly reachable. However, the solution can be leveraged by 1188 simply corresponding the MIP Proxy surrogate HA to the HA in [11]. 1190 The following sub-sections show MIPv4 control and data packets 1191 flow between a MN and a CN. 1193 6.1. MIPv4 Registration Message Flow 1194 6.1.1. MIPv4 Registration Requests 1196 From the MN to the NAT gateway: 1197 +-----------------------------------------------+ 1198 |IP-S=MN-Perm | Permanent Address = MN-Perm | 1199 |IP-D=MIPP-Pub | Home Agent = MIPP-Pub | 1200 | | Care-of Address = MN-COA | 1201 | | . . . | 1202 +-----------------------------------------------+ 1203 Please refer to section 4.5 and the [11] draft for detailed 1204 discussion of required registration extensions. 1206 From the NAT gateway to the MIP Proxy: 1207 The NAT gateway performs source address and source UDP port 1208 translation before forwarding the packet to the MIP Proxy. 1210 +-----------------------------------------------+ 1211 |IP-S=NATGW-Pub | Permanent Address = MN-Perm | 1212 |IP-D=MIPP-Pub | Home Agent = MIPP-Pub | 1213 | | Care-of Address = MN-COA | 1214 | | . . . | 1215 +-----------------------------------------------+ 1217 From the MIP Proxy to the actual HA: 1218 The MIP Proxy terminates and authenticates the registration 1219 request (as described in previous sections). It then creates a 1220 new registration request and forwards it to the actual HA. 1222 +-----------------------------------------------+ 1223 |IP-S=MIPP_Priv | Permanent Address = MN-Perm | 1224 |IP-D=HA | Home Agent = HA | 1225 | | Care-of Address = MIPP-Priv | 1226 | | . . . | 1227 +-----------------------------------------------+ 1229 6.1.2. MIPv4 Registration Replies 1231 From the actual HA to the MIP Proxy: 1232 +-------------------------------------+ 1233 |IP-S=HA | Home Agent = HA | 1234 |IP-D=MIPP-Priv | . . . | 1235 +-------------------------------------+ 1237 From the MIP Proxy to the NAT gateway: 1238 +--------------------------------------+ 1239 |IP-S=MIPP-Pub | Home Agent = MIPP-Pub| 1240 |IP-D=NATGW-Pub | . . . | 1241 +--------------------------------------+ 1243 From the NAT gateway to the MN: 1244 +----------------------------------------+ 1245 |IP-S=MIPP-Pub | Home Agent = MIPP-Pub | 1246 |IP-D=MN COA | . . . | 1247 +----------------------------------------+ 1249 6.2. MIPv4 Data Flow 1251 6.2.1. Data Flow from the MN to the CN 1253 From MN to the NAT gateway: 1254 +--------------------------------------------------------+ 1255 |IP-S= | UDP|IP-S= |IPsec-ESP |IP-S=MN-Perm| Data | 1256 | MN-Priv | |MN-Perm | | | | 1257 |IP-D= | |IP-D= |MN-Perm to|IP-D=CN | | 1258 |MIPP-Pub | |VPNGW-Pub | VPNGW-Pub| | | 1259 +--------------------------------------------------------+ 1261 From the NAT gateway to the MIP Proxy: 1262 +----------------------------------------------------------+ 1263 |IP-S= | UDP |IP-S= |IPsec-ESP |IP-S=MN-Perm| Data | 1264 |NATGW-Pub | | MN-Perm | | | | 1265 |IP-D= | |IP-D= |MN-Perm to|IP-D=CN | | 1266 |MIPP-Pub | |VPNGW-Pub |VPNGW-Pub | | | 1267 +----------------------------------------------------------+ 1269 From the MIP Proxy to the VPN gateway: 1270 +-----------------------------------------------+ 1271 |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data | 1272 |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | | 1273 | |VPNGW-Pub | | | 1274 +-----------------------------------------------+ 1276 From the VPN gateway to the CN: 1277 +---------------------+ 1278 |IP-S=MN-Perm| Data | 1279 |IP-D=CN | | 1280 +---------------------+ 1282 6.2.2. Data Flow from the CN to the MN 1284 From the CN to the actual HA: 1285 +---------------------+ 1286 |IP-S=CN | Data | 1287 |IP-D=MN-Perm| | 1288 +---------------------+ 1289 From the actual HA to the MIP Proxy: 1290 +------------------------------------+ 1291 |IP-S=HA |IP-S=CN | Data | 1292 |IP-D=MIPP-Priv|IP-D=MN-Perm| | 1293 +------------------------------------+ 1295 From the MIP proxy to the VPN gateway: 1296 The MIP proxy strips off the outer IP header and forwards the 1297 packet on the layer-2 address for VPNGW-Priv. 1298 +---------------------+ 1299 |IP-S=CN | Data | 1300 |IP-D=MN-Perm| | 1301 +---------------------+ 1303 From the VPN gateway to the MIP Proxy: 1304 +-------------------------------------------------+ 1305 |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data | 1306 |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| | 1307 | |MN-Perm | | | 1308 +-------------------------------------------------+ 1310 From the MIP Proxy to the NAT gateway: 1311 +----------------------------------------------------------+ 1312 |IP-S= | UDP |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN| Data | 1313 |MIPP-Pub | | | | | | 1314 |IP-D= | |IP-D=NM-Perm |VPNGW-Pub to|IP-D= | | 1315 |NATGW-Pub| | | |MN-Perm| | 1316 | | | |MN-Perm | | | 1317 +----------------------------------------------------------+ 1319 From the NAT gateway to MN: 1320 +------------------------------------------------------------+ 1321 |IP-S= | UDP |IP-S= |IPsec-ESP |IP-S=CN |Data | 1322 |MIPP-Pub | |VPNGW-Pub | | | | 1323 |IP-D= | |IP-D= |VPNGW-Pub to|IP-D=MN-Perm| | 1324 |MN-Priv | |NM-Perm | MN-Perm | | | 1325 | | | | | | | 1326 +------------------------------------------------------------+ 1328 7. Security Implications 1330 The MIP Proxy is a functional entity that MUST be implemented on a 1331 secure device especially if it is deployed in the DMZ. The MIP 1332 Proxy is assumed to belong to the same (security) administrative 1333 domain as the MN and the actual HA. The protocol extensions 1334 specified in the draft do not introduce any new vulnerability to 1335 the mobile IP protocol. 1337 8. Acknowledgements 1338 The authors would like to thank Mike Andrews, Changwen Liu and 1339 Ranjit Narjala of Intel Corporation, Sami Vaarala of Netseal, 1340 Alexis Oliverean of Motorola for their review and feedback on this 1341 draft. 1343 9. Intellectual Property Rights 1345 Intel Corporation is in the process of filing one or more patent 1346 applications that may be relevant to this IETF draft. 1348 Cisco Systems is in the process of filing one or more patent 1349 applications that may be relevant to this IETF draft. 1351 10. Revision History 1353 1) Initial Version 1354 9/2001 1356 2) Second Version 3/2002 1357 + Modified the draft to meet requirements defined in 1358 [15] 1359 + General Clean up 1360 + Made changes to reflect comments/feedbacks from 1361 Sami Vaarala of Netseal, Qiang Zhang of 1362 Ecutel, Alexis Oliverean of Motorola 1364 11. References 1366 [1] Perkins. IP mobility support for IPv4. RFC 3220, January 2002 1367 [2] Montenegro. Reverse tunneling for mobile IP. RFC 3024, 1368 January 2001 1369 [3] Perkins. Minimal encapsulation within IP. RFC 2004, October 1370 1996 1371 [4] Hanks, Farinacci, Traina. Generic Routing encapsulation. RFC 1372 1701, October 1994 1373 [5] Bradner. Key words for use in RFCs to Indicate Requirement 1374 Levels. RFC 2119, March 1997 1375 [6] Rekhter, Moskowitz, Karrenberg. Address Allocation for Private 1376 Internets. RFC 1918, Feburary 1996 1377 [7] Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1378 1997 1379 [8] - Requirements / 1380 Implementation Guidelines for Mobile IP using IP Security 1381 [9] Cheshire, Aboba. Dynamic Configuration of IPv4 Link-Local 1382 Addresses. , April 2002 1383 [10] Perkins, Johnson. Route Optimization in Mobile IP. , September 2001 1385 [11] Levkowetz, Vaarala. Mobile IP NAT/NAPT Traversal using UDP 1386 Tunneling. , March 2002 1387 [12] Patel, Aboba, Zorn, Booth, RFC 3193 û Securing L2TP with 1388 IPsec 1389 [13] Huttunen , Dixon, Swander. UDP Encapsulation of IPsec Packets 1390 , April 2002 1392 [14] Calhoun, Perkins. Mobile IP Network Access Identifier 1393 Extension for IPv4. RFC 2794, March 2000 1394 [15] Adrangi, Leung, Kulkarni, Patel, Zhang, Lau. Problem 1395 Statement and Requirements for Mobile IPv4 Traversal Across VPN 1396 Gateways. , 1397 March 2002 1399 Authors: 1401 Farid Adrangi Email: farid.adrangi@intel.com 1402 Phone: 503-712-1791 1403 Prakash Iyer Email: prakash.iyer@intel.com 1404 Phone: 503-264-1815 1406 Intel Corporation 1407 2111 N.E. 25th Avenue 1408 Hillsboro, OR 97124 1409 USA 1411 Kent Leung Email: kleung@cisco.com Phone: 408-526-5030 1412 Milind Kulkarni Email: mkulkarn@cisco.com Phone: 408-527-8382 1413 Alpesh Patel Email: alpesh@cisco.com Phone: 408-853-9580 1415 Cisco Systems 1416 170 W. Tasman Drive, 1417 San Jose, CA 95134 1419 Qiang Zhang Email: qzhang@liqwidnet.com 1420 Phone:703 8641327 1421 Liqwid Networks Inc. 1423 Joe Lau Email: jlau@cup.hp.com Phone: 408 447-2159 1424 Hewlett-Packard Company 1425 19420 Homestead Road, MS 4301 1426 Cupertino, CA 95014