[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-mobileip-vpn-problem-solution) 00 01 02 03 04 05 RFC 5265

Mobile IP                                               S. Vaarala (Ed.)
Internet-Draft                                                 Stinghorn
Expires: March 29, 2005                               September 28, 2004



         Mobile IPv4 Traversal Across IPsec-based VPN Gateways
                draft-ietf-mip4-vpn-problem-solution-00


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.


   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 March 29, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


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 March 29, 2005                 [Page 1]

Internet-Draft                 MIPv4-VPN                  September 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.3   Related work . . . . . . . . . . . . . . . . . . . . . . .  6
     1.4   Terms and abbreviations  . . . . . . . . . . . . . . . . .  6
     1.5   Requirement levels . . . . . . . . . . . . . . . . . . . .  7
     1.6   Assumptions and rationale  . . . . . . . . . . . . . . . .  7
     1.7   Why IPsec lacks mobility . . . . . . . . . . . . . . . . .  8
   2.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.  Access modes . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.1   Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . 14
     3.2   Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . 14
     3.3   Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 14
     3.4   Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 15
     3.5   NAT traversal  . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Internal network detection . . . . . . . . . . . . . . . . . . 16
     4.1   Assumptions  . . . . . . . . . . . . . . . . . . . . . . . 17
     4.2   Implementation requirements  . . . . . . . . . . . . . . . 17
       4.2.1   Connection status change . . . . . . . . . . . . . . . 17
       4.2.2   Registration-based internal network detection  . . . . 18
       4.2.3   Registration-based internal network monitoring . . . . 18
       4.2.4   Handling of network interfaces . . . . . . . . . . . . 19
     4.3   Proposed algorithm . . . . . . . . . . . . . . . . . . . . 19
     4.4   Implementation issues  . . . . . . . . . . . . . . . . . . 21
     4.5   Rationale  . . . . . . . . . . . . . . . . . . . . . . . . 21
       4.5.1   Firewall configuration requirements  . . . . . . . . . 21
       4.5.2   Registration-based internal network monitoring . . . . 22
       4.5.3   No encryption when inside  . . . . . . . . . . . . . . 22
     4.6   Improvements . . . . . . . . . . . . . . . . . . . . . . . 22
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 24
     5.1   Mobile node requirements . . . . . . . . . . . . . . . . . 24
     5.2   VPN device requirements  . . . . . . . . . . . . . . . . . 24
     5.3   Home agent requirements  . . . . . . . . . . . . . . . . . 24
   6.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     6.1   Comparison against guidelines  . . . . . . . . . . . . . . 25
     6.2   Packet overhead  . . . . . . . . . . . . . . . . . . . . . 26
     6.3   Latency considerations . . . . . . . . . . . . . . . . . . 27
     6.4   Firewall state considerations  . . . . . . . . . . . . . . 28
     6.5   Intrusion detection systems (IDSs) . . . . . . . . . . . . 28
     6.6   Implementation of mobile node  . . . . . . . . . . . . . . 29
     6.7   Non-IPsec VPN protocols  . . . . . . . . . . . . . . . . . 29
     6.8   Shortcomings for enterprise use  . . . . . . . . . . . . . 29
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 30
     7.1   Internal network detection . . . . . . . . . . . . . . . . 30
     7.2   Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 30
   8.  Intellectual property rights . . . . . . . . . . . . . . . . . 32




Vaarala (Ed.)            Expires March 29, 2005                 [Page 2]

Internet-Draft                 MIPv4-VPN                  September 2004



   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 33
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 35
   A.  Packet flow examples . . . . . . . . . . . . . . . . . . . . . 36
     A.1   Connection setup for access mode 'cvc' . . . . . . . . . . 36
     A.2   Connection setup for access mode 'fvc' . . . . . . . . . . 40
   B.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
       Intellectual Property and Copyright Statements . . . . . . . . 44












































Vaarala (Ed.)            Expires March 29, 2005                 [Page 3]

Internet-Draft                 MIPv4-VPN                  September 2004



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 [1].  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 and requires no changes to existing
   standards.


   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.


   There is no single solution for combining Mobile IPv4 with IPsec; by
   changing the requirements and assumptions one ends up with different
   solutions.  The solution specified in this document is most
   applicable when the assumption documented in the problem statement
   [1] are valid; among others that the solution:
   o  must minimize changes to existing firewall/VPN/DMZ deployments;
   o  must ensure that traffic is not routed through the DMZ when the
      mobile node is inside (to avoid scalability and management
      issues);
   o  must support foreign networks with only foreign agent access;
   o  should not require changes to existing IPsec or key exchange
      standards;
   o  must adhere to the Mobile IPv4 protocol (but may require new
      extensions or multiple instances of Mobile IPv4); and
   o  must propose a mechanism to avoid or minimize IPsec re-negotiation
      when mobile node moves.


   Two crucial assumptions with regards to the specified solution are
   the "existing DMZ" assumption, and the assumption that traffic cannot
   be routed through the DMZ when the mobile node is inside.  More
   optimal solutions are possible by relaxing assumptions and
   requirements; however, these are out of scope of this document.


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




Vaarala (Ed.)            Expires March 29, 2005                 [Page 4]

Internet-Draft                 MIPv4-VPN                  September 2004



   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
   [14].


   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
   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.





Vaarala (Ed.)            Expires March 29, 2005                 [Page 5]

Internet-Draft                 MIPv4-VPN                  September 2004



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 [15] which discusses the
   interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6
   signaling.  The draft also discusses dynamic updating of the IPsec
   endpoint based on Mobile IP signaling packets.


   The "transient pseudo-NAT" attack, described in [16] and [6], affects
   any approach which attempts to provide security of mobility signaling
   in conjunction with NAT devices.  In many cases, one 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
   DMZ:  (DeMilitarized Zone) A small network inserted as a "neutral
      zone" between a company's private network and the outside public
      network to prevent outside users from getting direct access to the
      company's private network
   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 [7]
   i-HoA:  home address of the mobile node in the internal home agent
   NAI:  Network Access Identifier [4]
   outside:  in the external network; each network interface may be
      independently inside or outside
   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.






Vaarala (Ed.)            Expires March 29, 2005                 [Page 6]

Internet-Draft                 MIPv4-VPN                  September 2004



   VPN tunnel:  an IPsec-based tunnel; for instance, IPsec tunnel mode
      IPsec connection, or L2TP combined with IPsec transport
      connection.
   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


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 [2].


1.6  Assumptions and rationale


   The proposed solution is an attempt to solve the problem described in
   [1].  The major assumptions and their rationale is summarized below.


   Changes to existing firewall and VPN deployments should be minimized:
   o  The current deployment of firewalls and IPsec-based VPNs is much
      larger than corresponding Mobile IPv4 elements.  Thus a solution
      should work within the existing infrastructure to be deployable in
      the short run.
   o  Current enterprise network deployments typically centralize
      management of security and network access into a compact DMZ.


   When mobile node is inside, traffic should not go through the DMZ
   network:
   o  Routing all mobile node traffic through the DMZ is seen as a
      performance problem in existing deployments of firewalls.  The
      more sophisticated firewall technology is used (e.g.  content
      scanning), the more serious the performance problem is.
   o  Current deployments of firewalls and DMZs in general have been
      optimized for the case where only a small minority of total
      enterprise traffic goes through the DMZ.  Furthermore, users of
      current VPN remote access solutions "switch off" and access their
      network without going through the DMZ when inside.


   Home agent inside the enterprise cannot be reached directly from
   outside, even if the home agent contains IPsec functionality:
   o  Deployment of current combined IPsec/MIPv4 solutions are not
      common in large installations.
   o  Doing decryption in the home agents "deep inside" the enterprise
      effectively means having a security perimeter much larger than the
      typical, compact DMZ used by a majority of enterprises today.
   o  In order to maintain a security level equal to current firewall/
      DMZ deployments, every home agent decapsulating IPsec would need
      to do the same firewalling as the current DMZ firewalls (content




Vaarala (Ed.)            Expires March 29, 2005                 [Page 7]

Internet-Draft                 MIPv4-VPN                  September 2004



      scanning, connection tracking, etc).


   Traffic cannot be encrypted when the mobile node is inside:
   o  There is a considerable performance impact on home agents (which
      currently do rather light processing), and mobile nodes
      (especially for small devices).  Note that traffic throughput
      inside the enterprise is typically order(s) of magnitude larger
      than the remote access traffic through a VPN.
   o  Encryption consumes processing power and has a consequent impact
      on device battery life.
   o  There is also a usability issue involved; the user needs to
      authenticate connection to the IPsec layer in the home agent to
      gain access.  For interactive authentication mechanisms (such as
      SecurID, which is quite widely used) this always means user
      interaction.
   o  Furthermore, if there is a separate VPN device in the DMZ for
      remote access, the user needs to authenticate to both devices, and
      might need to have separate credentials for both.
   o  Current Mobile IPv4 home agents do not typically incorporate IPsec
      functionality, which is relevant for the proposed solution when we
      assume zero or minimal changes to existing Mobile IPv4 nodes.
   o  Note, however, that the assumption (no encryption when inside)
      does not necessarily apply to all solutions in the solution space;
      if the abovementioned problems were resolved there is no
      fundamental reason why encryption could not be applied when
      inside.


1.7  Why IPsec lacks mobility


   IPsec, as currently specified [3] requires that a new IKE negotiation
   be done whenever an IPsec peer moves (i.e.  changes care-of address).
   There are multiple reasons for the limitation, outlined below.


   A security association is uni-directional, and identified by a
   triplet consisting of (1) the destination address (which is the outer
   address when tunnel mode is used), (2) the security protocol (ESP or
   AH), and (3) the Security Parameter Index (SPI) ([3], Section 4.1).
   Although an implementation is not required to use all of these for
   its own SAs, an implementation cannot assume that a peer does not.


   When a mobile IPsec peer sends packets to a stationary IPsec peer,
   there is no problem; the SA is "owned" by the stationary IPsec peer,
   and therefore the destination address does not need to change.  The
   (outer) source address should be ignored by the stationary peer
   (although some implementations do check the source address as well).


   The problem arises when packets are sent from the stationary peer to
   the mobile peer.  The destination address of this SA (SAs are




Vaarala (Ed.)            Expires March 29, 2005                 [Page 8]

Internet-Draft                 MIPv4-VPN                  September 2004



   unidirectional) is established during IKE negotiation, and is
   effectively the care-of address of the mobile peer at time of
   negotiation.  Therefore the packets will be sent to the original
   care-of address, not a changed care-of address.


   There is no standardized way of updating the destination address of
   the SA for the stationary-to-mobile direction -- other than using a
   new IKE negotiation to create a new pair of SAs.  Some vendors have
   implemented and deployed an implicit mechanism where a properly
   authenticated inbound packet received by the stationary peer causes
   the corresponding destination address (mobile peer care-of address)
   to be updated from the received packet.  This allows, in effect, for
   mobility without signaling, although having minor traffic redirection
   vulnerabilies.


   The IPsec NAT traversal mechanism can also be used for limited
   mobility, but UDP tunneling needs to be used even when there is no
   NAT in the route between the mobile and the stationary peers.
   Furthermore, support for changes in current NAT mapping is not
   required by the NAT traversal specification (draft).  Section 7 of
   [8] states:


           There are cases where NAT box decides to remove mappings that
           are still alive (for example, the keepalive interval is too
           long, or the NAT box is rebooted). To recover from those ends
           which are NOT behind NAT SHOULD use the last valid
           authenticated packet from the other end to determine which IP
           and port addresses should be used. The host behind dynamic
           NAT MUST NOT do this as otherwise it opens DoS attack
           possibility, and there is no need for that, because the IP
           address or port of other host will not change (it is not
           behind NAT).


           Keepalives cannot be used for this purposes as they are not
           authenticated, but any IKE authenticated IKE packet or ESP
           packet can be used to detect that the IP address or the port
           has changed.


   Also, if no NAT is detected during IKE negotiation, UDP encapsulation
   is not used, and consequently the endpoint updating mentioned above
   is not available.


   In summary, although the IPsec standard does not as such prevent
   mobility (in the sense of updating security associations on-the-fly),
   there is no standardized mechanism (explicit or implicit) for doing
   so.  Therefore it is assumed throughout this document that any change
   in the addresses comprising the identity of an SA requires IKE
   re-negotiation, which implies too heavy computation and too large




Vaarala (Ed.)            Expires March 29, 2005                 [Page 9]

Internet-Draft                 MIPv4-VPN                  September 2004



   latency for useful mobility.


   A standard "mobile IPsec" would be an effective replacement for the
   external Mobile IPv4 layer proposed in this document.  However, even
   if such a standard existed, there would still be the problem of
   networks where the only available access is through a Mobile IPv4
   foreign agent.













































Vaarala (Ed.)            Expires March 29, 2005                [Page 10]

Internet-Draft                 MIPv4-VPN                  September 2004



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 [7].  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 March 29, 2005                [Page 11]

Internet-Draft                 MIPv4-VPN                  September 2004



   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 tunneling 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 important when considering enterprise
   mobile users:
   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 March 29, 2005                [Page 12]

Internet-Draft                 MIPv4-VPN                  September 2004



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 signaling for the protocol layers (in the
      following order):
      *  x-MIP (if used);
      *  VPN (if used); and
      *  i-MIP.


   Note that these two tasks are intertwined to some extent: detection
   of internal network results in a successful registration to the i-HA
   using the proposed network detection algorithm, for instance.  An
   improved network detection mechanism not based on Mobile IPv4




Vaarala (Ed.)            Expires March 29, 2005                [Page 13]

Internet-Draft                 MIPv4-VPN                  September 2004



   registration messages might not have this side-effect.


   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 [5] 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 tunneling) set.
   Reverse tunneling 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 tunneling should be used to increase interoperability.


3.2  Access mode: 'f'


   This access mode is standard Mobile IPv4 [5] 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 tunneling (see
   Section 3.1).


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 tunneling)
   o  If the mobile node does not have an existing IPsec security
      association, it uses IKE to set up an IPsec security association
      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




Vaarala (Ed.)            Expires March 29, 2005                [Page 14]

Internet-Draft                 MIPv4-VPN                  September 2004



      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 tunneling)


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 tunneling)
   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 tunneling)


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 [8][9] 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 March 29, 2005                [Page 15]

Internet-Draft                 MIPv4-VPN                  September 2004



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
   Section 4.1.






Vaarala (Ed.)            Expires March 29, 2005                [Page 16]

Internet-Draft                 MIPv4-VPN                  September 2004



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
   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.







Vaarala (Ed.)            Expires March 29, 2005                [Page 17]

Internet-Draft                 MIPv4-VPN                  September 2004



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 security requirements when
   inside:
   o  The mobile node MUST NOT send or receive a user data packet (i.e.
      any IPv4 packet other than a Mobile IPv4 signaling packet) if more
      than T_MONITOR seconds has elapsed since last successful
      (re-)registration with the i-HA.
   o  If more than T_MONITOR seconds has elapsed, data packets MUST be
      either dropped or queued.  If the packets are queued, the queues
      MUST NOT be processed until the re-registration has been
      successfully completed without a connection status change.
   o  The T_MONITOR parameter MUST be configurable, and have the default
      value of 60 seconds.  This default is a trade-off between traffic
      overhead and a reasonable bound to exposure.


   A simple approach to fulfill the requirement is to start
   re-registration every T_MONITOR-N seconds when inside (where N is a
   grace period which ensures that re-registration is completed before
   T_MONITOR seconds are up).  This approach is reasonable for a wide
   range of mobile nodes (e.g.  laptops), but has unnecessary overhead
   when the mobile node is idle (not sending or receiving packets).  If
   re-registration does not complete before T_MONITOR seconds are up,
   data packets must be queued or dropped as specified above.  Note that
   re-registration packets must be sent even if bi-directional user data
   traffic is being relayed: data packets are no substitute for an
   authenticated re-registration.


   To minimize traffic overhead when the mobile node is idle,
   re-registrations can be stopped when no traffic is being sent or
   received.  If the mobile node subsequently receives or needs to send
   a packet, the packet must be dropped or queued (as specified above)
   until a re-registration with the i-HA has been successfully
   completed.  This "relaxed re-registration" approach, although adding




Vaarala (Ed.)            Expires March 29, 2005                [Page 18]

Internet-Draft                 MIPv4-VPN                  September 2004



   some packet processing complexity, may be appropriate for small
   battery powered devices which may be idle much of the time.  (Note
   that ordinary re-registration before the mobility binding lifetime is
   exhausted should still be done.)


   T_MONITOR is required to be configurable so that an administrator can
   determine the required security level for the particular deployment.
   Configuring T_MONITOR 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.


   The re-registration mechanism is a worst case fallback mechanism.  If
   additional information (such as layer two triggers) are available to
   the mobile node, the mobile node SHOULD use the triggers to detect
   when it has (potentially) moved and restart the detection process to
   minimize exposure.


   Note that re-registration is required by Mobile IPv4 by default
   (except for the untypical case of an infinite binding lifetime);
   however, the re-registration interval may be much larger when using
   an ordinary Mobile IPv4 client.  Shorter re-registration interval is
   usually not an issue, because the internal network is typically a
   fast, wired network, and the shortened re-registration interval
   applies only when the mobile node is inside the internal network.
   Furthermore, battery powered devices may use the "relaxed
   re-registration" approach to conserve power when no traffic is being
   sent or received.  When outside, the ordinary Mobile IPv4
   re-registration process (based on binding 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




Vaarala (Ed.)            Expires March 29, 2005                [Page 19]

Internet-Draft                 MIPv4-VPN                  September 2004



      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
   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.







Vaarala (Ed.)            Expires March 29, 2005                [Page 20]

Internet-Draft                 MIPv4-VPN                  September 2004



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:
   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




Vaarala (Ed.)            Expires March 29, 2005                [Page 21]

Internet-Draft                 MIPv4-VPN                  September 2004



   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
   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.5.3  No encryption when inside


   If encryption was applied also when MN was inside, there would be no
   security reason to monitor the internal network periodically.  Why,
   then, not simply mandate encryption in the internal network as well?


   Some rationale for why encryption cannot be applied when the MN is
   inside was given in Section 1.6.  In short, the main issues are (1)
   power consumption; (2) extra CPU load, especially because internal
   networks are typically switched networks and a lot of data may be
   routinely transferred; (3) existing HA devices do not typically
   integrate IPsec functionality; (4) (IPsec) encryption requires user
   authentication, which may be interactive in some cases (e.g.
   SecurID) and thus a usability issue; and (5) user may need to have
   separate credentials for VPN devices in the DMZ and the HA.


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.




Vaarala (Ed.)            Expires March 29, 2005                [Page 22]

Internet-Draft                 MIPv4-VPN                  September 2004



   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 March 29, 2005                [Page 23]

Internet-Draft                 MIPv4-VPN                  September 2004



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 [6] for both
   internal and external Mobile IP.


   The mobile node SHOULD support IPsec NAT traversal [8][9].


   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 [8][9].


5.3  Home agent requirements


   The home agent SHOULD implement the Mobile IPv4 NAT traversal
   mechanism described in [6].  (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 March 29, 2005                [Page 24]

Internet-Draft                 MIPv4-VPN                  September 2004



6.  Analysis


   This section provides a comparison against guidelines described in
   Section 6 of the problem statement [1] 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
   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.





Vaarala (Ed.)            Expires March 29, 2005                [Page 25]

Internet-Draft                 MIPv4-VPN                  September 2004



   Implications of intervening NAT gateways
   o  The solution leverages existing MIPv4 NAT traversal [6] and IPsec
      NAT traversal [8][9] 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
   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 [10]), 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 [8][9] is used and 12 octets when MIP NAT traversal [6]
   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.






Vaarala (Ed.)            Expires March 29, 2005                [Page 26]

Internet-Draft                 MIPv4-VPN                  September 2004



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
   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 [6] 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




Vaarala (Ed.)            Expires March 29, 2005                [Page 27]

Internet-Draft                 MIPv4-VPN                  September 2004



   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.


   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,




Vaarala (Ed.)            Expires March 29, 2005                [Page 28]

Internet-Draft                 MIPv4-VPN                  September 2004



   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 tunneling
   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,
   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 [6]
      solves some, but not all, fragment related issues.


   However, these are not part of the problem statement.
















Vaarala (Ed.)            Expires March 29, 2005                [Page 29]

Internet-Draft                 MIPv4-VPN                  September 2004



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 [5] 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) signaling 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 March 29, 2005                [Page 30]

Internet-Draft                 MIPv4-VPN                  September 2004



   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 [16] and [6], 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 March 29, 2005                [Page 31]

Internet-Draft                 MIPv4-VPN                  September 2004



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.


   Intel may or may not have patents or patent applications related to
   the non-mandatory mechanisms described in this document.





































Vaarala (Ed.)            Expires March 29, 2005                [Page 32]

Internet-Draft                 MIPv4-VPN                  September 2004



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 (Stinghorn)
           - 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.  Special thanks to Radia Perlman for
   giving the document a thorough read and a security review.  Tom
   Hiller pointed out issues with battery powered devices.  We would
   also like to thank the previous Mobile IP working group chairs
   (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important
   feedback and guidance.


10  References


   [1]   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.


   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.


   [3]   Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.


   [4]   Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
         2486, January 1999.


   [5]   Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August




Vaarala (Ed.)            Expires March 29, 2005                [Page 33]

Internet-Draft                 MIPv4-VPN                  September 2004



         2002.


   [6]   Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
         Address Translation (NAT) Devices", RFC 3519, April 2003.


   [7]   Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
         Lear, "Address Allocation for Private Internets", RFC 1918, BCP
         5, February 1996.


   [8]   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.


   [9]   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.


   [10]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", RFC 2406, November 1998.


   [11]  Nuopponen, A. and S. Vaarala, "Mobile IPv4 coexistence with
         IPsec remote access tunnelling
         (draft-nuopponen-vaarala-mipvpn-00, work in progress)", July
         2002.


   [12]  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.


   [13]  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.


   [14]  Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage",
         December 2002.


   [15]  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.


   [16]  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)",




Vaarala (Ed.)            Expires March 29, 2005                [Page 34]

Internet-Draft                 MIPv4-VPN                  September 2004



         December 2002.



Author's Address


   Sami Vaarala
   Stinghorn
   Elimaenkatu 12-16 6B
   Espoo  00510
   FINLAND


   Phone: +358 (0)201 4425 50
   EMail: sami.vaarala@iki.fi







































Vaarala (Ed.)            Expires March 29, 2005                [Page 35]

Internet-Draft                 MIPv4-VPN                  September 2004



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 March 29, 2005                [Page 36]

Internet-Draft                 MIPv4-VPN                  September 2004



     !          !          !          !          ! <------- !
     !          !          !          ! <==(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 March 29, 2005                [Page 37]

Internet-Draft                 MIPv4-VPN                  September 2004



           .-------------------.
           ! 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 March 29, 2005                [Page 38]

Internet-Draft                 MIPv4-VPN                  September 2004



       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 March 29, 2005                [Page 39]

Internet-Draft                 MIPv4-VPN                  September 2004



     !          !          !          !          !          !
     !  [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 March 29, 2005                [Page 40]

Internet-Draft                 MIPv4-VPN                  September 2004



     !          !  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 March 29, 2005                [Page 41]

Internet-Draft                 MIPv4-VPN                  September 2004



     !          !          !          ! <==(2)== !  pkt     !          !
     !          !          ! <==(3)== !  pkt     !          !          !
     !          ! <==(2)== !  pkt     !          !          !          !
     ! <------- !  pkt     !          !          !          !          !
     !  pkt     !          !          !          !          !          !
     :          :          :          :          :          :          :
     :          :          :          :          :          :          :













































Vaarala (Ed.)            Expires March 29, 2005                [Page 42]

Internet-Draft                 MIPv4-VPN                  September 2004



Appendix B.  Changes


   Changes from draft-ietf-mobileip-vpn-problem-solution-03 to
   draft-ietf-mip4-vpn-problem-solution-00:
   o  Renamed and resubmitted document.
   o  New boilerplate to match RFCs 3667 and 3668.


   Changes from -02 to -03:
   o  Remaining issues from security review worked into document.
   o  Short rationale for why (a) IPsec is not mobile, and (b) the
      essential problem statement assumptions added.
   o  Minor wording changes (IETF 57 comments).
   o  Internal network monitoring section revised with "relaxed
      re-registration" approach to improve applicability to battery
      powered devices.
   o  IPR section needs to refer to on-line rights (and current text
      moved on-line).  Not done yet.


   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 March 29, 2005                [Page 43]

Internet-Draft                 MIPv4-VPN                  September 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Vaarala (Ed.)            Expires March 29, 2005                [Page 44]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/