7.  MPA Operations

   In order to provide an optimized handover for a mobile node
   experiencing rapid movement between subnets and/or domains, one needs
   to look into several operations.  These issues include:

      i) discovery of neighboring networking elements,

      ii) connecting to the right network based on certain policy,

      iii) changing the layer 2 point of attachment,

      iv) obtaining an IP address from a DHCP or PPP server,

      v) confirming the uniqueness of the IP address,

      vi) pre-authenticating with the authentication agent,

      vii) sending the binding update to the Correspondent Host (CH),

      viii) obtaining the redirected streaming traffic to the new point
      of attachment,

      ix) ping-pong effect, and

      x) probability of moving to more than one network and associating
      with multiple target networks.

   We describe these issues in detail in the following paragraphs and
   describe how we have optimized these issues in the case of MPA-based
   secure proactive handover.

7.1.  Discovery

   Discovery of neighboring networking elements such as access points,
   access routers, and authentication servers helps expedite the
   handover process during a mobile node's movement between networks.
   After discovering the network neighborhood with a desired set of
   coordinates, capabilities, and parameters, the mobile node can
   perform many of the operations, such as pre-authentication, proactive
   IP address acquisition, proactive address resolution, and binding
   update, while in the previous network.

   There are several ways a mobile node can discover neighboring
   networks.  The Candidate Access Router Discovery protocol [RFC4066]
   helps discover the candidate access routers in the neighboring
   networks.  Given a certain network domain, SLP (Service Location
   Protocol) [RFC2608] and DNS help provide addresses of the networking
   components for a given set of services in the specific domain.  In
   some cases, many of the network-layer and upper-layer parameters may
   be sent over link-layer management frames, such as beacons, when the
   mobile node approaches the vicinity of the neighboring networks.
   IEEE 802.11u is considering issues such as discovering the
   neighborhood using information contained in the link layer.  However,
   if the link-layer management frames are encrypted by some link-layer
   security mechanism, then the mobile node may not be able to obtain
   the requisite information before establishing link-layer connectivity
   to the access point.  In addition, this may add burden to the
   bandwidth-constrained wireless medium.  In such cases, a higher-layer
   protocol is preferred to obtain the information regarding the
   neighboring elements.  Some proposals, such as [802.21], help obtain
   information about the neighboring networks from a mobility server.
   When the movement is imminent, the mobile node starts the discovery
   process by querying a specific server and obtains the required
   parameters, such as the IP address of the access point, its
   characteristics, routers, SIP servers, or authentication servers of
   the neighboring networks.  In the event of multiple networks, it may
   obtain the required parameters from more than one neighboring network

   and keep these in a cache.  At some point, the mobile node finds
   several CTNs out of many probable networks and starts the pre-
   authentication process by communicating with the required entities in
   the CTNs.  Further details of this scenario are in Section 7.2.

7.2.  Pre-Authentication in Multiple-CTN Environment

   In some cases, although a mobile node selects a specific network to
   be the target network, it may actually end up moving into a
   neighboring network other than the target network, due to factors
   that are beyond the mobile node's control.  Thus, it may be useful to
   perform the pre-authentication with a few probable candidate target
   networks and establish time-bound transient tunnels with the
   respective access routers in those networks.  Thus, in the event of a
   mobile node moving to a candidate target network other than that
   chosen as the target network, it will not be subjected to packet loss
   due to authentication and IP address acquisition delay that could
   occur if the mobile node did not pre-authenticate with that candidate
   target network.  It may appear that by pre-authenticating with a
   number of candidate target networks and reserving the IP addresses,
   the mobile node is reserving resources that could be used otherwise.
   But since this happens for a time-limited period, it should not be a
   big problem; it depends upon the mobility pattern and duration.  The
   mobile node uses a pre-authentication procedure to obtain an IP
   address proactively and to set up the time-bound tunnels with the
   access routers of the candidate target networks.  Also, the MN may
   retain some or all of the nCoAs for future movement.

   The mobile node may choose one of these addresses as the binding
   update address and send it to the CN (Correspondent Node) or HA (Home
   Agent), and will thus receive the tunneled traffic via the target
   network while in the previous network.  But in some instances, the
   mobile node may eventually end up moving to a network that is other
   than the target network.  Thus, there will be a disruption in traffic
   as the mobile node moves to the new network, since the mobile node
   has to go through the process of assigning the new IP address and
   sending the binding update again.  There are two solutions to this
   problem.  As one solution to the problem, the mobile node can take
   advantage of the simultaneous mobility binding and send multiple
   binding updates to the Correspondent Host or HA.  Thus, the
   Correspondent Host or HA forwards the traffic to multiple IP
   addresses assigned to the virtual interfaces for a specific period of
   time.  This binding update gets refreshed at the CH after the mobile
   node moves to the new network, thus stopping the flow to the other
   candidate networks.  RFC 5648 [RFC5648] discusses different scenarios
   of mobility binding with multiple care-of-addresses.  As the second

   solution, in case simultaneous binding is not supported in a specific
   mobility scheme, forwarding of traffic from the previous target
   network will help take care of the transient traffic until the new
   binding update is sent from the new network.

7.3.  Proactive IP Address Acquisition

   In general, a mobility management protocol works in conjunction with
   the Foreign Agent or in the co-located address mode.  The MPA
   approach can use both the co-located address mode and the Foreign
   Agent address mode.  We discuss here the address assignment component
   that is used in the co-located address mode.  There are several ways
   a mobile node can obtain an IP address and configure itself.  In some
   cases, a mobile node can configure itself statically in the absence
   of any configuration element such as a server or router in the
   network.  In a LAN environment, the mobile node can obtain an IP
   address from DHCP servers.  In the case of IPv6 networks, a mobile
   node has the option of obtaining the IP address using stateless
   autoconfiguration or DHCPv6.  In some wide-area networking
   environments, the mobile node uses PPP (Point-to-Point Protocol) to
   obtain the IP address by communicating with a NAS (Network Access
   Server).

   Each of these processes takes on the order of few hundred
   milliseconds to a few seconds, depending upon the type of IP address
   acquisition process and operating system of the clients and servers.
   Since IP address acquisition is part of the handover process, it adds
   to the handover delay, and thus it is desirable to reduce this delay
   as much as possible.  There are a few optimized techniques available,
   such as DHCP Rapid Commit [RFC4039] and GPS-coordinate-based IP
   address [GPSIP], that attempt to reduce the handover delay due to IP
   address acquisition time.  However, in all these cases, the mobile
   node also obtains the IP address after it moves to the new subnet and
   incurs some delay because of the signaling handshake between the
   mobile node and the DHCP server.

   In Fast MIPv6 [RFC5568], through the RtSolPr and PrRtAdv messages,
   the MN also formulates a prospective new CoA (nCoA) when it is still
   present on the Previous Access Router's (pAR's) link.  Hence, the
   latency due to new prefix discovery subsequent to handover is
   eliminated.  However, in this case, both the pAR and the Next Access
   Router (nAR) need to cooperate with each other to be able to retrieve
   the prefix from the target network.

   In the following paragraph, we describe a few ways that a mobile node
   can obtain the IP address proactively from the CTN, and the
   associated tunnel setup procedure.  These can broadly be divided into
   four categories: PANA-assisted proactive IP address acquisition,

   IKE-assisted proactive IP address acquisition, proactive IP address
   acquisition using DHCP only, and stateless autoconfiguration.  When
   DHCP is used for address configuration, a DHCP server is assumed to
   be serving one subnet.

7.3.1.  PANA-Assisted Proactive IP Address Acquisition

   In the case of PANA-assisted proactive IP address acquisition, the
   mobile node obtains an IP address proactively from a CTN.  The mobile
   node makes use of PANA [RFC5191] messages to trigger the IP address
   acquisition process via a DHCP client that is co-located with the
   PANA authentication agent in the access router in the CTN acting on
   behalf of the mobile node.  Upon receiving a PANA message from the
   mobile node, the DHCP client on the authentication agent performs
   normal DHCP message exchanges to obtain the IP address from the DHCP
   server in the CTN.  This address is piggy-backed in a PANA message
   and is delivered to the mobile node.  In the case of IPv6, a Router
   Advertisement (RA) is carried as part of the PANA message.  In the
   case of stateless autoconfiguration, the mobile node uses the
   prefix(es) obtained as part of the RA and its MAC address to
   construct the unique IPv6 address(es) as it would have done in the
   new network.  In the case of stateful address autoconfiguration, a
   procedure similar to DHCPv4 can be applied.

7.3.2.  IKEv2-Assisted Proactive IP Address Acquisition

   IKEv2-assisted proactive IP address acquisition works when an IPsec
   gateway and a DHCP relay agent [RFC3046] are resident within each
   access router in the CTN.  In this case, the IPsec gateway and DHCP
   relay agent in a CTN help the mobile node acquire the IP address from
   the DHCP server in the CTN.  The MN-AR key established during the
   pre-authentication phase is used as the IKEv2 pre-shared secret
   needed to run IKEv2 between the mobile node and the access router.
   The IP address from the CTN is obtained as part of the standard IKEv2
   procedure, using the co-located DHCP relay agent for obtaining the IP
   address from the DHCP server in the target network using standard
   DHCP.  The obtained IP address is sent back to the client in the
   IKEv2 Configuration Payload exchange.  In this case, IKEv2 is also
   used as the tunnel management protocol for a proactive handover
   tunnel (see Section 7.4).  Alternatively, a VPN gateway can dispense
   the IP address from its IP address pool.

7.3.3.  Proactive IP Address Acquisition Using DHCPv4 Only

   As another alternative, DHCP may be used for proactively obtaining an
   IP address from a CTN without relying on PANA or IKEv2-based
   approaches by allowing direct DHCP communication between the mobile
   node and the DHCP relay agent or DHCP server in the CTN.  The

   mechanism described in this section is applicable to DHCPv4 only.
   The mobile node sends a unicast DHCP message to the DHCP relay agent
   or DHCP server in the CTN requesting an address, while using the
   address associated with the current physical interface as the source
   address of the request.

   When the message is sent to the DHCP relay agent, the DHCP relay
   agent relays the DHCP messages back and forth between the mobile node
   and the DHCP server.  In the absence of a DHCP relay agent, the
   mobile node can also directly communicate with the DHCP server in the
   target network.  The broadcast option in the client's unicast
   DISCOVER message should be set to 0 so that the relay agent or the
   DHCP server can send the reply directly back to the mobile node using
   the mobile node's source address.

   In order to prevent malicious nodes from obtaining an IP address from
   the DHCP server, DHCP authentication should be used, or the access
   router should be configured with a filter to block unicast DHCP
   messages sent to the remote DHCP server from mobile nodes that are
   not pre-authenticated.  When DHCP authentication is used, the DHCP
   authentication key may be derived from the MPA-SA established between
   the mobile node and the authentication agent in the candidate target
   network.

   The proactively obtained IP address is not assigned to the mobile
   node's physical interface until the mobile node has moved to the new
   network.  The IP address thus obtained proactively from the target
   network should not be assigned to the physical interface but rather
   to a virtual interface of the client.  Thus, such a proactively
   acquired IP address via direct DHCP communication between the mobile
   node and the DHCP relay agent or the DHCP server in the CTN may be
   carried with additional information that is used to distinguish it
   from other addresses as assigned to the physical interface.

   Upon the mobile node's entry to the new network, the mobile node can
   perform DHCP over the physical interface to the new network to get
   other configuration parameters, such as the SIP server or DNS server,
   by using DHCP INFORM.  This should not affect the ongoing
   communication between the mobile node and Correspondent Host.  Also,
   the mobile node can perform DHCP over the physical interface to the
   new network to extend the lease of the address that was proactively
   obtained before entering the new network.

   In order to maintain the DHCP binding for the mobile node and keep
   track of the dispensed IP address before and after the secure
   proactive handover, the same DHCP client identifier needs to be used

   for the mobile node for both DHCP for proactive IP address
   acquisition and for DHCP performed after the mobile node enters the
   target network.  The DHCP client identifier may be the MAC address of
   the mobile node or some other identifier.

7.3.4.  Proactive IP Address Acquisition Using Stateless
        Autoconfiguration

   For IPv6, a network address is configured either using DHCPv6 or
   stateless autoconfiguration.  In order to obtain the new IP address
   proactively, the router advertisement of the next-hop router can be
   sent over the established tunnel, and a new IPv6 address is generated
   based on the prefix and MAC address of the mobile node.  Generating a
   CoA from the new network will avoid the time needed to obtain an IP
   address and perform Duplicate Address Detection.

   Duplicate Address Detection and address resolution are part of the IP
   address acquisition process.  As part of the proactive configuration,
   these two processes can be done ahead of time.  Details of how these
   two processes can be done proactively are described in Appendix A and
   Appendix B, respectively.

   In the case of stateless autoconfiguration, the mobile node checks to
   see the prefix of the router advertisement in the new network and
   matches it with the prefix of the newly assigned IP address.  If
   these turn out to be the same, then the mobile node does not go
   through the IP address acquisition phase again.

7.4.  Tunnel Management

   After an IP address is proactively acquired from the DHCP server in a
   CTN, or via stateless autoconfiguration in the case of IPv6, a
   proactive handover tunnel is established between the mobile node and
   the access router in the CTN.  The mobile node uses the acquired IP
   address as the tunnel's inner address.

   There are several reasons why this transient tunnel is established
   between the nAR and the mobile node in the old PoA, unlike the
   transient tunnel in FMIPv6 (Fast MIPv6) [RFC5568], where it is set up
   between the mobile node's new point of attachment and the old access
   router.

   In the case of inter-domain handoff, it is important that any
   signaling message between the nPoA and the mobile node needs to be
   secured.  This transient secured tunnel provides the desired
   functionality, including securing the proactive binding update and
   transient data between the end-points before the handover has taken
   place.  Unlike the proactive mode of FMIPv6, transient handover

   packets are not sent to the pAR, and thus a tunnel between the mobile
   node's new point of attachment and the old access router is not
   needed.

   In the case of inter-domain handoff, the pAR and nAR could logically
   be far from each other.  Thus, the signaling and data during the
   pre-authentication period will take a longer route, and thus may be
   subjected to longer one-way delay.  Hence, MPA provides a tradeoff
   between larger packet loss or larger one-way packet delay for a
   transient period, when the mobile node is preparing for handoff.

   The proactive handover tunnel is established using a tunnel
   management protocol.  When IKEv2 is used for proactive IP address
   acquisition, IKEv2 is also used as the tunnel management protocol.
   Alternatively, when PANA is used for proactive IP address
   acquisition, PANA may be used as the secure tunnel management
   protocol.

   Once the proactive handover tunnel is established between the mobile
   node and the access router in the candidate target network, the
   access router also needs to perform proxy address resolution (Proxy
   ARP) on behalf of the mobile node so that it can capture any packets
   destined to the mobile node's new address.

   Since the mobile node needs to be able to communicate with the
   Correspondent Node while in the previous network, some or all parts
   of the binding update and data from the Correspondent Node to the
   mobile node need to be sent back to the mobile node over a proactive
   handover tunnel.  Details of these binding update procedures are
   described in Section 7.5.

   In order for the traffic to be directed to the mobile node after the
   mobile node attaches to the target network, the proactive handover
   tunnel needs to be deleted or disabled.  The tunnel management
   protocol used for establishing the tunnel is used for this purpose.
   Alternatively, when PANA is used as the authentication protocol, the
   tunnel deletion or disabling at the access router can be triggered by
   means of the PANA update mechanism as soon as the mobile node moves
   to the target network.  A link-layer trigger ensures that the mobile
   node is indeed connected to the target network and can also be used
   as the trigger to delete or disable the tunnel.  A tunnel management
   protocol also triggers the router advertisement (RA) from the next
   access router to be sent over the tunnel, as soon as the tunnel
   creation is complete.

7.5.  Binding Update

   There are several kinds of binding update mechanisms for different
   mobility management schemes.

   In the case of Mobile IPv4 and Mobile IPv6, the mobile node performs
   a binding update with the Home Agent only, if route optimization is
   not used.  Otherwise, the mobile node performs the binding update
   with both the Home Agent (HA) and Correspondent Node (CN).

   In the case of SIP-based terminal mobility, the mobile node sends a
   binding update using an INVITE to the Correspondent Node and a
   REGISTER message to the Registrar.  Based on the distance between the
   mobile node and the Correspondent Node, the binding update may
   contribute to the handover delay.  SIP-fast handover [SIPFAST]
   provides several ways of reducing the handover delay due to binding
   update.  In the case of secure proactive handover using SIP-based
   mobility management, we do not encounter the delay due to the binding
   update at all, as it takes place in the previous network.

   Thus, this proactive binding update scheme looks more attractive when
   the Correspondent Node is too far from the communicating mobile node.
   Similarly, in the case of Mobile IPv6, the mobile node sends the
   newly acquired CoA from the target network as the binding update to
   the HA and CN.  Also, all signaling messages between the MN and HA
   and between the MN and CN are passed through this proactive tunnel
   that is set up.  These messages include Binding Update (BU); Binding
   Acknowledgement (BA); and the associated return routability messages,
   such as Home Test Init (HoTI), Home Test (HoT), Care-of Test Init
   (CoTI), and Care-of Test (CoT).  In Mobile IPv6, since the receipt of
   an on-link router advertisement is mandatory for the mobile node to
   detect the movement and trigger the binding update, a router
   advertisement from the next access router needs to be advertised over
   the tunnel.  By proper configuration on the nAR, the router
   advertisement can be sent over the tunnel interface to trigger the
   proactive binding update.  The mobile node also needs to make the
   tunnel interface the active interface, so that it can send the
   binding update using this interface as soon as it receives the router
   advertisement.

   If the proactive handover tunnel is realized as an IPsec tunnel, it
   will also protect these signaling messages between the tunnel end-
   points and will make the return routability test secured as well.
   Any subsequent data will also be tunneled through, as long as the
   mobile node is in the previous network.  The accompanying document
   [MPA-WIRELESS] talks about the details of how binding updates and
   signaling for return routability are sent over the secured tunnel.

7.6.  Preventing Packet Loss

   In the MPA case, packet loss due to IP address acquisition, secured
   authentication, and binding update does not occur.  However,
   transient packets during link-layer handover can be lost.  Possible
   scenarios of packet loss and its prevention are described below.

7.6.1.  Packet Loss Prevention in Single-Interface MPA

   For single-interface MPA, there may be some transient packets during
   link-layer handover that are directed to the mobile node at the old
   point of attachment before the mobile node is able to attach to the
   target network.  Those transient packets can be lost.  Buffering
   these packets at the access router of the old point of attachment can
   eliminate packet loss.  Dynamic buffering signals from the MN can
   temporarily hold transient traffic during handover, and then these
   packets can be forwarded to the MN once it attaches to the target
   network.  A detailed analysis of the buffering technique can be found
   in [PIMRC06].

   An alternative method is to use bicasting.  Bicasting helps to
   forward the traffic to two destinations at the same time.  However,
   it does not eliminate packet loss if link-layer handover is not
   seamlessly performed.  On the other hand, buffering does not reduce
   packet delay.  While packet delay can be compensated by a playout
   buffer at the receiver side for a streaming application, a playout
   buffer does not help much for interactive VoIP applications that
   cannot tolerate large delay jitters.  Thus, it is still important to
   optimize the link-layer handover anyway.

7.6.2.  Preventing Packet Losses for Multiple Interfaces

   MPA usage in multi-interface handover scenarios involves preparing
   the second interface for use via the current active interface.  This
   preparation involves pre-authentication and provisioning at a target
   network where the second interface would be the eventual active
   interface.  For example, during inter-technology handover from a WiFi
   to a CDMA network, pre-authentication at the CDMA network can be
   performed via the WiFi interface.  The actual handover occurs when
   the CDMA interface becomes the active interface for the MN.

   In such scenarios, if handover occurs while both interfaces are
   active, there is generally no packet loss, since transient packets
   directed towards the old interface will still reach the MN.  However,
   if sudden disconnection of the current active interface is used to
   initiate handover to the prepared interface, then transient packets
   for the disconnected interface will be lost while the MN attempts to
   be reachable at the prepared interface.  In such cases, a specialized

   form of buffering can be used to eliminate packet loss where packets
   are merely copied at an access router in the current active network
   prior to disconnection.  If sudden disconnection does occur, copied
   packets can be forwarded to the MN once the prepared interface
   becomes the active reachable interface.  The copy-and-forward
   mechanism is not limited to multi-interface handover.

   A notable side-effect of this process is the possible duplication of
   packets during forwarding to the new active interface.  Several
   approaches can be employed to minimize this effect.  Relying on
   upper-layer protocols such as TCP to detect and eliminate duplicates
   is the most common approach.  Customized duplicate detection and
   handling techniques can also be used.  In general, packet duplication
   is a well-known issue that can also be handled locally by the MN.

   If the mobile node takes a longer amount of time to detect the
   disconnection event of the current active interface, this can also
   have an adverse effect on the length of the handover process.  Thus,
   it becomes necessary to use an optimized scheme of detecting
   interface disconnection in such scenarios.  Use of the current
   interface to perform pre-authentication instead of the new interface
   is desirable in certain circumstances, such as to save battery power,
   or in cases where the adjacent cells (e.g., WiFi or CDMA) are
   non-overlapping, or in cases when the carrier does not allow the
   simultaneous use of both interfaces.  However, in certain
   circumstances, depending upon the type of target network, only parts
   of MPA operations can be performed (e.g., pre-authentication,
   pre-configuration, or proactive binding update).  In a specific
   scenario involving handoff between WiFi and CDMA networks, some of
   the PPP context can be set up during the pre-authentication period,
   thus reducing the time for PPP activation.

7.6.3.  Reachability Test

   In addition to previous techniques, the MN may also want to ensure
   reachability of the new point of attachment before switching from the
   old one.  This can be done by exchanging link-layer management frames
   with the new point of attachment.  This reachability check should be
   performed as quickly as possible.  In order to prevent packet loss
   during this reachability check, transmission of packets over the link
   between the MN and the old point of attachment should be suspended by
   buffering the packets at both ends of the link during the
   reachability check.  How to perform this buffering is out of scope of
   this document.  Some of the results of using this buffering scheme
   are explained in the accompanying document [MPA-WIRELESS].

7.7.  Security and Mobility

   This section describes how MPA can help establish layer 2 and layer 3
   security association in the target networks while the mobile node is
   in the previous network.

7.7.1.  Link-Layer Security and Mobility

   Using the MPA-SA established between the mobile node and the
   authentication agent for a CTN, during the pre-authentication phase,
   it is possible to bootstrap link-layer security in the CTN while the
   mobile node is in the current network, as described in the following
   steps.  Figure 5 shows the sequence of operation.

   (1)  The authentication agent and the mobile node derive a PMK (Pair-
        wise Master Key) [RFC5247] using the MPA-SA that is established
        as a result of successful pre-authentication.  Successful
        operation of EAP and a AAA protocol may be involved during
        pre-authentication to establish the MPA-SA.  From the PMK,
        distinct TSKs (Transient Session Keys) [RFC5247] for the mobile
        node are directly or indirectly derived for each point of
        attachment of the CTN.

   (2)  The authentication agent may install the keys derived from the
        PMK and used for secure association to points of attachment.
        The derived keys may be TSKs or intermediary keys from which
        TSKs are derived.

   (3)  After the mobile node chooses a CTN as the target network and
        switches to a point of attachment in the target network (which
        now becomes the new network for the mobile node), it executes a
        secure association protocol such as the IEEE 802.11i 4-way
        handshake [802.11], using the PMK in order to establish PTKs
        (Pair-wise Transient Keys) and group keys [RFC5247] used for
        protecting link-layer packets between the mobile node and the
        point of attachment.  No additional execution of EAP
        authentication is needed here.

   (4)  While the mobile node is roaming in the new network, the mobile
        node only needs to perform a secure association protocol with
        its point of attachment, and no additional execution of EAP
        authentication is needed either.  Integration of MPA with link-
        layer handover optimization mechanisms such as 802.11r can be
        archived this way.

   The mobile node may need to know the link-layer identities of the
   points of attachment in the CTN to derive TSKs.

          _________________        ____________________________
         | Current Network |      |           CTN              |
         |   ____          |      |                 ____       |
         |  |    |      (1) pre-authentication     |    |      |
         |  | MN |<------------------------------->| AA |      |
         |  |____|         |      |                |____|      |
         |    .            |      |                  |         |
         |    .            |      |                  |         |
         |____.____________|      |                  |         |
              .movement           |                  |(2) Keys |
          ____.___________________|                  |         |
         |   _v__                      _____         |         |
         |  |    |(3) secure assoc.   |     |        |         |
         |  | MN |<------------------>| AP1 |<-------+         |
         |  |____|                    |_____|        |         |
         |    .                                      |         |
         |    .movement                              |         |
         |    .                                      |         |
         |    .                                      |         |
         |   _v__                      _____         |         |
         |  |    |(4) secure assoc.   |     |        |         |
         |  | MN |<------------------>| AP2 |<-------+         |
         |  |____|                    |_____|                  |
         |_____________________________________________________|

                Figure 5: Bootstrapping Link-Layer Security

7.7.2.  IP-Layer Security and Mobility

   IP-layer security is typically maintained between the mobile node and
   the first-hop router, or any other network element such as SIP proxy
   by means of IPsec.  This IPsec SA can be set up either in tunnel mode
   or in ESP mode.  However, as the mobile node moves, the IP address of
   the router and outbound proxy will change in the new network.  The
   mobile node's IP address may or may not change, depending upon the
   mobility protocol being used.  This will warrant re-establishing a
   new security association between the mobile node and the desired
   network entity.  In some cases, such as in a 3GPP/3GPP2 IMS/MMD
   environment, data traffic is not allowed to pass through unless there
   is an IPsec SA established between the mobile node and outbound
   proxy.  This will of course add unreasonable delay to the existing
   real-time communication during a mobile node's movement.  In this
   scenario, key exchange is done as part of a SIP registration that
   follows a key exchange procedure called AKA (Authentication and Key
   Agreement).

   MPA can be used to bootstrap this security association as part of
   pre-authentication via the new outbound proxy.  Prior to the
   movement, if the mobile node can pre-register via the new outbound
   proxy in the target network and completes the pre-authentication
   procedure, then the new SA state between the mobile node and new
   outbound proxy can be established prior to the movement to the new
   network.  A similar approach can also be applied if a key exchange
   mechanism other than AKA is used or the network element with which
   the security association has to be established is different than an
   outbound proxy.

   By having the security association established ahead of time, the
   mobile node does not need to be involved in any exchange to set up
   the new security association after the movement.  Any further key
   exchange will be limited to renew the expiry time.  This will reduce
   the delay for real-time communication as well.

7.8.  Authentication in Initial Network Attachment

   When the mobile node initially attaches to a network, network access
   authentication would occur regardless of the use of MPA.  The
   protocol used for network access authentication when MPA is used for
   handover optimization can be a link-layer network access
   authentication protocol such as IEEE 802.1X, or a higher-layer
   network access authentication protocol such as PANA.

8.  Security Considerations

   This document describes a framework for a secure handover
   optimization mechanism based on performing handover-related signaling
   between a mobile node and one or more candidate target networks to
   which the mobile node may move in the future.  This framework
   involves acquisition of the resources from the CTN as well as data
   packet redirection from the CTN to the mobile node in the current
   network before the mobile node physically connects to one of those
   CTNs.

   Acquisition of the resources from the candidate target networks must
   be done with appropriate authentication and authorization procedures
   in order to prevent an unauthorized mobile node from obtaining the
   resources.  For this reason, it is important for the MPA framework to
   perform pre-authentication between the mobile node and the candidate
   target networks.  The MN-CA key and the MN-AR key generated as a
   result of successful pre-authentication can protect subsequent
   handover signaling packets and data packets exchanged between the
   mobile node and the MPA functional elements in the CTNs.

   The MPA framework also addresses security issues when the handover is
   performed across multiple administrative domains.  With MPA, it is
   possible for handover signaling to be performed based on direct
   communication between the mobile node and routers or mobility agents
   in the candidate target networks.  This eliminates the need for a
   context transfer protocol [RFC5247] for which known limitations exist
   in terms of security and authorization.  For this reason, the MPA
   framework does not require trust relationships among administrative
   domains or access routers, which makes the framework more deployable
   in the Internet without compromising the security in mobile
   environments.

9.  Acknowledgments

   We would like to thank Farooq Anjum and Raziq Yaqub for their review
   of this document, and Subir Das for standardization support in the
   IEEE 802.21 working group.

   The authors would like to acknowledge Christian Vogt, Rajeev Koodli,
   Marco Liebsch, Juergen Schoenwaelder, and Charles Perkins for their
   thorough review of the document and useful feedback.

   Author and Editor Ashutosh Dutta would like to thank Telcordia
   Technologies, and author Victor Fajardo would like to thank Toshiba
   America Research and Telcordia Technologies, for supporting the
   development of their document while they were employed in their
   respective organizations.

10.  References

10.1.  Normative References

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
              RFC 5944, November 2010.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, June 2004.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC5380]  Soliman, H., Castelluccia, C., El Malki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.

   [RFC5568]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

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

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [RFC4881]  El Malki, K., Ed., "Low-Latency Handoffs in Mobile IPv4",
              RFC 4881, June 2007.

   [RFC4066]  Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D.,
              and E. Shim, "Candidate Access Router Discovery (CARD)",
              RFC 4066, July 2005.

   [RFC4067]  Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
              "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, August 2008.

   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, May 2008.

   [RG98]     ITU-T, "General Characteristics of International Telephone
              Connections and International Telephone Circuits: One-Way
              Transmission Time", ITU-T Recommendation G.114, 1998.

   [ITU98]    ITU-T, "The E-Model, a computational model for use in
              transmission planning", ITU-T Recommendation G.107, 1998.

   [ETSI]     ETSI, "Telecommunications and Internet Protocol
              Harmonization Over Networks (TIPHON) Release 3; End-to-end
              Quality of Service in TIPHON systems; Part 1: General
              aspects of Quality of Service (QoS)", ETSI TR 101
              329-1 V3.1.2, 2002.

10.2.  Informative References

   [RFC5201]      Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
                  Henderson, "Host Identity Protocol", RFC 5201,
                  April 2008.

   [RFC2679]      Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
                  Delay Metric for IPPM", RFC 2679, September 1999.

   [RFC2680]      Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
                  Packet Loss Metric for IPPM", RFC 2680,
                  September 1999.

   [RFC2681]      Almes, G., Kalidindi, S., and M. Zekauskas, "A
                  Round-trip Delay Metric for IPPM", RFC 2681,
                  September 1999.

   [RFC2003]      Perkins, C., "IP Encapsulation within IP", RFC 2003,
                  October 1996.

   [RFC2608]      Guttman, E., Perkins, C., Veizades, J., and M. Day,
                  "Service Location Protocol, Version 2", RFC 2608,
                  June 1999.

   [RFC2473]      Conta, A. and S. Deering, "Generic Packet Tunneling in
                  IPv6 Specification", RFC 2473, December 1998.

   [RFC3046]      Patrick, M., "DHCP Relay Agent Information Option",
                  RFC 3046, January 2001.

   [RFC4039]      Park, S., Kim, P., and B. Volz, "Rapid Commit Option
                  for the Dynamic Host Configuration Protocol version 4
                  (DHCPv4)", RFC 4039, March 2005.

   [RFC5172]      Varada, S., Ed., "Negotiation for IPv6 Datagram
                  Compression Using IPv6 Control Protocol", RFC 5172,
                  March 2008.

   [RFC5648]      Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G.,
                  Ernst, T., and K. Nagami, "Multiple Care-of Addresses
                  Registration", RFC 5648, October 2009.

   [RFC4429]      Moore, N., "Optimistic Duplicate Address Detection
                  (DAD) for IPv6", RFC 4429, April 2006.

   [RFC5836]      Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed.,
                  "Extensible Authentication Protocol (EAP) Early
                  Authentication Problem Statement", RFC 5836,
                  April 2010.

   [RFC5213]      Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
                  Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
                  RFC 5213, August 2008.

   [RFC5974]      Manner, J., Karagiannis, G., and A. McDonald, "NSIS
                  Signaling Layer Protocol (NSLP) for Quality-of-Service
                  Signaling", RFC 5974, October 2010.

   [RFC5169]      Clancy, T., Nakhjiri, M., Narayanan, V., and L.
                  Dondeti, "Handover Key Management and
                  Re-Authentication Problem Statement", RFC 5169,
                  March 2008.

   [SIPMM]        Schulzrinne, H. and E. Wedlund, "Application-Layer
                  Mobility Using SIP", ACM MC2R, July 2000.

   [CELLIP]       Campbell, A., Gomez, J., Kim, S., Valko, A., Wan, C.,
                  and Z. Turanyi, "Design, Implementation, and
                  Evaluation of Cellular IP", IEEE Personal
                  Communications, August 2000.

   [MOBIQUIT07]   Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and
                  A.  Skarmeta, "Network-layer assisted mechanism to
                  optimize authentication delay during handoff in 802.11
                  networks", IEEE Mobiquitous, June 2007.

   [MISHRA04]     Mishra, A., Shin, M., Petroni, N., Clancy, T., and W.
                  Arbaugh, "Proactive key distribution using neighbor
                  graphs", IEEE Wireless Communications Magazine,
                  February 2004.

   [SPRINGER07]   Dutta, A., Das, S., Famolari, D., Ohba, Y., Taniuchi,
                  K., Fajardo, V., Lopez, R., Kodama, T., Schulzrinne,
                  H., and A. Skarmeta, "Seamless proactive handover
                  across heterogeneous access networks", Wireless
                  Personal Communications, November 2007.

   [HAWAII]       Ramjee, R., La Porta, T., Thuel, S., Varadhan, K., and
                  S.  Wang, "HAWAII: A Domain-based Approach for
                  Supporting Mobility in Wide-area Wireless networks",
                  International Conference on Network Protocols ICNP'99.

   [IDMP]         Das, S., McAuley, A., Dutta, A., Misra, A.,
                  Chakraborty, K., and S. Das, "IDMP: An Intra-Domain
                  Mobility Management Protocol for Next Generation
                  Wireless Networks", IEEE Wireless Communications
                  Magazine, October 2000.

   [MOBIP-REG]    Gustafsson, E., Jonsson, A., and C. Perkins, "Mobile
                  IPv4 Regional Registration", Work in Progress,
                  June 2004.

   [YOKOTA]       Yokota, H., Idoue, A., Hasegawa, T., and T. Kato,
                  "Link Layer Assisted Mobile IP Fast Handoff Method
                  over Wireless LAN Networks", Proceedings of ACM
                  MobiCom02, 2002.

   [MACD]         Shin, S., Forte, A., Rawat, A., and H. Schulzrinne,
                  "Reducing MAC Layer Handoff Latency in IEEE 802.11
                  Wireless LANs", MobiWac Workshop, 2004.

   [SUM]          Dutta, A., Zhang, T., Madhani, S., Taniuchi, K.,
                  Fujimoto, K., Katsube, Y., Ohba, Y., and H.
                  Schulzrinne, "Secured Universal Mobility for Wireless
                  Internet", WMASH'04, October 2004.

   [SIPFAST]      Dutta, A., Madhani, S., Chen, W., Altintas, O., and H.
                  Schulzrinne, "Fast-handoff Schemes for Application
                  Layer Mobility Management", PIMRC 2004.

   [PIMRC06]      Dutta, A., Berg, E., Famolari, D., Fajardo, V., Ohba,
                  Y., Taniuchi, K., Kodama, T., and H. Schulzrinne,
                  "Dynamic Buffering Control Scheme for Mobile Handoff",
                  Proceedings of PIMRC 2006, 1-11.

   [MITH]         Gwon, Y., Fu, G., and R. Jain, "Fast Handoffs in
                  Wireless LAN Networks using Mobile initiated Tunneling
                  Handoff Protocol for IPv4 (MITHv4)", Wireless
                  Communications and Networking 2003, January 2005.

   [WENYU]        Jiang, W. and H. Schulzrinne, "Modeling of Packet Loss
                  and Delay and their Effect on Real-Time Multimedia
                  Service Quality", NOSSDAV 2000, June 2000.

   [802.21]       "IEEE Standard for Local and Metropolitan Area
                  Networks: Media Independent Handover Services, IEEE
                  802.21-2008", a contribution to IEEE 802.21 WG,
                  January 2009.

   [802.11]       "IEEE Wireless LAN Edition A compilation based on IEEE
                  Std 802.11-1999(R2003)", Institute of Electrical and
                  Electronics Engineers, September 2003.

   [GPSIP]        Dutta, A., Madhani, S., Chen, W., Altintas, O., and H.
                  Schulzrinne, "GPS-IP based fast-handoff approaches for
                  Mobiles", IEEE Sarnoff Symposium 2006.

   [MAGUIRE]      Vatn, J. and G. Maguire, "The effect of using
                  co-located care-of addresses on macro handover
                  latency", 14th Nordic Teletraffic Seminar 1998.

   [MPA-MOBIKE]   El Mghazli, Y., Bournelle, J., and J. Laganier, "MPA
                  using IKEv2 and MOBIKE", Work in Progress, June 2006.

   [MPA-WIRELESS] Dutta, A., Famolari, D., Das, S., Ohba, Y., Fajardo,
                  V., Taniuchi, K., Lopez, R., and H. Schulzrinne,
                  "Media- Independent Pre-authentication Supporting
                  Secure Interdomain Handover Optimization", IEEE
                  Wireless Communications Magazine, April 2008.