7. MPA Operations
In order to provide an optimized handover for a mobile node
experiencing rapid movement between subnets and/or domains, one needs
to look into several operations. These issues include:
i) discovery of neighboring networking elements,
ii) connecting to the right network based on certain policy,
iii) changing the layer 2 point of attachment,
iv) obtaining an IP address from a DHCP or PPP server,
v) confirming the uniqueness of the IP address,
vi) pre-authenticating with the authentication agent,
vii) sending the binding update to the Correspondent Host (CH),
viii) obtaining the redirected streaming traffic to the new point
ix) ping-pong effect, and
x) probability of moving to more than one network and associating
with multiple target networks.
We describe these issues in detail in the following paragraphs and
describe how we have optimized these issues in the case of MPA-based
secure proactive handover.
Discovery of neighboring networking elements such as access points,
access routers, and authentication servers helps expedite the
handover process during a mobile node's movement between networks.
After discovering the network neighborhood with a desired set of
coordinates, capabilities, and parameters, the mobile node can
perform many of the operations, such as pre-authentication, proactive
IP address acquisition, proactive address resolution, and binding
update, while in the previous network.
There are several ways a mobile node can discover neighboring
networks. The Candidate Access Router Discovery protocol [RFC4066]
helps discover the candidate access routers in the neighboring
networks. Given a certain network domain, SLP (Service Location
Protocol) [RFC2608] and DNS help provide addresses of the networking
components for a given set of services in the specific domain. In
some cases, many of the network-layer and upper-layer parameters may
be sent over link-layer management frames, such as beacons, when the
mobile node approaches the vicinity of the neighboring networks.
IEEE 802.11u is considering issues such as discovering the
neighborhood using information contained in the link layer. However,
if the link-layer management frames are encrypted by some link-layer
security mechanism, then the mobile node may not be able to obtain
the requisite information before establishing link-layer connectivity
to the access point. In addition, this may add burden to the
bandwidth-constrained wireless medium. In such cases, a higher-layer
protocol is preferred to obtain the information regarding the
neighboring elements. Some proposals, such as [802.21], help obtain
information about the neighboring networks from a mobility server.
When the movement is imminent, the mobile node starts the discovery
process by querying a specific server and obtains the required
parameters, such as the IP address of the access point, its
characteristics, routers, SIP servers, or authentication servers of
the neighboring networks. In the event of multiple networks, it may
obtain the required parameters from more than one neighboring network
and keep these in a cache. At some point, the mobile node finds
several CTNs out of many probable networks and starts the pre-
authentication process by communicating with the required entities in
the CTNs. Further details of this scenario are in Section 7.2.
7.2. Pre-Authentication in Multiple-CTN Environment
In some cases, although a mobile node selects a specific network to
be the target network, it may actually end up moving into a
neighboring network other than the target network, due to factors
that are beyond the mobile node's control. Thus, it may be useful to
perform the pre-authentication with a few probable candidate target
networks and establish time-bound transient tunnels with the
respective access routers in those networks. Thus, in the event of a
mobile node moving to a candidate target network other than that
chosen as the target network, it will not be subjected to packet loss
due to authentication and IP address acquisition delay that could
occur if the mobile node did not pre-authenticate with that candidate
target network. It may appear that by pre-authenticating with a
number of candidate target networks and reserving the IP addresses,
the mobile node is reserving resources that could be used otherwise.
But since this happens for a time-limited period, it should not be a
big problem; it depends upon the mobility pattern and duration. The
mobile node uses a pre-authentication procedure to obtain an IP
address proactively and to set up the time-bound tunnels with the
access routers of the candidate target networks. Also, the MN may
retain some or all of the nCoAs for future movement.
The mobile node may choose one of these addresses as the binding
update address and send it to the CN (Correspondent Node) or HA (Home
Agent), and will thus receive the tunneled traffic via the target
network while in the previous network. But in some instances, the
mobile node may eventually end up moving to a network that is other
than the target network. Thus, there will be a disruption in traffic
as the mobile node moves to the new network, since the mobile node
has to go through the process of assigning the new IP address and
sending the binding update again. There are two solutions to this
problem. As one solution to the problem, the mobile node can take
advantage of the simultaneous mobility binding and send multiple
binding updates to the Correspondent Host or HA. Thus, the
Correspondent Host or HA forwards the traffic to multiple IP
addresses assigned to the virtual interfaces for a specific period of
time. This binding update gets refreshed at the CH after the mobile
node moves to the new network, thus stopping the flow to the other
candidate networks. RFC 5648 [RFC5648] discusses different scenarios
of mobility binding with multiple care-of-addresses. As the second
solution, in case simultaneous binding is not supported in a specific
mobility scheme, forwarding of traffic from the previous target
network will help take care of the transient traffic until the new
binding update is sent from the new network.
7.3. Proactive IP Address Acquisition
In general, a mobility management protocol works in conjunction with
the Foreign Agent or in the co-located address mode. The MPA
approach can use both the co-located address mode and the Foreign
Agent address mode. We discuss here the address assignment component
that is used in the co-located address mode. There are several ways
a mobile node can obtain an IP address and configure itself. In some
cases, a mobile node can configure itself statically in the absence
of any configuration element such as a server or router in the
network. In a LAN environment, the mobile node can obtain an IP
address from DHCP servers. In the case of IPv6 networks, a mobile
node has the option of obtaining the IP address using stateless
autoconfiguration or DHCPv6. In some wide-area networking
environments, the mobile node uses PPP (Point-to-Point Protocol) to
obtain the IP address by communicating with a NAS (Network Access
Each of these processes takes on the order of few hundred
milliseconds to a few seconds, depending upon the type of IP address
acquisition process and operating system of the clients and servers.
Since IP address acquisition is part of the handover process, it adds
to the handover delay, and thus it is desirable to reduce this delay
as much as possible. There are a few optimized techniques available,
such as DHCP Rapid Commit [RFC4039] and GPS-coordinate-based IP
address [GPSIP], that attempt to reduce the handover delay due to IP
address acquisition time. However, in all these cases, the mobile
node also obtains the IP address after it moves to the new subnet and
incurs some delay because of the signaling handshake between the
mobile node and the DHCP server.
In Fast MIPv6 [RFC5568], through the RtSolPr and PrRtAdv messages,
the MN also formulates a prospective new CoA (nCoA) when it is still
present on the Previous Access Router's (pAR's) link. Hence, the
latency due to new prefix discovery subsequent to handover is
eliminated. However, in this case, both the pAR and the Next Access
Router (nAR) need to cooperate with each other to be able to retrieve
the prefix from the target network.
In the following paragraph, we describe a few ways that a mobile node
can obtain the IP address proactively from the CTN, and the
associated tunnel setup procedure. These can broadly be divided into
four categories: PANA-assisted proactive IP address acquisition,
IKE-assisted proactive IP address acquisition, proactive IP address
acquisition using DHCP only, and stateless autoconfiguration. When
DHCP is used for address configuration, a DHCP server is assumed to
be serving one subnet.
7.3.1. PANA-Assisted Proactive IP Address Acquisition
In the case of PANA-assisted proactive IP address acquisition, the
mobile node obtains an IP address proactively from a CTN. The mobile
node makes use of PANA [RFC5191] messages to trigger the IP address
acquisition process via a DHCP client that is co-located with the
PANA authentication agent in the access router in the CTN acting on
behalf of the mobile node. Upon receiving a PANA message from the
mobile node, the DHCP client on the authentication agent performs
normal DHCP message exchanges to obtain the IP address from the DHCP
server in the CTN. This address is piggy-backed in a PANA message
and is delivered to the mobile node. In the case of IPv6, a Router
Advertisement (RA) is carried as part of the PANA message. In the
case of stateless autoconfiguration, the mobile node uses the
prefix(es) obtained as part of the RA and its MAC address to
construct the unique IPv6 address(es) as it would have done in the
new network. In the case of stateful address autoconfiguration, a
procedure similar to DHCPv4 can be applied.
7.3.2. IKEv2-Assisted Proactive IP Address Acquisition
IKEv2-assisted proactive IP address acquisition works when an IPsec
gateway and a DHCP relay agent [RFC3046] are resident within each
access router in the CTN. In this case, the IPsec gateway and DHCP
relay agent in a CTN help the mobile node acquire the IP address from
the DHCP server in the CTN. The MN-AR key established during the
pre-authentication phase is used as the IKEv2 pre-shared secret
needed to run IKEv2 between the mobile node and the access router.
The IP address from the CTN is obtained as part of the standard IKEv2
procedure, using the co-located DHCP relay agent for obtaining the IP
address from the DHCP server in the target network using standard
DHCP. The obtained IP address is sent back to the client in the
IKEv2 Configuration Payload exchange. In this case, IKEv2 is also
used as the tunnel management protocol for a proactive handover
tunnel (see Section 7.4). Alternatively, a VPN gateway can dispense
the IP address from its IP address pool.
7.3.3. Proactive IP Address Acquisition Using DHCPv4 Only
As another alternative, DHCP may be used for proactively obtaining an
IP address from a CTN without relying on PANA or IKEv2-based
approaches by allowing direct DHCP communication between the mobile
node and the DHCP relay agent or DHCP server in the CTN. The
mechanism described in this section is applicable to DHCPv4 only.
The mobile node sends a unicast DHCP message to the DHCP relay agent
or DHCP server in the CTN requesting an address, while using the
address associated with the current physical interface as the source
address of the request.
When the message is sent to the DHCP relay agent, the DHCP relay
agent relays the DHCP messages back and forth between the mobile node
and the DHCP server. In the absence of a DHCP relay agent, the
mobile node can also directly communicate with the DHCP server in the
target network. The broadcast option in the client's unicast
DISCOVER message should be set to 0 so that the relay agent or the
DHCP server can send the reply directly back to the mobile node using
the mobile node's source address.
In order to prevent malicious nodes from obtaining an IP address from
the DHCP server, DHCP authentication should be used, or the access
router should be configured with a filter to block unicast DHCP
messages sent to the remote DHCP server from mobile nodes that are
not pre-authenticated. When DHCP authentication is used, the DHCP
authentication key may be derived from the MPA-SA established between
the mobile node and the authentication agent in the candidate target
The proactively obtained IP address is not assigned to the mobile
node's physical interface until the mobile node has moved to the new
network. The IP address thus obtained proactively from the target
network should not be assigned to the physical interface but rather
to a virtual interface of the client. Thus, such a proactively
acquired IP address via direct DHCP communication between the mobile
node and the DHCP relay agent or the DHCP server in the CTN may be
carried with additional information that is used to distinguish it
from other addresses as assigned to the physical interface.
Upon the mobile node's entry to the new network, the mobile node can
perform DHCP over the physical interface to the new network to get
other configuration parameters, such as the SIP server or DNS server,
by using DHCP INFORM. This should not affect the ongoing
communication between the mobile node and Correspondent Host. Also,
the mobile node can perform DHCP over the physical interface to the
new network to extend the lease of the address that was proactively
obtained before entering the new network.
In order to maintain the DHCP binding for the mobile node and keep
track of the dispensed IP address before and after the secure
proactive handover, the same DHCP client identifier needs to be used
for the mobile node for both DHCP for proactive IP address
acquisition and for DHCP performed after the mobile node enters the
target network. The DHCP client identifier may be the MAC address of
the mobile node or some other identifier.
7.3.4. Proactive IP Address Acquisition Using Stateless
For IPv6, a network address is configured either using DHCPv6 or
stateless autoconfiguration. In order to obtain the new IP address
proactively, the router advertisement of the next-hop router can be
sent over the established tunnel, and a new IPv6 address is generated
based on the prefix and MAC address of the mobile node. Generating a
CoA from the new network will avoid the time needed to obtain an IP
address and perform Duplicate Address Detection.
Duplicate Address Detection and address resolution are part of the IP
address acquisition process. As part of the proactive configuration,
these two processes can be done ahead of time. Details of how these
two processes can be done proactively are described in Appendix A and
Appendix B, respectively.
In the case of stateless autoconfiguration, the mobile node checks to
see the prefix of the router advertisement in the new network and
matches it with the prefix of the newly assigned IP address. If
these turn out to be the same, then the mobile node does not go
through the IP address acquisition phase again.
7.4. Tunnel Management
After an IP address is proactively acquired from the DHCP server in a
CTN, or via stateless autoconfiguration in the case of IPv6, a
proactive handover tunnel is established between the mobile node and
the access router in the CTN. The mobile node uses the acquired IP
address as the tunnel's inner address.
There are several reasons why this transient tunnel is established
between the nAR and the mobile node in the old PoA, unlike the
transient tunnel in FMIPv6 (Fast MIPv6) [RFC5568], where it is set up
between the mobile node's new point of attachment and the old access
In the case of inter-domain handoff, it is important that any
signaling message between the nPoA and the mobile node needs to be
secured. This transient secured tunnel provides the desired
functionality, including securing the proactive binding update and
transient data between the end-points before the handover has taken
place. Unlike the proactive mode of FMIPv6, transient handover
packets are not sent to the pAR, and thus a tunnel between the mobile
node's new point of attachment and the old access router is not
In the case of inter-domain handoff, the pAR and nAR could logically
be far from each other. Thus, the signaling and data during the
pre-authentication period will take a longer route, and thus may be
subjected to longer one-way delay. Hence, MPA provides a tradeoff
between larger packet loss or larger one-way packet delay for a
transient period, when the mobile node is preparing for handoff.
The proactive handover tunnel is established using a tunnel
management protocol. When IKEv2 is used for proactive IP address
acquisition, IKEv2 is also used as the tunnel management protocol.
Alternatively, when PANA is used for proactive IP address
acquisition, PANA may be used as the secure tunnel management
Once the proactive handover tunnel is established between the mobile
node and the access router in the candidate target network, the
access router also needs to perform proxy address resolution (Proxy
ARP) on behalf of the mobile node so that it can capture any packets
destined to the mobile node's new address.
Since the mobile node needs to be able to communicate with the
Correspondent Node while in the previous network, some or all parts
of the binding update and data from the Correspondent Node to the
mobile node need to be sent back to the mobile node over a proactive
handover tunnel. Details of these binding update procedures are
described in Section 7.5.
In order for the traffic to be directed to the mobile node after the
mobile node attaches to the target network, the proactive handover
tunnel needs to be deleted or disabled. The tunnel management
protocol used for establishing the tunnel is used for this purpose.
Alternatively, when PANA is used as the authentication protocol, the
tunnel deletion or disabling at the access router can be triggered by
means of the PANA update mechanism as soon as the mobile node moves
to the target network. A link-layer trigger ensures that the mobile
node is indeed connected to the target network and can also be used
as the trigger to delete or disable the tunnel. A tunnel management
protocol also triggers the router advertisement (RA) from the next
access router to be sent over the tunnel, as soon as the tunnel
creation is complete.
7.5. Binding Update
There are several kinds of binding update mechanisms for different
mobility management schemes.
In the case of Mobile IPv4 and Mobile IPv6, the mobile node performs
a binding update with the Home Agent only, if route optimization is
not used. Otherwise, the mobile node performs the binding update
with both the Home Agent (HA) and Correspondent Node (CN).
In the case of SIP-based terminal mobility, the mobile node sends a
binding update using an INVITE to the Correspondent Node and a
REGISTER message to the Registrar. Based on the distance between the
mobile node and the Correspondent Node, the binding update may
contribute to the handover delay. SIP-fast handover [SIPFAST]
provides several ways of reducing the handover delay due to binding
update. In the case of secure proactive handover using SIP-based
mobility management, we do not encounter the delay due to the binding
update at all, as it takes place in the previous network.
Thus, this proactive binding update scheme looks more attractive when
the Correspondent Node is too far from the communicating mobile node.
Similarly, in the case of Mobile IPv6, the mobile node sends the
newly acquired CoA from the target network as the binding update to
the HA and CN. Also, all signaling messages between the MN and HA
and between the MN and CN are passed through this proactive tunnel
that is set up. These messages include Binding Update (BU); Binding
Acknowledgement (BA); and the associated return routability messages,
such as Home Test Init (HoTI), Home Test (HoT), Care-of Test Init
(CoTI), and Care-of Test (CoT). In Mobile IPv6, since the receipt of
an on-link router advertisement is mandatory for the mobile node to
detect the movement and trigger the binding update, a router
advertisement from the next access router needs to be advertised over
the tunnel. By proper configuration on the nAR, the router
advertisement can be sent over the tunnel interface to trigger the
proactive binding update. The mobile node also needs to make the
tunnel interface the active interface, so that it can send the
binding update using this interface as soon as it receives the router
If the proactive handover tunnel is realized as an IPsec tunnel, it
will also protect these signaling messages between the tunnel end-
points and will make the return routability test secured as well.
Any subsequent data will also be tunneled through, as long as the
mobile node is in the previous network. The accompanying document
[MPA-WIRELESS] talks about the details of how binding updates and
signaling for return routability are sent over the secured tunnel.
7.6. Preventing Packet Loss
In the MPA case, packet loss due to IP address acquisition, secured
authentication, and binding update does not occur. However,
transient packets during link-layer handover can be lost. Possible
scenarios of packet loss and its prevention are described below.
7.6.1. Packet Loss Prevention in Single-Interface MPA
For single-interface MPA, there may be some transient packets during
link-layer handover that are directed to the mobile node at the old
point of attachment before the mobile node is able to attach to the
target network. Those transient packets can be lost. Buffering
these packets at the access router of the old point of attachment can
eliminate packet loss. Dynamic buffering signals from the MN can
temporarily hold transient traffic during handover, and then these
packets can be forwarded to the MN once it attaches to the target
network. A detailed analysis of the buffering technique can be found
An alternative method is to use bicasting. Bicasting helps to
forward the traffic to two destinations at the same time. However,
it does not eliminate packet loss if link-layer handover is not
seamlessly performed. On the other hand, buffering does not reduce
packet delay. While packet delay can be compensated by a playout
buffer at the receiver side for a streaming application, a playout
buffer does not help much for interactive VoIP applications that
cannot tolerate large delay jitters. Thus, it is still important to
optimize the link-layer handover anyway.
7.6.2. Preventing Packet Losses for Multiple Interfaces
MPA usage in multi-interface handover scenarios involves preparing
the second interface for use via the current active interface. This
preparation involves pre-authentication and provisioning at a target
network where the second interface would be the eventual active
interface. For example, during inter-technology handover from a WiFi
to a CDMA network, pre-authentication at the CDMA network can be
performed via the WiFi interface. The actual handover occurs when
the CDMA interface becomes the active interface for the MN.
In such scenarios, if handover occurs while both interfaces are
active, there is generally no packet loss, since transient packets
directed towards the old interface will still reach the MN. However,
if sudden disconnection of the current active interface is used to
initiate handover to the prepared interface, then transient packets
for the disconnected interface will be lost while the MN attempts to
be reachable at the prepared interface. In such cases, a specialized
form of buffering can be used to eliminate packet loss where packets
are merely copied at an access router in the current active network
prior to disconnection. If sudden disconnection does occur, copied
packets can be forwarded to the MN once the prepared interface
becomes the active reachable interface. The copy-and-forward
mechanism is not limited to multi-interface handover.
A notable side-effect of this process is the possible duplication of
packets during forwarding to the new active interface. Several
approaches can be employed to minimize this effect. Relying on
upper-layer protocols such as TCP to detect and eliminate duplicates
is the most common approach. Customized duplicate detection and
handling techniques can also be used. In general, packet duplication
is a well-known issue that can also be handled locally by the MN.
If the mobile node takes a longer amount of time to detect the
disconnection event of the current active interface, this can also
have an adverse effect on the length of the handover process. Thus,
it becomes necessary to use an optimized scheme of detecting
interface disconnection in such scenarios. Use of the current
interface to perform pre-authentication instead of the new interface
is desirable in certain circumstances, such as to save battery power,
or in cases where the adjacent cells (e.g., WiFi or CDMA) are
non-overlapping, or in cases when the carrier does not allow the
simultaneous use of both interfaces. However, in certain
circumstances, depending upon the type of target network, only parts
of MPA operations can be performed (e.g., pre-authentication,
pre-configuration, or proactive binding update). In a specific
scenario involving handoff between WiFi and CDMA networks, some of
the PPP context can be set up during the pre-authentication period,
thus reducing the time for PPP activation.
7.6.3. Reachability Test
In addition to previous techniques, the MN may also want to ensure
reachability of the new point of attachment before switching from the
old one. This can be done by exchanging link-layer management frames
with the new point of attachment. This reachability check should be
performed as quickly as possible. In order to prevent packet loss
during this reachability check, transmission of packets over the link
between the MN and the old point of attachment should be suspended by
buffering the packets at both ends of the link during the
reachability check. How to perform this buffering is out of scope of
this document. Some of the results of using this buffering scheme
are explained in the accompanying document [MPA-WIRELESS].
7.7. Security and Mobility
This section describes how MPA can help establish layer 2 and layer 3
security association in the target networks while the mobile node is
in the previous network.
7.7.1. Link-Layer Security and Mobility
Using the MPA-SA established between the mobile node and the
authentication agent for a CTN, during the pre-authentication phase,
it is possible to bootstrap link-layer security in the CTN while the
mobile node is in the current network, as described in the following
steps. Figure 5 shows the sequence of operation.
(1) The authentication agent and the mobile node derive a PMK (Pair-
wise Master Key) [RFC5247] using the MPA-SA that is established
as a result of successful pre-authentication. Successful
operation of EAP and a AAA protocol may be involved during
pre-authentication to establish the MPA-SA. From the PMK,
distinct TSKs (Transient Session Keys) [RFC5247] for the mobile
node are directly or indirectly derived for each point of
attachment of the CTN.
(2) The authentication agent may install the keys derived from the
PMK and used for secure association to points of attachment.
The derived keys may be TSKs or intermediary keys from which
TSKs are derived.
(3) After the mobile node chooses a CTN as the target network and
switches to a point of attachment in the target network (which
now becomes the new network for the mobile node), it executes a
secure association protocol such as the IEEE 802.11i 4-way
handshake [802.11], using the PMK in order to establish PTKs
(Pair-wise Transient Keys) and group keys [RFC5247] used for
protecting link-layer packets between the mobile node and the
point of attachment. No additional execution of EAP
authentication is needed here.
(4) While the mobile node is roaming in the new network, the mobile
node only needs to perform a secure association protocol with
its point of attachment, and no additional execution of EAP
authentication is needed either. Integration of MPA with link-
layer handover optimization mechanisms such as 802.11r can be
archived this way.
The mobile node may need to know the link-layer identities of the
points of attachment in the CTN to derive TSKs.
| Current Network | | CTN |
| ____ | | ____ |
| | | (1) pre-authentication | | |
| | MN |<------------------------------->| AA | |
| |____| | | |____| |
| . | | | |
| . | | | |
|____.____________| | | |
.movement | |(2) Keys |
____.___________________| | |
| _v__ _____ | |
| | |(3) secure assoc. | | | |
| | MN |<------------------>| AP1 |<-------+ |
| |____| |_____| | |
| . | |
| .movement | |
| . | |
| . | |
| _v__ _____ | |
| | |(4) secure assoc. | | | |
| | MN |<------------------>| AP2 |<-------+ |
| |____| |_____| |
Figure 5: Bootstrapping Link-Layer Security7.7.2. IP-Layer Security and Mobility
IP-layer security is typically maintained between the mobile node and
the first-hop router, or any other network element such as SIP proxy
by means of IPsec. This IPsec SA can be set up either in tunnel mode
or in ESP mode. However, as the mobile node moves, the IP address of
the router and outbound proxy will change in the new network. The
mobile node's IP address may or may not change, depending upon the
mobility protocol being used. This will warrant re-establishing a
new security association between the mobile node and the desired
network entity. In some cases, such as in a 3GPP/3GPP2 IMS/MMD
environment, data traffic is not allowed to pass through unless there
is an IPsec SA established between the mobile node and outbound
proxy. This will of course add unreasonable delay to the existing
real-time communication during a mobile node's movement. In this
scenario, key exchange is done as part of a SIP registration that
follows a key exchange procedure called AKA (Authentication and Key
MPA can be used to bootstrap this security association as part of
pre-authentication via the new outbound proxy. Prior to the
movement, if the mobile node can pre-register via the new outbound
proxy in the target network and completes the pre-authentication
procedure, then the new SA state between the mobile node and new
outbound proxy can be established prior to the movement to the new
network. A similar approach can also be applied if a key exchange
mechanism other than AKA is used or the network element with which
the security association has to be established is different than an
By having the security association established ahead of time, the
mobile node does not need to be involved in any exchange to set up
the new security association after the movement. Any further key
exchange will be limited to renew the expiry time. This will reduce
the delay for real-time communication as well.
7.8. Authentication in Initial Network Attachment
When the mobile node initially attaches to a network, network access
authentication would occur regardless of the use of MPA. The
protocol used for network access authentication when MPA is used for
handover optimization can be a link-layer network access
authentication protocol such as IEEE 802.1X, or a higher-layer
network access authentication protocol such as PANA.
8. Security Considerations
This document describes a framework for a secure handover
optimization mechanism based on performing handover-related signaling
between a mobile node and one or more candidate target networks to
which the mobile node may move in the future. This framework
involves acquisition of the resources from the CTN as well as data
packet redirection from the CTN to the mobile node in the current
network before the mobile node physically connects to one of those
Acquisition of the resources from the candidate target networks must
be done with appropriate authentication and authorization procedures
in order to prevent an unauthorized mobile node from obtaining the
resources. For this reason, it is important for the MPA framework to
perform pre-authentication between the mobile node and the candidate
target networks. The MN-CA key and the MN-AR key generated as a
result of successful pre-authentication can protect subsequent
handover signaling packets and data packets exchanged between the
mobile node and the MPA functional elements in the CTNs.
The MPA framework also addresses security issues when the handover is
performed across multiple administrative domains. With MPA, it is
possible for handover signaling to be performed based on direct
communication between the mobile node and routers or mobility agents
in the candidate target networks. This eliminates the need for a
context transfer protocol [RFC5247] for which known limitations exist
in terms of security and authorization. For this reason, the MPA
framework does not require trust relationships among administrative
domains or access routers, which makes the framework more deployable
in the Internet without compromising the security in mobile
We would like to thank Farooq Anjum and Raziq Yaqub for their review
of this document, and Subir Das for standardization support in the
IEEE 802.21 working group.
The authors would like to acknowledge Christian Vogt, Rajeev Koodli,
Marco Liebsch, Juergen Schoenwaelder, and Charles Perkins for their
thorough review of the document and useful feedback.
Author and Editor Ashutosh Dutta would like to thank Telcordia
Technologies, and author Victor Fajardo would like to thank Toshiba
America Research and Telcordia Technologies, for supporting the
development of their document while they were employed in their
10.1. Normative References
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC5380] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4881] El Malki, K., Ed., "Low-Latency Handoffs in Mobile IPv4",
RFC 4881, June 2007.
[RFC4066] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D.,
and E. Shim, "Candidate Access Router Discovery (CARD)",
RFC 4066, July 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, May 2008.
[RG98] ITU-T, "General Characteristics of International Telephone
Connections and International Telephone Circuits: One-Way
Transmission Time", ITU-T Recommendation G.114, 1998.
[ITU98] ITU-T, "The E-Model, a computational model for use in
transmission planning", ITU-T Recommendation G.107, 1998.
[ETSI] ETSI, "Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON) Release 3; End-to-end
Quality of Service in TIPHON systems; Part 1: General
aspects of Quality of Service (QoS)", ETSI TR 101
329-1 V3.1.2, 2002.
10.2. Informative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201,
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680,
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A
Round-trip Delay Metric for IPPM", RFC 2681,
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option
for the Dynamic Host Configuration Protocol version 4
(DHCPv4)", RFC 4039, March 2005.
[RFC5172] Varada, S., Ed., "Negotiation for IPv6 Datagram
Compression Using IPv6 Control Protocol", RFC 5172,
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G.,
Ernst, T., and K. Nagami, "Multiple Care-of Addresses
Registration", RFC 5648, October 2009.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection
(DAD) for IPv6", RFC 4429, April 2006.
[RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed.,
"Extensible Authentication Protocol (EAP) Early
Authentication Problem Statement", RFC 5836,
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, August 2008.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L.
Dondeti, "Handover Key Management and
Re-Authentication Problem Statement", RFC 5169,
[SIPMM] Schulzrinne, H. and E. Wedlund, "Application-Layer
Mobility Using SIP", ACM MC2R, July 2000.
[CELLIP] Campbell, A., Gomez, J., Kim, S., Valko, A., Wan, C.,
and Z. Turanyi, "Design, Implementation, and
Evaluation of Cellular IP", IEEE Personal
Communications, August 2000.
[MOBIQUIT07] Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and
A. Skarmeta, "Network-layer assisted mechanism to
optimize authentication delay during handoff in 802.11
networks", IEEE Mobiquitous, June 2007.
[MISHRA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W.
Arbaugh, "Proactive key distribution using neighbor
graphs", IEEE Wireless Communications Magazine,
[SPRINGER07] Dutta, A., Das, S., Famolari, D., Ohba, Y., Taniuchi,
K., Fajardo, V., Lopez, R., Kodama, T., Schulzrinne,
H., and A. Skarmeta, "Seamless proactive handover
across heterogeneous access networks", Wireless
Personal Communications, November 2007.
[HAWAII] Ramjee, R., La Porta, T., Thuel, S., Varadhan, K., and
S. Wang, "HAWAII: A Domain-based Approach for
Supporting Mobility in Wide-area Wireless networks",
International Conference on Network Protocols ICNP'99.
[IDMP] Das, S., McAuley, A., Dutta, A., Misra, A.,
Chakraborty, K., and S. Das, "IDMP: An Intra-Domain
Mobility Management Protocol for Next Generation
Wireless Networks", IEEE Wireless Communications
Magazine, October 2000.
[MOBIP-REG] Gustafsson, E., Jonsson, A., and C. Perkins, "Mobile
IPv4 Regional Registration", Work in Progress,
[YOKOTA] Yokota, H., Idoue, A., Hasegawa, T., and T. Kato,
"Link Layer Assisted Mobile IP Fast Handoff Method
over Wireless LAN Networks", Proceedings of ACM
[MACD] Shin, S., Forte, A., Rawat, A., and H. Schulzrinne,
"Reducing MAC Layer Handoff Latency in IEEE 802.11
Wireless LANs", MobiWac Workshop, 2004.
[SUM] Dutta, A., Zhang, T., Madhani, S., Taniuchi, K.,
Fujimoto, K., Katsube, Y., Ohba, Y., and H.
Schulzrinne, "Secured Universal Mobility for Wireless
Internet", WMASH'04, October 2004.
[SIPFAST] Dutta, A., Madhani, S., Chen, W., Altintas, O., and H.
Schulzrinne, "Fast-handoff Schemes for Application
Layer Mobility Management", PIMRC 2004.
[PIMRC06] Dutta, A., Berg, E., Famolari, D., Fajardo, V., Ohba,
Y., Taniuchi, K., Kodama, T., and H. Schulzrinne,
"Dynamic Buffering Control Scheme for Mobile Handoff",
Proceedings of PIMRC 2006, 1-11.
[MITH] Gwon, Y., Fu, G., and R. Jain, "Fast Handoffs in
Wireless LAN Networks using Mobile initiated Tunneling
Handoff Protocol for IPv4 (MITHv4)", Wireless
Communications and Networking 2003, January 2005.
[WENYU] Jiang, W. and H. Schulzrinne, "Modeling of Packet Loss
and Delay and their Effect on Real-Time Multimedia
Service Quality", NOSSDAV 2000, June 2000.
[802.21] "IEEE Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services, IEEE
802.21-2008", a contribution to IEEE 802.21 WG,
[802.11] "IEEE Wireless LAN Edition A compilation based on IEEE
Std 802.11-1999(R2003)", Institute of Electrical and
Electronics Engineers, September 2003.
[GPSIP] Dutta, A., Madhani, S., Chen, W., Altintas, O., and H.
Schulzrinne, "GPS-IP based fast-handoff approaches for
Mobiles", IEEE Sarnoff Symposium 2006.
[MAGUIRE] Vatn, J. and G. Maguire, "The effect of using
co-located care-of addresses on macro handover
latency", 14th Nordic Teletraffic Seminar 1998.
[MPA-MOBIKE] El Mghazli, Y., Bournelle, J., and J. Laganier, "MPA
using IKEv2 and MOBIKE", Work in Progress, June 2006.
[MPA-WIRELESS] Dutta, A., Famolari, D., Das, S., Ohba, Y., Fajardo,
V., Taniuchi, K., Lopez, R., and H. Schulzrinne,
"Media- Independent Pre-authentication Supporting
Secure Interdomain Handover Optimization", IEEE
Wireless Communications Magazine, April 2008.