RFC 6252
A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization
Pages: 57
Informational
Informational
Part 1 of 3 – Pages 1 to 20
Internet Research Task Force (IRTF) A. Dutta, Ed. Request for Comments: 6252 V. Fajardo Category: Informational NIKSUN ISSN: 2070-1721 Y. Ohba K. Taniuchi Toshiba H. Schulzrinne Columbia Univ. June 2011 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover OptimizationAbstract
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.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6252. 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 (http://trustee.ietf.org/license-info) 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
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
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 higher. 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.
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 functionality. 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
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.
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.
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
movement.
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.
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.
+-----------------------------+ | +--------+ | | | | | | | 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
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
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.
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 proactively.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
(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.
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.
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 Components6.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.
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,
respectively.
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.
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
tunnel.
Call flow for MPA is shown in Figures 3 and 4.
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)
| | | | | | | +----------------+ | | | | | | |(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)