Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6252

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

Pages: 57
Part 1 of 3 – Pages 1 to 20
None   None   Next

Top   ToC   RFC6252 - Page 1
Internet Research Task Force (IRTF)                        A. Dutta, Ed.
Request for Comments: 6252                                    V. Fajardo
Category: Informational                                           NIKSUN
ISSN: 2070-1721                                                  Y. Ohba
                                                             K. Taniuchi
                                                          H. Schulzrinne
                                                          Columbia Univ.
                                                               June 2011

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


This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document. This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the MOBOPTS Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Top   ToC   RFC6252 - Page 2
   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

1. Introduction ....................................................3 1.1. Specification of Requirements ..............................5 1.2. Performance Requirements ...................................5 2. Terminology .....................................................7 3. Handover Taxonomy ...............................................7 4. Related Work ...................................................11 5. Applicability of MPA ...........................................12 6. MPA Framework ..................................................13 6.1. Overview ..................................................13 6.2. Functional Elements .......................................14 6.3. Basic Communication Flow ..................................16 7. MPA Operations .................................................20 7.1. Discovery .................................................21 7.2. Pre-Authentication in Multiple-CTN Environment ............22 7.3. Proactive IP Address Acquisition ..........................23 7.3.1. PANA-Assisted Proactive IP Address Acquisition .....24 7.3.2. IKEv2-Assisted Proactive IP Address Acquisition ....24 7.3.3. Proactive IP Address Acquisition Using DHCPv4 Only ........................................24 7.3.4. Proactive IP Address Acquisition Using Stateless Autoconfiguration ..................................26 7.4. Tunnel Management .........................................26 7.5. Binding Update ............................................28 7.6. Preventing Packet Loss ....................................29 7.6.1. Packet Loss Prevention in Single-Interface MPA .....29 7.6.2. Preventing Packet Losses for Multiple Interfaces ...29 7.6.3. Reachability Test ..................................30
Top   ToC   RFC6252 - Page 3
      7.7. Security and Mobility .....................................31
           7.7.1. Link-Layer Security and Mobility ...................31
           7.7.2. IP-Layer Security and Mobility .....................32
      7.8. Authentication in Initial Network Attachment ..............33
   8. Security Considerations ........................................33
   9. Acknowledgments ................................................34
   10. References ....................................................34
      10.1. Normative References .....................................34
      10.2. Informative References ...................................36
   Appendix A. Proactive Duplicate Address Detection .................40
   Appendix B. Address Resolution ....................................41
   Appendix C. MPA Deployment Issues .................................42
     C.1. Considerations for Failed Switching and Switch-Back ........42
     C.2. Authentication State Management ............................43
     C.3. Pre-Allocation of QoS Resources ............................44
     C.4. Resource Allocation Issue during Pre-Authentication ........45
     C.5. Systems Evaluation and Performance Results .................47
       C.5.1. Intra-Technology, Intra-Domain .........................47
       C.5.2. Inter-Technology, Inter-Domain .........................49
       C.5.3. MPA-Assisted Layer 2 Pre-Authentication ................49
     C.6. Guidelines for Handover Preparation ........................54

1. Introduction

As wireless technologies, including cellular and wireless LANs, are becoming popular, supporting terminal handovers across different types of access networks, such as from a wireless LAN to CDMA or to General Packet Radio Service (GPRS), is considered a clear challenge. On the other hand, supporting seamless terminal handovers between access networks of the same type is still more challenging, especially when the handovers are across IP subnets or administrative domains. To address those challenges, it is important to provide terminal mobility that is agnostic to link-layer technologies in an optimized and secure fashion without incurring unreasonable complexity. In this document, we discuss a framework to support terminal mobility that provides seamless handovers with low latency and low loss. Seamless handovers are characterized in terms of performance requirements as described in Section 1.2. [MPA-WIRELESS] is an accompanying document that describes implementation of a few MPA-based systems, including performance results to show how existing protocols could be leveraged to realize the functionalities of MPA. Terminal mobility is accomplished by a mobility management protocol that maintains a binding between a locator and an identifier of a mobile node, where the binding is referred to as the mobility binding. The locator of the mobile node may dynamically change when there is a movement of the mobile node. The movement that causes a
Top   ToC   RFC6252 - Page 4
   change of the locator may occur when there is a change in attachment
   point due to physical movement or network change.  A mobility
   management protocol may be defined at any layer.  In the rest of this
   document, the term "mobility management protocol" refers to a
   mobility management protocol that operates at the network layer or

   There are several mobility management protocols at different layers.
   Mobile IP [RFC5944] and Mobile IPv6 [RFC3775] are mobility management
   protocols that operate at the network layer.  Similarly, MOBIKE
   (IKEv2 Mobility and Multihoming) [RFC4555] is an extension to the
   Internet Key Exchange Protocol (IKEv2) that provides the ability to
   deal with a change of an IP address of an IKEv2 end-point.  There are
   several ongoing activities in the IETF to define mobility management
   protocols at layers higher than the network layer.  HIP (Host
   Identity Protocol) [RFC5201] defines a new protocol layer between the
   network layer and transport layer to provide terminal mobility in a
   way that is transparent to both the network layer and transport
   layer.  Also, SIP-based mobility is an extension to SIP to maintain
   the mobility binding of a SIP user agent [SIPMM].

   While mobility management protocols maintain mobility bindings, these
   cannot provide seamless handover if used in their current form.  An
   additional optimization mechanism is needed to prevent the loss of
   in-flight packets transmitted during the mobile node's binding update
   procedure and to achieve seamless handovers.  Such a mechanism is
   referred to as a mobility optimization mechanism.  For example,
   mobility optimization mechanisms for Mobile IPv4 [RFC4881] and Mobile
   IPv6 [RFC5568] are defined to allow neighboring access routers to
   communicate and carry information about mobile terminals.  There are
   protocols that are considered as "helpers" of mobility optimization
   mechanisms.  The CARD (Candidate Access Router Discovery) protocol
   [RFC4066] is designed to discover neighboring access routers.  CXTP
   (Context Transfer Protocol) [RFC4067] is designed to carry state that
   is associated with the services provided for the mobile node, or
   context, among access routers.  In Section 4, we describe some of the
   fast-handover schemes that attempt to reduce the handover delay.

   There are several issues in existing mobility optimization
   mechanisms.  First, existing mobility optimization mechanisms are
   tightly coupled with specific mobility management protocols.  For
   example, it is not possible to use mobility optimization mechanisms
   designed for Mobile IPv4 or Mobile IPv6 with MOBIKE.  What is
   strongly desired is a single, unified mobility optimization mechanism
   that works with any mobility management protocol.  Second, there is
   no existing mobility optimization mechanism that easily supports
   handovers across administrative domains without assuming a
   pre-established security association between administrative domains.
Top   ToC   RFC6252 - Page 5
   A mobility optimization mechanism should work across administrative
   domains in a secure manner only based on a trust relationship between
   a mobile node and each administrative domain.  Third, a mobility
   optimization mechanism needs to support not only terminals with
   multiple interfaces where simultaneous connectivity through multiple
   interfaces or connectivity through a single interface can be
   expected, but also terminals with a single interface.

   This document describes a framework of Media-independent
   Pre-Authentication (MPA), a new handover optimization mechanism that
   addresses all those issues.  MPA is a mobile-assisted, secure
   handover optimization scheme that works over any link layer and with
   any mobility management protocol, including Mobile IPv4, Mobile IPv6,
   MOBIKE, HIP, and SIP mobility.  In cases of multiple operators
   without a roaming relationship or without an agreement to participate
   in a key management scheme, MPA provides a framework that can perform
   pre-authentication to establish the security mechanisms without
   assuming a common source of trust.  In MPA, the notion of IEEE
   802.11i pre-authentication is extended to work at a higher layer,
   with additional mechanisms to perform early acquisition of an IP
   address from a network where the mobile node may move, as well as
   proactive handover to the network while the mobile node is still
   attached to the current network.  Since this document focuses on the
   MPA framework, it is left to future work to choose the protocols for
   MPA and define detailed operations.  The accompanying document
   [MPA-WIRELESS] provides one method that describes usage and
   interactions between existing protocols to accomplish MPA

   This document represents the consensus of the IP Mobility
   Optimizations (MOBOPTS) Research Group.  It has been reviewed by
   Research Group members active in the specific area of work.

1.1. Specification of Requirements

In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1.2. Performance Requirements

In order to provide desirable quality of service for interactive Voice over IP (VoIP) and streaming traffic, one needs to limit the value of end-to-end delay, jitter, and packet loss to a certain threshold level. ITU-T and ITU-E standards define the acceptable values for these parameters. For example, for one-way delay, ITU-T
Top   ToC   RFC6252 - Page 6
   G.114 [RG98] recommends 150 ms as the upper limit for most of the
   applications, and 400 ms as generally unacceptable delay.  One-way
   delay tolerance for video conferencing is in the range of 200 to
   300 ms [ITU98].  Also, if an out-of-order packet is received after a
   certain threshold, it is considered lost.  According to ETSI TR 101
   [ETSI], a normal voice conversation can tolerate up to 2% packet
   loss.  But this is the mean packet loss probability and may be
   applicable to a scenario when the mobile node is subjected to
   repeated handoff during a normal conversation.  Measurement
   techniques for delay and jitter are described in [RFC2679],
   [RFC2680], and [RFC2681].

   In the case of interactive VoIP traffic, end-to-end delay affects the
   jitter value, and thus is an important issue to consider.  An end-to-
   end delay consists of several components, such as network delay,
   operating system (OS) delay, codec delay, and application delay.  A
   complete analysis of these delays can be found in [WENYU].  During a
   mobile node's handover, in-flight transient traffic cannot reach the
   mobile node because of the associated handover delay.  These
   in-flight packets could either be lost or buffered.  If the in-flight
   packets are lost, this packet loss will contribute to jitter between
   the last packet before handoff and the first packet after handoff.
   If these packets are buffered, packet loss is minimized, but there is
   additional jitter for the in-flight packets when these are flushed
   after the handoff.  Buffering during handoff avoids the packet loss,
   but at the cost of additional one-way delay.  A tradeoff between one-
   way delay and packet loss is desired based on the type of
   application.  For example, for a streaming application, packet loss
   can be reduced by increasing the playout buffer, resulting in longer
   one-way packet delay.

   The handover delay is attributed to several factors, such as
   discovery, configuration, authentication, binding update, and media
   delivery.  Many of the security-related procedures, such as handover
   keying and re-authentication procedures, deal with cases where there
   is a single source of trust at the top, and the underlying
   Authentication, Authorization, and Accounting (AAA) domain elements
   trust the top source of trust and the keys it generates and
   distributes.  In this scenario, there is an appreciable delay in
   re-establishing link-security-related parameters, such as
   authentication, link key management, and access authorization during
   inter-domain handover.  The focus of this document is the design of a
   framework that can reduce the delay due to authentication and other
   handoff-related operations such as configuration and binding update.
Top   ToC   RFC6252 - Page 7

2. Terminology

Mobility Binding: A binding between a locator and an identifier of a mobile terminal. Mobility Management Protocol (MMP): A protocol that operates at the network layer or above to maintain a binding between a locator and an identifier of a mobile node. Binding Update (BU): A procedure to update a mobility binding. Media-independent Pre-Authentication Mobile Node (MN): A mobile node using Media-independent Pre-Authentication (MPA). MPA is a mobile-assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol. An MPA mobile node is an IP node. In this document, the term "mobile node" or "MN" without a modifier refers to "MPA mobile node". An MPA mobile node usually has a functionality of a mobile node of a mobility management protocol as well. Candidate Target Network (CTN): A network to which the mobile node may move in the near future. Target Network (TN): The network to which the mobile node has decided to move. The target network is selected from one or more candidate target networks. Proactive Handover Tunnel (PHT): A bidirectional IP tunnel [RFC2003] [RFC2473] that is established between the MPA mobile node and an access router of a candidate target network. In this document, the term "tunnel" without a modifier refers to "proactive handover tunnel". Point of Attachment (PoA): A link-layer device (e.g., a switch, an access point, or a base station) that functions as a link-layer attachment point for the MPA mobile node to a network. Care-of Address (CoA): An IP address used by a mobility management protocol as a locator of the MPA mobile node.

3. Handover Taxonomy

Based on the type of movement, type of access network, and underlying mobility support, one can primarily define the handover as inter- technology, intra-technology, inter-domain, and intra-domain. We describe briefly each of these handover processes. However, our focus of the discussion is on inter-domain handover.
Top   ToC   RFC6252 - Page 8
   Inter-technology:  A mobile node may be equipped with multiple
      interfaces, where each interface can support a different access
      technology (e.g., 802.11, CDMA).  A mobile node may communicate
      with one interface at any time in order to conserve power.  During
      the handover, the mobile node may move out of the footprint of one
      access technology (e.g., 802.11) and move into the footprint of a
      different access technology (e.g., CDMA).  This will warrant
      switching of the communicating interface on the mobile node as
      well.  This type of inter-technology handover is often called
      "vertical handover", since the mobile node moves between two
      different cell sizes.

   Intra-technology:  An intra-technology handover is defined as when a
      mobile node moves within the same type of access technology, such
      as between 802.11[a,b,n] and 802.11 [a,b,n] or between CDMA1XRTT
      and CDMA1EVDO.  In this scenario, a mobile node may be equipped
      with a single interface (with multiple PHY types of the same
      technology) or with multiple interfaces.  An intra-technology
      handover may involve intra-subnet or inter-subnet movement and
      thus may need to change its L3 locator, depending upon the type of

   Inter-domain:  A domain can be defined in several ways.  But for the
      purposes of roaming, we define "domain" as an administrative
      domain that consists of networks managed by a single
      administrative entity that authenticates and authorizes a mobile
      node for accessing the networks.  An administrative entity may be
      a service provider, an enterprise, or any organization.  Thus, an
      inter-domain handover will by default be subjected to inter-subnet
      handover, and in addition it may be subjected to either inter-
      technology or intra-technology handover.  A mobile node is
      subjected to inter-subnet handover when it moves from one subnet
      (broadcast domain) to another subnet (broadcast domain).  Inter-
      domain handover will be subjected to all the transition steps a
      subnet handover goes through, and it will be subjected to
      authentication and authorization processes as well.  It is also
      likely that the type of mobility support in each administrative
      domain will be different.  For example, administrative domain A
      may have Mobile IP version 6 (MIPv6) support, while administrative
      domain B may use Proxy MIPv6 [RFC5213].

   Intra-domain:  When a mobile node's movement is confined to movement
      within an administrative domain, it is called "intra-domain
      movement".  An intra-domain movement may involve intra-subnet,
      inter-subnet, intra-technology, and inter-technology as well.
Top   ToC   RFC6252 - Page 9
   Both inter-domain and intra-domain handovers can be subjected to
   either inter-technology or intra-technology handover based on the
   network access characteristics.  Inter-domain handover requires
   authorization for acquisition or modification of resources assigned
   to a mobile node, and the authorization needs interaction with a
   central authority in a domain.  In many cases, an authorization
   procedure during inter-domain handover follows an authentication
   procedure that also requires interaction with a central authority in
   a domain.  Thus, security associations between the network entities,
   such as routers in the neighboring administrative domains, need to be
   established before any interaction takes place between these
   entities.  Similarly, an inter-domain mobility may involve different
   mobility protocols, such as MIPv6 and Proxy MIPv6, in each of its
   domains.  In that case, one needs a generalized framework to achieve
   the optimization during inter-domain handover.  Figure 1 shows a
   typical example of inter-domain mobility involving two domains,
   domain A and domain B.  It illustrates several important components,
   such as a AAA Home server (AAAH); AAA visited servers (e.g., AAAV1
   and AAAV2); an Authentication Agent (AA); a layer 3 point of
   attachment, such as an Access Router (AR); and a layer 2 point of
   attachment, such as an Access Point (AP).  Any mobile node may be
   using a specific mobility protocol and associated mobility
   optimization technique during intra-domain movement in either domain.
   But the same optimization technique may not be suitable to support
   inter-domain handover, independent of whether it uses the same or a
   different mobility protocol in either domain.
Top   ToC   RFC6252 - Page 10
                        |      +--------+             |
                        |      |        |             |
                        |      | AAAH   ------------------|
                        |      |        |             |   |
                        |      +|-------+             |   |
                        |       |                     |   |
                        |       |  Home Domain        |   |
                        |       |                     |   |
                        +-------|---------------------+   |
                                |                         |
                                |                         |
                                |                         |
   +----------------------------|---------+ +-------------|------------+
   | Domain A                   |         | | Domain B    |            |
   |                            |         | |            +|-------+    |
   |                    +-------|+        | | +-----+    |        |    |
   |                    |        |        | | |     ------ AAAV2  |    |
   |                    | AAAV1  |        | | | AA  |    |        |    |
   |      +--------------        |        | | +|----+    +--------+    |
   |      |     |       +--------+        | |  |                       |
   |      |AA   |                         | |  |---         ----       |
   |      +--|--+                         | | /    \       /    \      |
   |         |              /----\        | || AR   |-----| AR   |     |
   |        -|--           /      \       | | \    /       \    /      |
   |       /    \         | AR     |      | |  -|--         --|-       |
   |      | AR   -----------      /       | |+--|---+  +------|------+ |
   |       \    /           \--|-/        | || AP4  |  |  L2 Switch  | |
   |        -/--         +-----|------+   | ||      |  +-|---------|-+ |
   |        /            |  L2 Switch |   | |+------+    |         |   |
   |       /             +-|-------|--+   | |        +---|--+ +----|-+ |
   | +----/-+         +----|-+   +-|----+ | |        |      | |      | |
   | |      |         |      |   |      | | |        | AP5  | |AP6   | |
   | | AP1  |         | AP2  |   | AP3  | | |        +----|-+ +------+ |
   | +------+         +------+   +--|---+ | |             |            |
   +--------------------------------|-----+ +------------ |------------+
                                  --|---------            |
                              ////            \\\\   -----|-----
                            //    +------+       ////  +------+ \\\\
                            |     | MN   ------------->|MN  |     \\\
                           |      |      |    |     |  |      |       |
                            |     +------+   |     |   +------+        |
                            \\                |   //                  |
                              \\\\            \\\/                  ///
                                  ------------   \\\\------------- ////

                      Figure 1: Inter-Domain Mobility
Top   ToC   RFC6252 - Page 11

4. Related Work

While basic mobility management protocols such as Mobile IP [RFC5944], Mobile IPv6 [RFC3775], and SIP-Mobility [SIPMM] provide continuity to TCP and RTP traffic, these are not optimized to reduce the handover latency during a mobile node's movement between subnets and domains. In general, these mobility management protocols introduce handover delays incurred at several layers, such as layer 3 and the application layer, for updating the mobile node's mobility binding. These protocols are affected by underlying layer 2 delay as well. As a result, applications using these mobility protocols suffer from performance degradation. There have been several optimization techniques that apply to current mobility management schemes that try to reduce handover delay and packet loss during a mobile node's movement between cells, subnets, and domains. Micro-mobility management schemes such as [CELLIP] and [HAWAII], and intra-domain mobility management schemes such as [IDMP], [MOBIP-REG], and [RFC5380], provide fast handover by limiting the signaling updates within a domain. Fast Mobile IP protocols for IPv4 and IPv6 networks [RFC4881] [RFC5568] utilize mobility information made available by link-layer triggers. Yokota et al. [YOKOTA] propose the joint use of an access point and a dedicated Media Access Control (MAC) bridge to provide fast handover without altering the MIPv4 specification. Shin et al. [MACD] propose a scheme that reduces the delay due to MAC-layer handoff by providing a cache-based algorithm. In this scheme, the mobile node caches the neighboring channels that it has already visited and thus uses a selective scanning method. This helps to reduce the associated scanning time. Some mobility management schemes use dual interfaces, thus providing make-before-break [SUM]. In a make-before-break situation, communication usually continues with one interface when the secondary interface is in the process of getting connected. The IEEE 802.21 working group is discussing these scenarios in detail [802.21]. Providing fast handover using a single interface needs more careful design than for a client with multiple interfaces. Dutta et al. [SIPFAST] provide an optimized handover scheme for SIP-based mobility management, where the transient traffic is forwarded from the old subnet to the new one by using an application-layer forwarding scheme. [MITH] provides a fast-handover scheme for the single-interface case that uses mobile-initiated tunneling between the old Foreign Agent and a new Foreign Agent. [MITH] defines two types of handover schemes: Pre-MIT (Mobile Initiated Tunneling) and Post-MIT (Media Initiated Tunneling). The proposed MPA scheme is very similar to Mobile Initiated Tunneling Handoff's (MITH's) predictive scheme, where the mobile node communicates with the
Top   ToC   RFC6252 - Page 12
   Foreign Agent before actually moving to the new network.  However,
   the MPA scheme is not limited to MIP; this scheme takes care of
   movement between domains and performs pre-authentication in addition
   to proactive handover.  Thus, MPA reduces the overall delay to a
   period close to that of link-layer handover delay.  Most of the
   mobility optimization techniques developed so far are restricted to a
   specific type of mobility protocol only.  While supporting
   optimization for inter-domain mobility, these protocols assume that
   there is a pre-established security arrangement between two
   administrative domains.  But this assumption may not always be
   viable.  Thus, there is a need to develop an optimization mechanism
   that can support inter-domain mobility without any underlying
   constraints or security-related assumptions.

   Recently, the HOKEY working group within the IETF has been defining
   ways to expedite the authentication process.  In particular, it has
   defined pre-authentication [RFC5836] and fast re-authentication
   [RFC5169] mechanisms to expedite the authentication and security
   association process.

5. Applicability of MPA

MPA is more applicable where an accurate prediction of movement can be easily made. For other environments, special care must be taken to deal with issues such as pre-authentication to multiple CTNs (Candidate Target Networks), and failed switching and switching back as described in [MPA-WIRELESS]. However, addressing those issues in actual deployments may not be easier. Some of the deployment issues are described in Appendix C. The authors of the accompanying document [MPA-WIRELESS] have cited several use cases of how MPA can be used to optimize several network- layer and application-layer mobility protocols. The effectiveness of MPA may be relatively reduced if the network employs network- controlled localized mobility management in which the MN does not need to change its IP address while moving within the network. The effectiveness of MPA may also be relatively reduced if signaling for network access authentication is already optimized for movements within the network, e.g., when simultaneous use of multiple interfaces during handover is allowed. In other words, MPA is more viable as a solution for inter-administrative domain predictive handover without the simultaneous use of multiple interfaces. Since MPA is not tied to a specific mobility protocol, it is also applicable to support optimization for inter-domain handover where each domain may be equipped with a different mobility protocol.
Top   ToC   RFC6252 - Page 13
   Figure 1 shows an example of inter-domain mobility where MPA could be
   applied.  For example, domain A may support just Proxy MIPv6, whereas
   domain B may support Client Mobile IPv6.  MPA's different functional
   components can provide the desired optimization techniques

6. MPA Framework

6.1. Overview

Media-independent Pre-Authentication (MPA) is a mobile-assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol. With MPA, a mobile node is not only able to securely obtain an IP address and other configuration parameters for a CTN, but also able to send and receive IP packets using the IP address obtained before it actually attaches to the CTN. This makes it possible for the mobile node to complete the binding update of any mobility management protocol and use the new CoA before performing a handover at the link layer. MPA adopts the following basic procedures to provide this functionality. The first procedure is referred to as "pre-authentication", the second procedure is referred to as "pre-configuration", and the combination of the third and fourth procedures is referred to as "secure proactive handover". The security association established through pre-authentication is referred to as an "MPA-SA". This functionality is provided by allowing a mobile node that has connectivity to the current network, but is not yet attached to a CTN, to (i) establish a security association with the CTN to secure the subsequent protocol signaling, then (ii) securely execute a configuration protocol to obtain an IP address and other parameters from the CTN as well as execute a tunnel management protocol to establish a Proactive Handover Tunnel (PHT) [RFC2003] between the mobile node and an access router of the CTN, then (iii) send and receive IP packets, including signaling messages for the binding update of an MMP and data packets transmitted after completion of the binding update, over the PHT, using the obtained IP address as the tunnel inner address, and finally
Top   ToC   RFC6252 - Page 14
      (iv) delete or disable the PHT immediately before attaching to the
      CTN when it becomes the target network, and then re-assign the
      inner address of the deleted or disabled tunnel to its physical
      interface immediately after the mobile node is attached to the
      target network through the interface.  Instead of deleting or
      disabling the tunnel before attaching to the target network, the
      tunnel may be deleted or disabled immediately after being attached
      to the target network.

   Step (iii) above (i.e., the binding update procedure), in particular,
   makes it possible for the mobile node to complete the higher-layer
   handover before starting a link-layer handover.  This means that the
   mobile node is able to send and receive data packets transmitted
   after completing the binding update over the tunnel, while data
   packets transmitted before completion of the binding update do not
   use the tunnel.

6.2. Functional Elements

In the MPA framework, the following functional elements are expected to reside in each CTN to communicate with a mobile node: an Authentication Agent (AA), a Configuration Agent (CA), and an Access Router (AR). These elements can reside in one or more network devices. An authentication agent is responsible for pre-authentication. An authentication protocol is executed between the mobile node and the authentication agent to establish an MPA-SA. The authentication protocol MUST be able to establish a shared key between the mobile node and the authentication agent and SHOULD be able to provide mutual authentication. The authentication protocol SHOULD be able to interact with a AAA protocol, such as RADIUS or Diameter, to carry authentication credentials to an appropriate authentication server in the AAA infrastructure. This interaction happens through the authentication agent, such as the PANA Authentication Agent (PAA). In turn, the derived key is used to derive additional keys that will be applied to protecting message exchanges used for pre-configuration and secure proactive handover. Other keys that are used for bootstrapping link-layer and/or network-layer ciphers MAY also be derived from the MPA-SA. A protocol that can carry the Extensible Authentication Protocol (EAP) [RFC3748] would be suitable as an authentication protocol for MPA.
Top   ToC   RFC6252 - Page 15
   A configuration agent is responsible for one part of
   pre-configuration, namely securely executing a configuration protocol
   to deliver an IP address and other configuration parameters to the
   mobile node.  The signaling messages of the configuration protocol
   (e.g., DHCP) MUST be protected using a key derived from the key
   corresponding to the MPA-SA.

   An access router in the MPA framework is a router that is responsible
   for the other part of pre-configuration, i.e., securely executing a
   tunnel management protocol to establish a proactive handover tunnel
   to the mobile node.  IP packets transmitted over the proactive
   handover tunnel SHOULD be protected using a key derived from the key
   corresponding to the MPA-SA.  Details of this procedure are described
   in Section 6.3.
Top   ToC   RFC6252 - Page 16
   Figure 2 shows the basic functional components of MPA.

                                        | CN |
                              (Core Network)
                             /              \
                            /                \
          +----------------/--------+    +----\-----------------+
          | +-----+                 |    |+-----+               |
          | |     |        +-----+  |    ||     |       +-----+ |
          | | AA  |        |CA   |  |    ||AA   |       | CA  | |
          | +--+--+        +--+--+  |    |+--+--+       +--+--+ |
          |    |   +------+   |     |    |   | +-----+     |    |
          |    |   | pAR  |   |     |    |   | |nAR  |     |    |
          | ---+---+      +---+-----+----+---+-+     +-----+    |
          |        +---+--+         |    |     +-----+          |
          |            |            |    |                      |
          |            |            |    |                      |
          |            |            |    |                      |
          +------------+------------+    +--------|-------------+
          Current      |                 Candidate| Target Network
          Network      |                          |
                    +------+                  +------+
                    | oPoA |                  | nPoA |
                    +--.---+                  +--.---+
                       .                         .
                       .                         .
                    |  MN  |  ---------->

                    Figure 2: MPA Functional Components

6.3. Basic Communication Flow

Assume that the mobile node is already connected to a point of attachment, say oPoA (old point of attachment), and assigned a care-of address, say oCoA (old care-of address). The communication flow of MPA is described as follows. Throughout the communication flow, data packet loss should not occur except for the period during the switching procedure in Step 5 below, and it is the responsibility of link-layer handover to minimize packet loss during this period.
Top   ToC   RFC6252 - Page 17
   Step 1 (pre-authentication phase):  The mobile node finds a CTN
      through some discovery process, such as IEEE 802.21, and obtains
      the IP addresses of an authentication agent, a configuration
      agent, and an access router in the CTN (Candidate Target Network)
      by some means.  Details about discovery mechanisms are discussed
      in Section 7.1.  The mobile node performs pre-authentication with
      the authentication agent.  As discussed in Section 7.2, the mobile
      node may need to pre-authenticate with multiple candidate target
      networks.  The decision regarding with which candidate network the
      mobile node needs to pre-authenticate will depend upon several
      factors, such as signaling overhead, bandwidth requirement
      (Quality of Service (QoS)), the mobile node's location,
      communication cost, handover robustness, etc.  Determining the
      policy that decides the target network with which the mobile node
      should pre-authenticate is out of scope for this document.

      If the pre-authentication is successful, an MPA-SA is created
      between the mobile node and the authentication agent.  Two keys
      are derived from the MPA-SA, namely an MN-CA key and an MN-AR key,
      which are used to protect subsequent signaling messages of a
      configuration protocol and a tunnel management protocol,
      respectively.  The MN-CA key and the MN-AR key are then securely
      delivered to the configuration agent and the access router,

   Step 2 (pre-configuration phase):  The mobile node realizes that its
      point of attachment is likely to change from the oPoA to a new
      one, say nPoA (new point of attachment).  It then performs
      pre-configuration with the configuration agent, using the
      configuration protocol to obtain several configuration parameters
      such as an IP address, say nCoA (new care-of address), and a
      default router from the CTN.  The mobile node then communicates
      with the access router using the tunnel management protocol to
      establish a proactive handover tunnel.  In the tunnel management
      protocol, the mobile node registers the oCoA and the nCoA as the
      tunnel outer address and the tunnel inner address, respectively.
      The signaling messages of the pre-configuration protocol are
      protected using the MN-CA key and the MN-AR key.  When the
      configuration agent and the access router are co-located in the
      same device, the two protocols may be integrated into a single
      protocol, such as IKEv2.  After completion of the tunnel
      establishment, the mobile node is able to communicate using both
      the oCoA and the nCoA by the end of Step 4.  A configuration
      protocol and a tunnel management protocol may be combined in a
      single protocol or executed in different orders depending on the
      actual protocol(s) used for configuration and tunnel management.
Top   ToC   RFC6252 - Page 18
   Step 3 (secure proactive handover main phase):  The mobile node
      decides to switch to the new point of attachment by some means.
      Before the mobile node switches to the new point of attachment, it
      starts secure proactive handover by executing the binding update
      operation of a mobility management protocol and transmitting
      subsequent data traffic over the tunnel (main phase).  This
      proactive binding update could be triggered based on certain local
      policy at the mobile node end, after the pre-configuration phase
      is over.  This local policy could be Signal-to-Noise Ratio,
      location of the mobile node, etc.  In some cases, it may cache
      multiple nCoA addresses and perform simultaneous binding with the
      Correspondent Node (CN) or Home Agent (HA).

   Step 4 (secure proactive handover pre-switching phase):  The mobile
      node completes the binding update and becomes ready to switch to
      the new point of attachment.  The mobile node may execute the
      tunnel management protocol to delete or disable the proactive
      handover tunnel and cache the nCoA after deletion or disabling of
      the tunnel.  This transient tunnel can be deleted prior to or
      after the handover.  The buffering module at the next access
      router buffers the packets once the tunnel interface is deleted.
      The decision as to when the mobile node is ready to switch to the
      new point of attachment depends on the handover policy.

   Step 5 (switching):  It is expected that a link-layer handover occurs
      in this step.

   Step 6 (secure proactive handover post-switching phase):  The mobile
      node executes the switching procedure.  Upon successful completion
      of the switching procedure, the mobile node immediately restores
      the cached nCoA and assigns it to the physical interface attached
      to the new point of attachment.  If the proactive handover tunnel
      was not deleted or disabled in Step 4, the tunnel is deleted or
      disabled as well.  After this, direct transmission of data packets
      using the nCoA is possible without using a proactive handover

   Call flow for MPA is shown in Figures 3 and 4.
Top   ToC   RFC6252 - Page 19
                                                         IP address(es)
                                                          Available for
                                                             Use by MN
                           +-----------------------------------+   |
                           |     Candidate Target Network      |   |
                           |     (Future Target Network)       |   |
             MN       oPoA | nPoA     AA        CA        AR   |   |
             |         |   |  |       |         |         |    |   |
             |         |   +-----------------------------------+   |
             |         |      |       |         |         |        .
    +---------------+  |      |       |         |         |        .
    |(1) Found a CTN|  |      |       |         |         |        .
    +---------------+  |      |       |         |         |        |
             |   Pre-authentication   |         |         |        |
             |   [authentication protocol]      |         |        |
             |<--------+------------->|MN-CA key|         |        |
             |         |      |       |-------->|MN-AR key|        |
   +-----------------+ |      |       |------------------>|        |
   |(2) Increased    | |      |       |         |         |     [oCoA]
   |chance to switch | |      |       |         |         |        |
   |     to CTN      | |      |       |         |         |        |
   +-----------------+ |      |       |         |         |        |
             |         |      |       |         |         |        |
             |   Pre-configuration    |         |         |        |
             |   [configuration protocol to get nCoA]     |        |
             |<--------+----------------------->|         |        |
             |   Pre-configuration    |         |         |        |
             |   [tunnel management protocol to establish PHT]     V
             |         |      |       |         |         |        ^
   +-----------------+ |      |       |         |         |        |
   |(3) Determined   | |      |       |         |         |        |
   |to switch to CTN | |      |       |         |         |        |
   +-----------------+ |      |       |         |         |        |
             |         |      |       |         |         |        |
             |   Secure proactive handover main phase     |        |
             |   [execution of binding update of MMP and  |        |
             |    transmission of data packets through AR | [oCoA, nCoA]
             |    based on nCoA over the PHT]   |         |        |
             |<<=======+================================>+--->...  |
             .         .      .       .         .         .        .
             .         .      .       .         .         .        .
             .         .      .       .         .         .        .

                Figure 3: Example Communication Flow (1/2)
Top   ToC   RFC6252 - Page 20
             |         |      |       |         |         |        |
   +----------------+  |      |       |         |         |        |
   |(4) Completion  |  |      |       |         |         |        |
   |of MMP BU and   |  |      |       |         |         |        |
   |ready to switch |  |      |       |         |         |        |
   +----------------+  |      |       |         |         |        |
             |   Secure proactive handover pre-switching phase     |
             |   [tunnel management protocol to delete PHT]        V
    +---------------+         |       |         |         |
    |(5)Switching   |         |       |         |         |
    +---------------+         |       |         |         |
             |                |       |         |         |
    +---------------+         |       |         |         |
    |(6) Completion |         |       |         |         |
    |of switching   |         |       |         |         |
    +---------------+         |       |         |         |
             o<- Secure proactive handover post-switching phase ^
             |   [Re-assignment of Tunnel Inner Address   |        |
             |                 to the physical I/F]       |        |
             |                |       |         |         |        |
             |   Transmission of data packets through AR  |     [nCoA]
             |   based on nCoA|       |         |         |        |
             |<---------------+---------------------------+-->...  |
             |                |       |         |         |        .

                Figure 4: Example Communication Flow (2/2)

(page 20 continued on part 2)

Next Section