Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6252

A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization

Pages: 57
Informational
Part 2 of 3 – Pages 20 to 39
First   Prev   Next

Top   ToC   RFC6252 - Page 20   prevText

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),
Top   ToC   RFC6252 - Page 21
      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
Top   ToC   RFC6252 - Page 22
   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
Top   ToC   RFC6252 - Page 23
   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,
Top   ToC   RFC6252 - Page 24
   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
Top   ToC   RFC6252 - Page 25
   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
Top   ToC   RFC6252 - Page 26
   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
Top   ToC   RFC6252 - Page 27
   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.
Top   ToC   RFC6252 - Page 28

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.
Top   ToC   RFC6252 - Page 29

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
Top   ToC   RFC6252 - Page 30
   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].
Top   ToC   RFC6252 - Page 31

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.
Top   ToC   RFC6252 - Page 32
          _________________        ____________________________
         | 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).
Top   ToC   RFC6252 - Page 33
   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.
Top   ToC   RFC6252 - Page 34
   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.
Top   ToC   RFC6252 - Page 35
   [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.
Top   ToC   RFC6252 - Page 36

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.
Top   ToC   RFC6252 - Page 37
   [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.
Top   ToC   RFC6252 - Page 38
   [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.
Top   ToC   RFC6252 - Page 39
   [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.


(next page on part 3)

Next Section