Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6252

Pages: 57
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

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

Part 1 of 3, p. 1 to 20
None       Next RFC Part


Top       ToC       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

   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.

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

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

   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       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       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       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       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       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       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 RFC Part