Network Working Group S. Vaarala (Ed.) Internet-Draft Netseal Expires: December 27, 2003 June 28, 2003 Mobile IPv4 Traversal Across IPsec-based VPN Gateways draft-ietf-mobileip-vpn-problem-solution-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 27, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document outlines the proposed solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec are not required. Vaarala (Ed.) Expires December 27, 2003 [Page 1] Internet-Draft MIPv4-VPN June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Terms and abbreviations . . . . . . . . . . . . . . . . . . 6 1.5 Requirement levels . . . . . . . . . . . . . . . . . . . . . 7 2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Access modes . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . . 12 3.4 Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . . 12 3.5 NAT traversal . . . . . . . . . . . . . . . . . . . . . . . 13 4. Internal network detection . . . . . . . . . . . . . . . . . 14 4.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Implementation requirements . . . . . . . . . . . . . . . . 15 4.2.1 Connection status change . . . . . . . . . . . . . . . . . . 15 4.2.2 Registration-based internal network detection . . . . . . . 16 4.2.3 Registration-based internal network monitoring . . . . . . . 16 4.2.4 Handling of network interfaces . . . . . . . . . . . . . . . 17 4.3 Proposed algorithm . . . . . . . . . . . . . . . . . . . . . 17 4.4 Implementation issues . . . . . . . . . . . . . . . . . . . 18 4.5 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5.1 Firewall configuration requirements . . . . . . . . . . . . 19 4.5.2 Registration-based internal network monitoring . . . . . . . 19 4.6 Improvements . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1 Mobile node requirements . . . . . . . . . . . . . . . . . . 21 5.2 VPN device requirements . . . . . . . . . . . . . . . . . . 21 5.3 Home agent requirements . . . . . . . . . . . . . . . . . . 21 6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1 Comparison against guidelines . . . . . . . . . . . . . . . 22 6.2 Packet overhead . . . . . . . . . . . . . . . . . . . . . . 23 6.3 Latency considerations . . . . . . . . . . . . . . . . . . . 24 6.4 Firewall state considerations . . . . . . . . . . . . . . . 25 6.5 Intrusion detection systems (IDSs) . . . . . . . . . . . . . 26 6.6 Implementation of mobile node . . . . . . . . . . . . . . . 26 6.7 Non-IPsec VPN protocols . . . . . . . . . . . . . . . . . . 26 6.8 Shortcomings for enterprise use . . . . . . . . . . . . . . 27 7. Security considerations . . . . . . . . . . . . . . . . . . 28 Vaarala (Ed.) Expires December 27, 2003 [Page 2] Internet-Draft MIPv4-VPN June 2003 7.1 Internal network detection . . . . . . . . . . . . . . . . . 28 7.2 Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . . 28 8. Intellectual property rights . . . . . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 References . . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . 33 A. Packet flow examples . . . . . . . . . . . . . . . . . . . . 34 A.1 Connection setup for access mode 'cvc' . . . . . . . . . . . 34 A.2 Connection setup for access mode 'fvc' . . . . . . . . . . . 38 B. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Full Copyright Statement . . . . . . . . . . . . . . . . . . 42 Vaarala (Ed.) Expires December 27, 2003 [Page 3] Internet-Draft MIPv4-VPN June 2003 1. Introduction The Mobile IP working group started a design team to explore the problem and solution spaces of IPsec and Mobile IP coexistence. The problem statement and solution requirements for Mobile IPv4 case was first documented in [2]. The design team then set out to evaluate solution candidates and ultimately arrive at a solution draft. The current version of this document outlines the proposed solution for IPv4. The solution places only requirements on the implementation of the mobile node. This document contains two parts: o a basic solution which is an applicability statement of Mobile IPv4 and IPsec to provide session mobility between internal and external networks, intended for enterprise mobile users; and o a technical specification and a set of requirements for secure detection of the internal and the external networks. 1.1 Overview Typical corporate networks consist of three different domains: the Internet (untrusted external network), the intranet (trusted internal network), and the DMZ, which connects the two networks. Access to the internal network is guarded both by a firewall and a VPN device; access is only allowed if both firewall and VPN security policies are respected. Enterprise mobile users benefit from unrestrained seamless session mobility between subnets, regardless of whether the subnets are part of the internal or the external network. Unfortunately the current Mobile IPv4 and IPsec standards alone do not provide such a service [12]. The proposed solution is to use standard Mobile IPv4 when the mobile node is in the internal network, and to use the inner address of a VPN tunnel (VPN-TIA) as a co-located care-of address for Mobile IPv4 registration when outside. IPsec-based VPN tunnels require re- negotiation after movement; thus, some additional mechanism must deal with mobility when the MN is outside. The external mobility is provided by another layer of Mobile IPv4 underneath IPsec, in effect making IPsec unaware of movement. Thus, the mobile node can freely move in the external network without disrupting the VPN connection. The downside of this approach is that Vaarala (Ed.) Expires December 27, 2003 [Page 4] Internet-Draft MIPv4-VPN June 2003 an external home agent is required, and that the packet overhead is considerable (see Section 6). Briefly, when outside, the mobile node: o detects (securely) that it is outside (Section 4); o registers its co-located or foreign agent care-of address with the external home agent; o establishes a VPN tunnel using e.g. IKE (or IKEv2) if security associations are not already available; o registers the VPN tunnel inner address (VPN-TIA) as its co-located care-of address with the internal home agent; this registration request is sent inside the IPsec tunnel. The solution requires some control over the protocol layers in the mobile node. The mobile node must be capable of (1) detecting whether it is inside or outside in a secure fashion, and (2) control the protocol layers accordingly. For instance, if the mobile node is inside, the IPsec layer needs to become dormant. Current Mobile IPv4 and IPsec standards, when used in a suitable combination, are sufficient to implement the solution; no changes are required to existing VPN devices, home agents, or foreign agents. Although the basic solution has a number of shortcomings, especially in terms of overhead and complexity, optimizations that require changes to Mobile IPv4 or IPsec are out of scope of this document. These will be pursued as separate work items. 1.2 Scope This document describes a solution for IPv4 only. VPN, in this document, refers to an IPsec-based remote access VPN. Other types of VPNs are out of scope. 1.3 Related work Related work has been done on Mobile IPv6 in [13] which discusses the interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6 signalling. The draft also discusses dynamic updating of the IPsec endpoint based on Mobile IP signaling packets. The "transient pseudo-NAT" attack, described in [14] and [4], affects any approach which attempts to provide security of mobility signalling in conjunction with NAT devices. In many cases, one Vaarala (Ed.) Expires December 27, 2003 [Page 5] Internet-Draft MIPv4-VPN June 2003 cannot assume any co-operation from NAT devices which thus have to be treated as "adversaries" of a sort. 1.4 Terms and abbreviations co-CoA: co-located care-of address external network: the untrusted network (i.e. Internet). Note that a private network (e.g. another corporate network) other than the mobile node's internal network is considered an external network. FA-CoA: foreign agent care-of address internal network: the trusted network; for instance, a physically secure corporate network where the i-HA is located. inside: in the internal network; each network interface may be independently inside or outside i-FA: Mobile IPv4 foreign agent residing in the internal network i-HA: Mobile IPv4 home agent residing in the internal network; typically has a private address [5] i-HoA: home address of the mobile node in the internal home agent VPN-TIA: VPN tunnel inner address, the address(es) negotiated during IKE phase 2 (quick mode), assigned manually, using IPsec-DHCP, using mode config, or by some other means. Some VPN clients use their current care-of address as their TIA for architectural reasons. VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode IPsec connection, or L2TP combined with IPsec transport connection. outside: in the external network; each network interface may be independently inside or outside x-FA: Mobile IPv4 foreign agent residing in the external network x-HA: Mobile IPv4 home agent residing in the external network x-HoA: home address of the mobile node in the external home agent Vaarala (Ed.) Expires December 27, 2003 [Page 6] Internet-Draft MIPv4-VPN June 2003 1.5 Requirement levels The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Vaarala (Ed.) Expires December 27, 2003 [Page 7] Internet-Draft MIPv4-VPN June 2003 2. Topology The following figure describes an example network topology illustrating the relationship between the internal and external networks, the possible locations of the mobile node ("MN" in parenthesis). The access modes (described later in Section 3) available to the mobile node from each location are also shown in curly braces. (MN) {fvc} {home} (MN) [i-HA] ! \ / .--+---. .-+---+-. ( ) ( ) `--+---' [VPN] `--+----' \ ! ! [R/FA] [x-HA] .--+--. [R] \ / ( DMZ ) ! .-+-------+--. `--+--' .-----+------. ( ) ! ( ) ( external net +---[R]----[FW]----[R]--+ internal net ) ( ) ( ) `--+---------' `---+---+----' / / \ [DHCP] [R] [DHCP] [R] [R] [i-FA] \ / \ / \ / .+--+---. .-+-+--. .--+--+-. ( ) ( ) ( ) `---+---' `--+---' `---+---' ! ! ! (MN) {cvc} (MN) {c} (MN) {f} Figure: Basic topology, possible MN locations and access modes The internal network is typically a multi-subnetted network which uses private addressing [5]. Subnets may contain internal home agent(s) (typically using private addresses), DHCP server(s), and/or foreign agent(s). Current IEEE 802.11 wireless LANs are typically deployed in the external network or the DMZ because of security concerns. The external network term used in this document includes the public Internet, and private networks other than the mobile node's internal network. The de-militarized zone (DMZ) is a tiny network typically containing servers that need to be accessed from both internal and external Vaarala (Ed.) Expires December 27, 2003 [Page 8] Internet-Draft MIPv4-VPN June 2003 networks; for instance, VPN devices. The figure leaves out a few details worth noticing: o There may be multiple NAT devices anywhere in the diagram. * When the MN is outside, the NAT devices may be placed between the MN and the x-HA or the x-HA and the VPN. * There may be also be NAT(s) between the VPN and the i-HA, or a NAT integrated into the VPN. In essence, any router in the figure may be considered to represent zero or more routers, each possibly performing NAT and/or ingress filtering. * When the MN is inside, there may be NAT devices between the MN and the i-HA, although this is not typical. o Site-to-site VPN tunnels are not shown. Although mostly transparent, IPsec endpoints may perform ingress filtering as part of enforcing their policy. (Thus, reverse tunnelling SHOULD always be used.) o Trusted foreign agents (in this context referring to foreign agents connected to the internal network using an IPsec tunnel) are not shown. Trusted foreign agents are logically part of the internal network. o The figure represents a "canonical" topology where each functional entity is illustrated as a separate device. However, it is possible that in a physical network several functions are co- located in a single device (for instance, the x-HA and VPN functionalities). In fact, all three server components (x-HA, VPN, and i-HA) may be co-located in a single physical device. The following issues are also of importance: o Some firewalls are configured to block ICMP messages and/or fragments. Such firewalls (routers) cannot be detected reliably. o Some networks contain transparent application proxies, especially for the HTTP protocol. Like firewalls, such proxies cannot be detected reliably in general. IPsec and Mobile IPv4 are incompatible with such networks. Vaarala (Ed.) Expires December 27, 2003 [Page 9] Internet-Draft MIPv4-VPN June 2003 3. Access modes In every possible location described in Section 2 the mobile node can establish a connection to its i-HA by using a suitable "access mode". An access mode is here defined to consist of: 1. a composition of the mobile node networking stack (i-MIP or x- MIP/VPN/i-MIP); and 2. registration mode(s) of i-MIP and x-MIP (if used); i.e. co- located care-of address or foreign agent care-of address. Each possible access mode is encoded as "xyz", where: o "x" indicates whether the x-MIP layer is used, and if used, the mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence indicates not used); o "y" indicates whether the VPN layer is used ("v" indicates VPN used, absence indicates not used); o "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c" indicates co-CoA). This results in four access modes: c: i-MIP w/ co-CoA f: i-MIP w/ FA-CoA cvc: x-MIP w/ co-CoA, VPN-TIA as i-MIP co-CoA fvc: x-MIP w/ FA-CoA, VPN-TIA as i-MIP co-CoA This notation is more useful when optimizations to protocol layers are considered. The notation is preserved here so that work on the optimizations can refer to a common notation. Whenever a mobile node obtains either a co-CoA (using e.g. DHCP) or a FA-CoA (from a foreign agent advertisement), the following steps (conceptually) take place: o The mobile node detects whether the subnet where the care-of address was obtained belongs to the internal or the external network using the method described in Section 4 (or a vendor specific mechanism fulfilling the requirements described). o The mobile node performs necessary registrations and other connection setup signalling for the protocol layers (in the following order): Vaarala (Ed.) Expires December 27, 2003 [Page 10] Internet-Draft MIPv4-VPN June 2003 * x-MIP (if used); * VPN (if used); and * i-MIP. Note that these two tasks are intertwined to some extent: detection of internal network may actually result in a successful registration to the i-HA, for instance. The following subsections describe the different access modes and the requirements for registration and connection setup phase. 3.1 Access mode: 'c' This access mode is standard Mobile IPv4 [3] with a co-located address, except that: o the mobile node MUST detect that it is in the internal network; and o the mobile node MUST re-register periodically (with a configurable interval) to ensure it is still inside the internal network (see Section 5). The registration request SHOULD have T-bit reverse tunnelling) set. Reverse tunnelling allows Mobile IPv4 to be used even in the presence of ingress filtering. Since some site-to-site VPN tunnels perform ingress filtering as a side effect of IPsec policy processing, reverse tunnelling should be used to increase interoperability. 3.2 Access mode: 'f' This access mode is standard Mobile IPv4 [3] with a foreign agent care-of address, except that o the mobile node MUST detect that it is in the internal network; and o the mobile node MUST re-register periodically (with a configurable interval) to ensure it is still inside the internal network (see Section 5). The registration request SHOULD request reverse tunnelling (see Section 3.1). Vaarala (Ed.) Expires December 27, 2003 [Page 11] Internet-Draft MIPv4-VPN June 2003 3.3 Access mode: 'cvc' Steps: o The mobile node obtains a care-of address from e.g. a DHCP server. o The mobile node detects it is outside and registers with the x-HA (possibly as a side effect of the detection process), where * D-bit MUST be set (co-located) * T-bit SHOULD be set (reverse tunnelling) o If necessary, the mobile node uses IKE to set up an IPsec connection with the VPN gateway, using the x-HoA as the IP address for IKE/IPsec communication. The VPN-TIA is assigned in some manner (or chosen by the MN). VPN capability negotiation is done at the same time. o The mobile node sends a MIPv4 RRQ to the i-HA, registering the VPN-TIA as a co-located care-of address, where * D-bit MUST be set (co-located) * T-bit MUST be set (reverse tunnelling) 3.4 Access mode: 'fvc' Steps: o The mobile node obtains a foreign agent advertisement from the local network. o The mobile node detects it is outside and registers with the x-HA (possibly as a side effect of the detection process), where * D-bit MUST NOT be set (foreign agent) * T-bit SHOULD be set (reverse tunnelling) o If necessary, the mobile node uses IKE to set up an IPsec connection with the VPN gateway, using the x-HoA as the IP address for IKE/IPsec communication. The VPN-TIA is assigned in some manner (or chosen by the MN). VPN capability negotiation is done at the same time. Vaarala (Ed.) Expires December 27, 2003 [Page 12] Internet-Draft MIPv4-VPN June 2003 o The mobile node sends a MIPv4 RRQ to the i-HA, registering the VPN-TIA as a co-located care-of address, where * D-bit MUST be set (co-located) * T-bit MUST be set (reverse tunnelling) 3.5 NAT traversal NAT devices may affect each layer independently (and even all three layers at the same time). Mobile IPv4 NAT traversal MUST be used for x-MIP and i-MIP layers, while IPsec NAT traversal [6][7] MUST be used for VPN layer. Note that NAT traversal for the internal MIPv4 layer may be necessary even when there is no separate NAT device between the VPN gateway and the internal network. Some VPN implementations NAT VPN tunnel inner addresses before routing traffic to the intranet. Sometimes this is done to make a deployment easier, but in some cases this approach makes VPN client implementation easier. Mobile IPv4 NAT traversal is required to establish a MIPv4 session in this case. Vaarala (Ed.) Expires December 27, 2003 [Page 13] Internet-Draft MIPv4-VPN June 2003 4. Internal network detection Secure detection of the internal network is security critical: if the mechanism fails for some reason, plaintext traffic may be sent to an untrusted network. In other words, the overall security (confidentiality and integrity of user data) is a minimum of IPsec security and the internal network detection mechanism security. For this reason, a set of requirements relevant to security are described in this section. In addition to detecting entry into the internal network, the mobile node must also detect when it leaves the internal network. Entry into the internal network is easier security-wise: the mobile node can take all the time it needs to ensure that it is inside the internal network before sending any plaintext traffic. Exit from the internal network is more difficult to detect, and the MN may accidentally leak plaintext packets if the event is not detected properly. Several events cause the mobile node to exit the internal network, for instance: o a routing change upstream; o a reassociation of 802.11 on layer 2 which the mobile node software does not detect; o a physical cable disconnect and reconnect which the mobile node software does not detect. Whether the mobile node can detect such changes in the current connection reliably depends on the implementation. For instance, some mobile nodes may be implemented as pure layer three entities. Even if the mobile node software has access to layer two information, such information is not trustworthy security-wise (and depends on the network interface driver). If the mobile node does not detect these events properly, it may leak plaintext traffic into an untrusted network. A number of approaches can be used to detect exit from the internal network, ranging from frequent re-registration to the use of layer two information. A mobile node MUST implement a detection mechanism fulfilling the requirements described in Section 4.2; this ensures that basic security requirements are fulfilled. The basic algorithm described in Section 4.3 is one way to do that, but alternative methods may be used instead or in conjunction. The assumptions that the requirements and the proposed mechanism rely upon are described in Vaarala (Ed.) Expires December 27, 2003 [Page 14] Internet-Draft MIPv4-VPN June 2003 Section 4.1. 4.1 Assumptions The firewall MUST be configured to block traffic originating from external networks going to the i-HA. In other words, if the mobile node succeeds in registering with the i-HA directly (without using IPsec), the mobile node may safely infer that it is connected to the trusted internal network, and may therefore use plaintext traffic. The firewall MAY be configured to block registration traffic to the x-HA originating from within the internal network, which makes the network detection algorithm simpler and more robust. However, as the registration request is basically UDP traffic, an ordinary firewall (even a stateful one) would typically allow the registration request to be sent, and a registration reply to be received through the firewall. 4.2 Implementation requirements Any mechanism used to detect the internal network MUST fulfill the following requirements. 4.2.1 Connection status change When the mobile node detects that its connection status on a certain network interface changes, the mobile node MUST: o immediately stop relaying user data packets; o detect whether this interface is connected to the internal or the external network; o resume data traffic only after the internal network detection and necessary registrations and VPN tunnel establishment have been completed. The mechanism used to detect a connection status change depends on the mobile node implementation and the access mode. The connection status is considered to change whenever any of the following happens: o when the interface is connected to the internal network, the i-HA can no longer be reached using a re-registration; o the next hop router is no longer reachable (e.g. ARP fails); o when using an FA, FA advertisements from the FA used for registration are no longer received; or Vaarala (Ed.) Expires December 27, 2003 [Page 15] Internet-Draft MIPv4-VPN June 2003 o layer two or other such information indicates that the physical connection status has changed. The mobile node MUST detect the first event, i.e. failure to re- register when inside. Detecting the other events is RECOMMENDED. 4.2.2 Registration-based internal network detection The mobile node MUST NOT infer that an interface is connected to the internal network unless a successful registration has been completed through that particular interface and the connection status of the interface has not changed since. 4.2.3 Registration-based internal network monitoring Some leak of plaintext packets to a (potentially) untrusted network cannot always be completely prevented; this depends heavily on the client implementation. In some cases the client cannot detect such a change (for instance if the subnet is reconnected to another place in the network topology in its entirety). To bound the maximum amount of time that such a leak may persist, the mobile node MUST fulfill the following requirements when inside: o When the mobile node is registered directly to the i-HA (i.e. not using IPsec), the mobile node MUST re-register with the i-HA periodically to ensure that is still connected to the trusted internal network. o This re-registration interval and associated retransmission parameters MUST be configurable in the mobile node, so that the maximum exposure time can be reliably controlled. o The default values MUST ensure that the mobile node will stop sending plaintext traffic within one minute of the change of i-HA reachability. o When the mobile node fails to re-register, it MUST stop sending and receiving plaintext traffic immediately, to prevent plaintext traffic from leaking out and untrusted data from leaking in. The re-registration requirement allows the administrator to determine the required security level for the particular deployment. Configuring the re-registration interval to a very small value (i.e. in the order of few seconds) is not practical; alternative mechanisms need to be considered if such confidence is required. Note that this is just the fallback mechanism. If additional Vaarala (Ed.) Expires December 27, 2003 [Page 16] Internet-Draft MIPv4-VPN June 2003 information (such as layer two information) is available to the mobile node, the mobile node SHOULD assume it has moved and restart the registration process to minimize exposure. Also note that the re-registration interval only applies when the mobile node is inside the internal network. When outside, ordinary Mobile IPv4 re-registration process (based on registration lifetime) is used. 4.2.4 Handling of network interfaces The mobile node implementation MUST track each network interface separately. Successful registration with the i-HA through interface X does not imply anything about the status of interface Y. 4.3 Proposed algorithm When the MN detects that it has changed its point of network attachment (on a certain interface), it issues two simultaneous registration requests, one to the i-HA and another to the x-HA. These registration requests are periodically retransmitted if reply messages are not received. Registration replies are processed as follows: o If a response from the x-HA is received, the MN stops retransmitting its registration request to the x-HA and determines it is outside. However, the MN MUST keep on retransmitting its registration to the i-HA for a period of time. The MN MAY postpone the IPsec connection setup for some period of time ("detection period") while it waits for a response from the i-HA. o If a response from the i-HA is received, the MN MUST determine that it is inside. If a previous registration reply from the x-HA has been received, the MN SHOULD de-register with the x-HA. In any case, the MN MUST stop retransmitting its registration requests to both i-HA and x-HA. o If a response from the x-HA is received while the MN has successfully registered with the i-HA, the MN SHOULD de-register with the x-HA. If the MN ends up detecting that it is inside, it MUST re-register periodically (regardless of binding lifetime). The re-registration interval and related parameters (e.g. for retransmission) MUST be configurable, as they are security related parameters (see Section 4.2.3). If the re-registration fails, the MN MUST stop sending and receiving plaintext traffic, and MUST restart the detection Vaarala (Ed.) Expires December 27, 2003 [Page 17] Internet-Draft MIPv4-VPN June 2003 algorithm. Plaintext re-registration messages are always addressed either to the x-HA or the i-HA, not to both. This is because the MN knows, after initial registration, whether it is inside or outside. (However, when the mobile node is outside, it re-registers independently with the x-HA using plaintext, and with the i-HA through the VPN tunnel.) The "detection period" is OPTIONAL, and may be useful in avoiding aborted IKE sessions due to timing of i-HA and x-HA registration reply messages. Aborted IKE sessions may be a problem in some cases because IKE does not provide a reliable, standardized, and mandatory- to-implement mechanism for terminating a session cleanly. If the x-HA is not reachable from inside (i.e. the firewall configuration is known), a detection period of zero is preferred, as it minimizes connection setup overhead and causes no timing problems. Should the assumption have been invalid and a response from the i-HA received after a response from the x-HA, the MN SHOULD re-register with the i-HA directly. Note that it is possible that an i-HA is initially unreachable for some time, but later becomes reachable (consider e.g. a routing problem in the internal network). To eventually detect the i-HA, the MN MAY send periodic registration attempts to the i-HA even after determining initially that it is outside. The period of such re- registration attempts should be in the order of minutes (e.g. 10 minutes), and configurable. 4.4 Implementation issues When the MN uses a parallel detection algorithm and is using an FA, the MN sends two registration requests through the same FA with the same MAC address (or equivalent) and possibly even the same home address. Although this is not in conflict with existing specifications, it is not a usual scenario; hence some FA implementations may not work properly in such a situation. However, practical testing against deployed foreign agents seems to indicate that a majority of foreign agents handle this situation. When the x-HA and i-HA addresses are the same, the scenario is even more difficult for the FA, and it is almost certain that existing FAs do not deal with the situation correctly. Therefore, it is required that x-HA and i-HA addresses MUST be different. This requirement is automatically satisfied if the x-HA has a public address. The mobile node MAY use the following hints to determine that it is inside, but MUST verify reachability of the i-HA anyway: Vaarala (Ed.) Expires December 27, 2003 [Page 18] Internet-Draft MIPv4-VPN June 2003 o a domain name in a DHCPDISCOVER / DHCPOFFER message; o a NAI in a foreign agent advertisement; o a list of default gateway MAC addresses which are known to reside in the internal network (i.e. configured as such, or have been previously verified to be inside). For instance, if the MN has reason to believe it is inside, it MAY postpone sending of registration request to the x-HA for some time. Similarly, if the MN has a reason to believe it is outside, it may start IPsec connection setup immediately after receiving a registration reply from the x-HA. However, should the MN receive a registration reply from the i-HA after IPsec connection setup has been started, the MN SHOULD still switch to using the i-HA directly. 4.5 Rationale 4.5.1 Firewall configuration requirements The assumption that the i-HA cannot be reached from the external network is, in practice, unavoidable. Suppose the assumption is not made, i.e. the i-HA is reachable from some external networks. As a result, a successful registration with the i-HA (without IPsec) cannot be used as a secure indication that the mobile node is inside. A possible solution to the obvious security problem would be to define and deploy a secure internal network detection mechanism based on e.g. signed FA advertisement or signed DHCP messages. However, unless the mechanism is defined for both FA and DHCP messages and is deployed in every internal network, it has limited applicability. In other words, the mobile node MUST NOT assume it is in the internal network unless it receives a signed FA or DHCP message (regardless of whether it can register directly with the i-HA or not!). If it receives an unsigned FA or DHCP message, it MUST use IPsec; otherwise the mobile node can be easily tricked into using plaintext. Assuming that all FA and DHCP servers in the internal network are upgraded to support such a feature does not seem realistic; it is highly desirable to be able to take advantage of existing DHCP and FA deployments. Similar analysis seems to apply regardless of what kind of additional security mechanism is defined. 4.5.2 Registration-based internal network monitoring This issue also affects IPsec client security. However, as IPsec specifications take no stand on how and when the client applies Vaarala (Ed.) Expires December 27, 2003 [Page 19] Internet-Draft MIPv4-VPN June 2003 IPsec, the issue is out of scope for IPsec. Because this document describes an algorithm and requirements for (secure) internal network detection, the issue is in scope of the document. The current requirement for internal network monitoring was added as a fallback mechanism. It seems to be the best what can be done with only layer three mechanisms. 4.6 Improvements The registration process can be improved in many ways. One simple way is to make the x-HA detect whether a registration request came from inside or outside. If it came from inside, the x-HA can simply drop the registration request, thus effectively "firewalling" the request. This approach is feasible without protocol changes in scenarios where a corporation owns both the VPN and the x-HA. The x-HA can simply determine based on incoming interface identifier (or the router which relayed the packet) whether the registration request came from inside or not. In other scenarios protocol changes may be needed. Such changes are out of scope of this document. Vaarala (Ed.) Expires December 27, 2003 [Page 20] Internet-Draft MIPv4-VPN June 2003 5. Requirements 5.1 Mobile node requirements The mobile node MUST implement an internal network detection algorithm fulfilling the requirements set forth in Section 4.2. The mobile node MUST support access modes: c, f, cvc, fvc (Section 3). The mobile node SHOULD support Mobile IPv4 NAT traversal [4] for both internal and external Mobile IP. The mobile node SHOULD support IPsec NAT traversal [6][7]. When the mobile node has direct access to the i-HA, it SHOULD use only the inner Mobile IPv4 layer to minimize firewall and VPN impact. 5.2 VPN device requirements The VPN security policy MUST allow communication using UDP to the internal home agent(s), with home agent port 434 and any remote port. The security policy SHOULD allow IP-IP to internal home agent(s) in addition to UDP port 434. The VPN device SHOULD implement the IPsec NAT traversal mechanism described in [6][7]. 5.3 Home agent requirements The home agent SHOULD implement the Mobile IPv4 NAT traversal mechanism described in [4]. (This also refers to the i-HA: NAT traversal is required to support VPNs that NAT VPN tunnel addresses or block IP-IP traffic.) Vaarala (Ed.) Expires December 27, 2003 [Page 21] Internet-Draft MIPv4-VPN June 2003 6. Analysis This section provides a comparison against guidelines described in Section 6 of the problem statement [2] and additional analysis of packet overhead with and without the optional mechanisms. 6.1 Comparison against guidelines Preservation of existing VPN infrastructure o The proposed solution does not mandate any changes to existing VPN infrastructure, other than possibly changes in configuration to avoid stateful filtering of traffic. Software upgrades to existing VPN clients and gateways o The solution described does not require any changes to VPN gateways or Mobile IPv4 home agents or foreign agents. IPsec protocol o Proposed solution does not require any changes to existing IPsec or key exchange standard protocols, and does not require implementation of new protocols in the VPN device. Multi-vendor interoperability o The proposed solution provides easy multi-vendor interoperability between server components (VPN device, foreign agents and home agents). Indeed, these components need not be aware of each other. o The mobile node networking stack is somewhat complex to implement, which may be an issue for multi-vendor interoperability. MIPv4 protocol o The solution adheres to the MIPv4 protocol. o The solution requires the use of two parallel MIPv4 layers. Handoff overhead o The solution provides a mechanism to avoid VPN tunnel SA renegotiation upon movement by using the external MIPv4 layer. Scalability, availability, reliability, and performance Vaarala (Ed.) Expires December 27, 2003 [Page 22] Internet-Draft MIPv4-VPN June 2003 o The solution complexity is linear with the number of MNs registered and accessing resources inside the intranet. o Additional overhead is imposed by the solution. Functional entities o The solution does not impose any new types of functional entities or required changes to existing entities. However, an external HA device is required. Implications of intervening NAT gateways o The solution leverages existing MIPv4 NAT traversal [4] and IPsec NAT traversal [6][7] solutions and does not require any new functionality to deal with NATs. Security implications o The solution requires a new mechanism to detect whether the mobile node is in the internal or the external network. The security of this mechanism is critical in ensuring that the security level provided by IPsec is not compromised by a faulty detection mechanism. o When the mobile node is outside, the external Mobile IPv4 layer may allow some traffic redirection attacks that plain IPsec does not allow. Other than that, IPsec security is unchanged. o More security considerations are described in Section 7. 6.2 Packet overhead The maximum packet overhead depends on access mode as follows: o f: 0 octets o c: 20 octets o fvc: 77 octets o cvc: 97 octets The overhead consists of the following: o IP-IP for i-MIPv4: 20 octets Vaarala (Ed.) Expires December 27, 2003 [Page 23] Internet-Draft MIPv4-VPN June 2003 o IPsec ESP: 57 octets total, consisting of: 20 (new IP header), 4+4+8 = 16 (SPI, sequence number, cipher initialization vector), 7+2 = 9 (padding, padding length field, next header field), 12 (ESP authentication trailer) o IP-IP for x-MIPv4: 20 octets When IPsec is used, a variable amount of padding is present in each ESP packet. The figures were computed for a cipher with 64-bit block size, padding overhead of 9 octets (next header field, padding length field, and 7 octets of padding, see Section 2.4 of [8]), and ESP authentication field of 12 octets (HMAC-SHA1-96 or HMAC-MD5-96). Note that an IPsec implementation MAY pad with more than a minimum amount of octets. NAT traversal overhead is not included, and adds 8 octets when IPsec NAT traversal [6][7] is used and 12 octets when MIP NAT traversal [4] is used. For instance, when using access mode cvc, the maximum NAT traversal overhead is 12+8+12 = 32 octets. Thus, the worst case scenario (with the abovementioned ESP assumptions) is 129 octets for cvc. 6.3 Latency considerations The following terms are used: i-RTT: round trip time to i-HA x-RTT: round trip time to x-HA i-TP: total processing time (MN & HA) for one i-HA round trip x-TP: total processing time (MN & HA) for one x-HA round trip DP-T: "detection period" when MN is outside VPN-T: VPN connection setup time DET-T: time to detect a change in network connection DHCP-T: time to obtain co-located care-of address using DHCP FA-T: time to obtain a foreign agent care-of address In the analysis below, packet loss is ignored. DHCP is used as an example; any method of obtaining a co-located care-of address is equivalent. Note that i-RTT and x-RTT always refer to the round trip time from the current location. Thus, i-RTT is typically "large" when the mobile node is outside, and "small" when inside. The basic network detection algorithm has no "memory"; thus connection setup latency is only dependent on the current access network, not whether the previous access network was outside or inside. When the mobile node is inside, connection setup latency is Vaarala (Ed.) Expires December 27, 2003 [Page 24] Internet-Draft MIPv4-VPN June 2003 determined simply by the latency of registration with the i-HA, which is typically simply (i-RTT + i-TP). When a foreign agent is used to register a co-located care-of address, and a NAT is detected, the latency is 2*(i-RTT + i-TP) (see [4] Section 4.11). The "detection period" does not affect latency because the mobile node SHOULD use the i-HA directly if the i-HA replies. When the mobile node is outside, connection setup latency is typically (x-RTT + x-TP + DP-T + VPN-T + i-RTT + i-TP), where VPN-T is omitted if an IPsec connection already exists. When a foreign agent is used to register a co-located care-of address to the x-HA, and a NAT is detected, the latency is (2*(x-RTT + x-TP) + DP-T + VPN- T + i-RTT + i-TP). Since each step of the connection setup builds on the previous one, the steps always proceed in strict sequence and no parallellism is possible. The total latency from change in network connection to bi-directional packet flow is the sum of DET-T, min(DHCP-T, FA-T), and the connection setup time. For instance, when outside, typically: (DET-T + min(DHCP-T, FA-T) + x-RTT + x-TP + DP-T + VPN-T + i-RTT + i-TP). Because the network detection uses parallel registration to x-HA and i-HA, there is no considerable latency impact from the parallel registration as such, except of course the small delay imposed on the second registration request because sending is sequential in reality. However, detection period (DP-T) increases total latency directly. The mobile node may improve latency when outside by two means: o sending the registration request most likely to succeed first, thus avoiding the small delay caused by sequential sending; and o using a detection period of zero. These two can be done based on heuristics about the network, e.g. addresses, MAC address of the default gateway (which the mobile node may remember from previous access), based on the previous access network (i.e. optimize for inside-inside and outside-outside movement), etc. 6.4 Firewall state considerations A separate firewall device or an integrated firewall in the VPN gateway typically performs stateful inspection of user traffic. The firewall may, for instance, track TCP session status and block TCP segments not related to open connections. Other stateful inspection mechanisms also exist. Vaarala (Ed.) Expires December 27, 2003 [Page 25] Internet-Draft MIPv4-VPN June 2003 Firewall state poses a problem when the mobile node moves between the internal and external networks. The mobile node may, for instance, initiate a TCP connection while inside, and later go outside while expecting to keep the connection alive. From the point of view of the firewall, the TCP connection has not been initiated, as it has not witnessed the TCP connection setup packets, thus potentially resulting in connectivity problems. When the VPN-TIA is registered as a co-located care-of address with the i-HA, all mobile node traffic appears as IP-IP for the firewall. Typically firewalls don't continue inspection beyond the IP-IP tunnel, but it is not inconceivable that some firewalls may do that. In summary, the firewall must allow traffic coming from and going into the IPsec connection to be routed, even though they may not have successfully tracked the connection state. How this is done is out of scope of this document. 6.5 Intrusion detection systems (IDSs) Many firewalls incorporate intrusion detection systems, which monitor traffic for unusual patterns and clear signs of attack. Since traffic from a mobile node implementing this specification is UDP to i-HA port 434, and possibly IP-IP traffic to the i-HA address, existing IDSs may treat the traffic differently than ordinary VPN remote access traffic. Like firewalls, IDSs are not standardized, so it is impossible to guarantee interoperability with any particular IDS system. 6.6 Implementation of mobile node Implementation of the mobile node requires the use of three tunnelling layers, which may be used in various configurations depending on whether that particular interface is inside or outside. Note that it is possible that one interface is inside and another interface is outside, which requires a different layering for each interface at the same time. For multi-vendor implementation, the IPsec and Mobile IPv4 layers need to interoperate in the same mobile node. This implies that a flexible framework for protocol layering (or protocol-specific APIs) are required. 6.7 Non-IPsec VPN protocols The proposed solution works also for VPN tunneling protocols that are not IPsec-based, provided that the mobile node is provided IPv4 connectivity with an address suitable for registration. However, Vaarala (Ed.) Expires December 27, 2003 [Page 26] Internet-Draft MIPv4-VPN June 2003 such VPN protocols are not explicitly considered. 6.8 Shortcomings for enterprise use The proposed solution has the following shortcomings for enterprise use: o Networks which provide only HTTP access (sometimes found in corporate networks) cannot be used for remote access. o Fragments are filtered by some routers. MIP NAT traversal [4] solves some, but not all, fragment related issues. However, these are not part of the problem statement. Vaarala (Ed.) Expires December 27, 2003 [Page 27] Internet-Draft MIPv4-VPN June 2003 7. Security considerations 7.1 Internal network detection If the mobile node mistakenly believes it is in the internal network and sends plaintext packets, it compromises IPsec security. For this reason, the overall security (confidentiality and integrity) of user data is a minimum of (1) IPsec security, and (2) security of the internal network detection mechanism. Security of the internal network detection relies on a successful registration with the i-HA. For standard Mobile IPv4 [3] this means HMAC-MD5 and Mobile IPv4 replay protection. When the connection status of an interface changes, an interface previously connected to the trusted internal network may suddenly be connected to an untrusted network. Although the same problem is also relevant to IPsec-based VPN implementations, the problem is especially relevant in the scope of this specification. In most cases, mobile node implementations are expected to have layer two information available, making connection change detection both fast and robust. To cover cases where such information is not available (or fails for some reason), the mobile node is required to periodically re-register with the internal home agent to verify that it is still connected to the trusted network. It is also required that this re-registration interval be configurable, thus giving the administrator a parameter by which potential exposure may be controlled robustly even for the worst case. 7.2 Mobile IPv4 versus IPsec MIPv4 and IPsec have different goals and approaches for providing security services. MIPv4 typically uses a shared secret for authentication of (only) signalling traffic, while IPsec typically uses IKE (an authenticated Diffie-Hellman exchange) to set up session keys. Thus, the overall security properties of a combined MIPv4 and IPsec system depend on both mechanisms. In a "dual HA" solution the external MIPv4 layer provides mobility for IPsec traffic. If the security of MIPv4 is broken in this context, traffic redirection attacks against the IPsec traffic are possible. However, such routing attacks do not affect other IPsec properties (confidentiality, integrity, replay protection, etc), because IPsec does not consider the network between two IPsec endpoints to be secure in any way. Because MIPv4 shared secrets are usually configured manually, they Vaarala (Ed.) Expires December 27, 2003 [Page 28] Internet-Draft MIPv4-VPN June 2003 may be weak if easily memorizable secrets are chosen, thus opening up redirection attacks described above. Note that a weak secret in the i-HA is fatal to security, as the mobile node can be fooled into dropping encryption if the i-HA secret is broken. Assuming the MIPv4 shared secrets have sufficient entropy, there are still at least the following differences and similarities between MIPv4 and IPsec worth considering: o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" attack described in [14] and [4], assuming that NAT traversal is enabled (which is typically the case). o When considering a "pseudo NAT" attack against standard IPsec and standard MIP (with NAT traversal), redirection attacks against MIP may be easier because: * MIPv4 re-registrations typically occur more frequently than IPsec SA setups (although this may not be the case for mobile hosts). * It suffices to catch and modify a single registration request, whereas attacking IKE requires that multiple IKE packets are caught and modified. o There may be concerns about mixing of algorithms. For instance, IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC- MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore, while IPsec algorithms are typically configurable, MIPv4 clients typically use only HMAC-MD5 or prefix+suffix MD5. Although this is probably not a security problem as such, it is more difficult to communicate to users. o When IPsec is used with a PKI, the key management properties are superior to those of basic MIPv4. Thus, adding MIPv4 to the system makes key management more complex. o In general, adding new security mechanisms increases overall complexity and makes the system more difficult to understand. Vaarala (Ed.) Expires December 27, 2003 [Page 29] Internet-Draft MIPv4-VPN June 2003 8. Intellectual property rights Birdstep Technology has submitted patent application(s) related to the dual mobile IP design for VPN gateway traversal. Birdstep's objective is to seek intellectual property protection for its mobile IP client implementation of such a design. If any standards arising from this document are or become protected by one or more patents assigned to Birdstep Technology, and if any claims of any issued Birdstep patents are necessary for practicing such a standard, any party will be able to obtain a license from Birdstep to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard. Vaarala (Ed.) Expires December 27, 2003 [Page 30] Internet-Draft MIPv4-VPN June 2003 9. Acknowledgements This document is a joint work of the contributing authors (in alphabetical order): - Farid Adrangi (Intel Corporation) - Nitsan Baider (Check Point Software Technologies, Inc.) - Gopal Dommety (Cisco Systems) - Eli Gelasco (Cisco Systems) - Dorothy Gellert (Nokia Corporation) - Espen Klovning (Birdstep) - Milind Kulkarni (Cisco Systems) - Henrik Levkowetz (ipUnplugged AB) - Frode Nielsen (Birdstep) - Sami Vaarala (Netseal) - Qiang Zhang (Liqwid Networks, Inc.) The authors would like to thank MIP/VPN design team, especially Mike Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans Sjostrand, and Serge Tessier for their continuous feedback and helping us improve this draft. We would also like to thank the Mobile IP working group chairs (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important feedback and guidance. Vaarala (Ed.) Expires December 27, 2003 [Page 31] Internet-Draft MIPv4-VPN June 2003 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Adrangi, F., Kulkarni, M., Dommety, G., Gelasco, E., Zhang, Q., Vaarala, S., Gellert, D., Baider, N. and H. Levkowetz, "Problem Statement and Solution Guidelines for Mobile IPv4 Traversal Across IPsec-based VPN Gateways (draft-ietf-mobileip-vpn- problem-statement-guide-00e, work in progress)", January 2003. [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003. [5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, BCP 5, February 1996. [6] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe, "Negotiation of NAT-Traversal in the IKE (draft-ietf-ipsec-nat- t-ike-05, work in progress)", January 2003. [7] Huttunen, A., Swander, B., Stenberg, M., Volpe, V. and L. DiBurro, "UDP Encapsulation of IPsec packets (draft-ietf-ipsec- udp-encaps-06, work in progress)", January 2003. [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [9] Nuopponen, A. and S. Vaarala, "Mobile IPv4 coexistence with IPsec remote access tunnelling (draft-nuopponen-vaarala-mipvpn- 00, work in progress)", July 2002. [10] Adrangi, F., Iyer, P., Zhang, Q. and N. Baider, "Mobile IPv4 Traversal Across IPsec-based VPN Gateways (draft-adrangi- mobileip-mipvpn-traversal, work in progress)", January 2003. [11] Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A., Zhang, Q. and J. Lau, "Mobile IPv4 Traversal Across IPsec-based VPN Gateways (draft-adrangi-mobileip-vpn-traversal-02)", July 2002. [12] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage", December 2002. Vaarala (Ed.) Expires December 27, 2003 [Page 32] Internet-Draft MIPv4-VPN June 2003 [13] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (draft-ietf-mobileip-mipv6-ha-ipsec-01, work in progress)", October 2002. [14] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed (draft-dupont- transient-pseudonat-01, work in progress)", December 2002. Author's Address Sami Vaarala Netseal Niittykatu 6 Espoo 02201 FINLAND Phone: +358 9 435 310 EMail: sami.vaarala@iki.fi Vaarala (Ed.) Expires December 27, 2003 [Page 33] Internet-Draft MIPv4-VPN June 2003 Appendix A. Packet flow examples A.1 Connection setup for access mode 'cvc' The following figure illustrates connection setup when the mobile node is outside and using a co-located care-of address. IKE connection setup is not shown in full, and involves multiple round trips (4.5 round trips when using main mode followed by quick mode). MN-APP MN x-HA VPN i-HA CN ! ! ! ! ! ! ! ! -------> ! ! ! ! ! ! rrq ! ! ! ! ! ! -----------------------------X ! ! rrq not ! ! rrq ! ! ! ! received ! ! ! ! ! ! by i-HA ! ! <------- ! ! ! ! ! ! rrp ! ! ! ! ! ! ! ! ! ! ! [wait for detection period for response from i-HA] ! ! [may also retransmit to i-HA, depending on config] ! no rrp ! ! ! ! ! ! from i-HA ! ! ==(1)==> ! ! ! ! ! ! ike {1a}! -------> ! ! ! ! ! ! ike ! ! ! ! ! ! <------- ! ! ! ! ! <==(1)== ! ike ! ! ! ! ! ike ! ! ! ! : : : : : : : : : : : : ! ! ! ! ! ! ! ! ==(2)==> ! ! ! ! ! ! rrq {2a}! ==(1)==> ! ! ! ! ! ! rrq {2b}! -------> ! ! ! ! ! ! rrq {2c}! ! ! ! ! ! <------- ! ! ! ! ! <==(1)== ! rrp ! ! ! ! <==(2)== ! rrp ! ! ! ! ! rrp ! ! ! ! ! ! ! ! ! ! [[--- connection setup ok, bidirectional connection up ---]] ! ! ! ! ! ! ! -------> ! ! ! ! ! ! pkt {3a}! ==(3)==> ! ! ! ! ! ! pkt {3b}! ==(2)==> ! ! ! ! ! ! pkt {3c}! ==(1)==> ! ! ! ! ! ! pkt {3d}! -------> ! ! ! ! ! ! pkt {3e}! Vaarala (Ed.) Expires December 27, 2003 [Page 34] Internet-Draft MIPv4-VPN June 2003 ! ! ! ! ! <------- ! ! ! ! ! <==(1)== ! pkt ! ! ! ! <==(2)== ! pkt ! ! ! ! <==(3)== ! pkt ! ! ! ! <------ ! pkt ! ! ! ! ! pkt ! ! ! ! ! : : : : : : : : : : : : The notation "==(N)==>" or "<==(N)==" indicates that the innermost packet has been encapsulated N times, using IP-IP, ESP, or MIP NAT traversal. Packets marked with {xx} are shown in more detail below. Each area represents a protocol header (labeled). Source and destination addresses or ports are shown underneath the protocol name when applicable. Note that there are no NAT traversal headers in the example packets. Packet {1a} .------------------------------------. ! IP ! IP ! UDP ! IKE ! ! co-CoA ! x-HoA ! 500 ! ! ! x-HA ! VPN-GW ! 500 ! ! `------------------------------------' Packet {2a} .--------------------------------------------------------. ! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ ! ! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! ! ! x-HA ! VPN-GW ! ! i-HA ! 434 ! ! `--------------------------------------------------------' Packet {2b} .----------------------------------------------. ! IP ! ESP ! IP ! UDP ! MIP RRQ ! ! x-HoA ! ! VPN-TIA ! ANY ! ! ! VPN-GW ! ! i-HA ! 434 ! ! `----------------------------------------------' Packet {2c} .----------------------------. ! IP ! UDP ! MIP RRQ ! ! VPN-TIA ! ANY ! ! ! i-HA ! 434 ! ! `----------------------------' Packet {3a} Vaarala (Ed.) Expires December 27, 2003 [Page 35] Internet-Draft MIPv4-VPN June 2003 .-------------------. ! IP ! user ! ! i-HoA ! protocol ! ! CN ! ! `-------------------' Packet {3b} .------------------------------------------------------- - ! IP ! IP ! ESP ! IP ! IP ! user \ ! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../ ! x-HA ! VPN-GW ! ! i-HA ! CN ! \ `------------------------------------------------------- - - - -----------------. \..user ! ESP ! / protocol ! trailer ! \ ! ! - - -----------------' Packet {3c} .--------------------------------------------------------. ! IP ! ESP ! IP ! IP ! user ! ESP ! ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer ! ! VPN-GW ! ! i-HA ! CN ! ! ! `--------------------------------------------------------' Packet {3d} .------------------------------. ! IP ! IP ! user ! ! VPN-TIA ! i-HoA ! protocol ! ! i-HA ! CN ! ! `------------------------------' Packet {3e} .-------------------. ! IP ! user ! ! i-HoA ! protocol ! ! CN ! ! `-------------------' Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is shown below for comparison. Vaarala (Ed.) Expires December 27, 2003 [Page 36] Internet-Draft MIPv4-VPN June 2003 Packet {3b} (with NAT traversal headers) .------------------------------------------------- - ! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \ ! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! / ! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \ `------------------------------------------------- - <=== external MIPv4 ====> <=== IPsec ESP ======== = = - - ------------------------------------------------ - \..ESP ! IP ! UDP ! MIP ! IP ! user \ / ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../ \ ! i-HA ! 434 ! data ! CN ! \ - - ------------------------------------------------ - = ===> <==== internal MIPv4 ====> <== user packet == = - - -----------------. \..user ! ESP ! / protocol ! trailer ! \ ! ! - - -----------------' = = ======> <= ESP => The following diagram illustrates what happens when the i-HA response is delayed beyond detection period (and is received while IKE is on- going). MN-APP MN x-HA VPN i-HA CN ! ! -------> ! ! ! ! ! ! rrq ! ! ! ! ! ! -----------------------------X ! ! rrq not ! ! rrq ! ! ! ! received ! ! ! ! ! ! by i-HA ! ! <------- ! ! ! ! ! ! rrp ! ! ! ! ! ! ! ! ! ! ! [wait for detection period for response from i-HA] ! ! [retranmissions to i-HA] ! ! no rrp ! ! ! ! ! ! from i-HA ! ! ==(1)==> ! ! ! ! ! ! ike {1a}! -------> ! ! ! ! ! ! ike ! ! ! ! ! ! <------- ! ! ! ! ! <==(1)== ! ike ! ! ! ! ! ! ! ! ! : : : : : : ! ! <----------------------------- ! ! late rrp ! ! rrp ! ! ! ! Vaarala (Ed.) Expires December 27, 2003 [Page 37] Internet-Draft MIPv4-VPN June 2003 ! ! ! ! ! ! ! [bidirectional connection with i-HA up] ! ! ! [abort ike, de-register with x-ha] ! ! ! ! ! ! ! ! ! ! ! <------- ! ! ! ! ! <==(1)== ! ike ! [ike packets may] ! ! ike ! ! [arrive for some time] ! [drop] ! ! ! ! ! ! ! [peer not responding] ! ! ! ! [retransmit for some time] ! ! ! ! ! ! ! ! ! -------> ! ! ! ! ! ! rrq ! ! ! ! ! ! (dereg) ! ! ! ! ! ! ! ! ! ! ! ! <------- ! ! [after de-reg, x-HA] ! ! rrp ! <------- ! [drops ike packets] ! ! ! ike ! ! ! ! ! [drop] ! ! ! ! ! ! ! ! ! ! ! ==(1)========================> ! ! ! ! pkt ! ! ! -------> ! ! ! ! ! ! pkt ! ! ! ! ! ! ! ! ! ! ! ! <------- ! ! ! <==(1)======================== ! pkt ! ! ! pkt ! ! ! ! : : : : : : : : : : : : In the diagram above, the IKE session in the VPN device eventually times out. Some IKE implementations support aborting a session (ISAKMP exchange) in some way; if so, the IKE state is dropped cleanly. Note that it is possible to receive the registration reply from the i-HA after a registration request has been sent to the i-HA through the VPN tunnel (or indeed, even after a reply for the latter registration has been received). This case is dealt with by ordinary Mobile IPv4 means. A.2 Connection setup for access mode 'fvc' The diagram below illustrates connection setup in access mode fvc. MN-APP MN x-FA x-HA VPN i-HA CN ! ! ! ! ! ! ! ! ! -------> ! ! ! ! ! Vaarala (Ed.) Expires December 27, 2003 [Page 38] Internet-Draft MIPv4-VPN June 2003 ! ! rrq ! -------> ! ! ! ! ! ! ! rrq ! ! ! ! ! ! ! ! ! ! ! ! ! -------> ! ! ! ! ! ! ! rrq ! -----------------------------X ! ! ! ! ! rrq ! ! ! ! ! ! ! ! ! ! ! ! ! ! <------- ! ! ! ! ! ! <------- ! rrp ! ! ! ! ! ! rrp ! ! ! ! ! ! ! ! ! ! ! ! ! [wait for detection period for response from i-HA] ! ! [may also retransmit to i-HA, depending on config] ! ! ! ! ! ! ! ! ! ! -------> ! ! ! ! ! ! ! ike ! ==(1)==> ! ! ! ! ! ! ! ike ! -------> ! ! ! ! ! ! ! ike ! ! ! ! ! ! ! <------- ! ! ! ! ! ! <==(1)== ! ike ! ! ! ! ! <------- ! ike ! ! ! ! ! ! ike ! ! ! ! ! : : : : : : : : : : : : : : ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ==(1)==> ! ! ! ! ! ! ! rrq ! ==(2)==> ! ! ! ! ! ! ! rrq ! ==(1)==> ! ! ! ! ! ! ! rrq ! -------> ! ! ! ! ! ! ! rrq ! ! ! ! ! ! ! <------- ! ! ! ! ! ! <==(1)== ! rrp ! ! ! ! ! <==(2)== ! rrp ! ! ! ! ! <==(1)== ! rrp ! ! ! ! ! ! rrp ! ! ! ! ! ! ! ! ! ! ! ! ! [[--- connection setup ok, bidirectional connection up ---]] ! ! ! ! ! ! ! ! ! -------> ! ! ! ! ! ! ! pkt ! ==(2)==> ! ! ! ! ! ! ! pkt ! ==(3)==> ! ! ! ! ! ! ! pkt ! ==(2)==> ! ! ! ! ! ! ! pkt ! ==(1)==> ! ! ! ! ! ! ! pkt ! -------> ! ! ! ! ! ! ! pkt ! ! ! ! ! ! ! <------- ! ! ! ! ! ! <==(1)== ! pkt ! Vaarala (Ed.) Expires December 27, 2003 [Page 39] Internet-Draft MIPv4-VPN June 2003 ! ! ! ! <==(2)== ! pkt ! ! ! ! ! <==(3)== ! pkt ! ! ! ! ! <==(2)== ! pkt ! ! ! ! ! <------- ! pkt ! ! ! ! ! ! pkt ! ! ! ! ! ! : : : : : : : : : : : : : : Vaarala (Ed.) Expires December 27, 2003 [Page 40] Internet-Draft MIPv4-VPN June 2003 Appendix B. Changes Changes from -01 to -02: o Packet flow examples added. o Explicit IDS reference added. o Requirement levels adjusted; NAT traversal requirements changed from MUST to SHOULD and other changes. o MN no longer required to use i-HA directly whenever available (in some cases that may not be desired). o IPR section revised. o Latency considerations section added. o External HA reachability assumption refined; if firewall properly configured, handover performance can be improved. This is now mentioned in the detection section. o Overhead section simplified, only base solution discussed. o Proposed solutions section removed from appendix. o Strawmen of optimizations removed from appendix, references to optimizations removed from text. Changes from -00 to -01: o First description of proposed solution based on basic and optimized dual HA drafts, as well as IPsec endpoint update mechanism. o List of proposed solutions in -00 included in appendix. Vaarala (Ed.) Expires December 27, 2003 [Page 41] Internet-Draft MIPv4-VPN June 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vaarala (Ed.) Expires December 27, 2003 [Page 42]