MOBOPTS Research Group A. Dutta
Internet-Draft Telcordia
Expires: January 9, 2008 V. Fajardo (Ed.)
R. Lopez
Y. Ohba
K. Taniuchi
TARI
H. Schulzrinne
Columbia Univ.
July 8, 2007
Media-Independent Pre-Authentication (MPA) Implementation Results
draft-ohba-mobopts-mpa-implementation-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Dutta, et al. Expires January 9, 2008 [Page 1]
Internet-Draft MPA Implementation July 2007
Abstract
This document describes an initial implementation of Media-
independent Pre-Authentication (MPA) optimization. MPA is a mobile-
assisted, secure handover optimization scheme that works over any
link-layer and with any mobility management protocol. The
implementation described in this document shows how existing
protocols can be leveraged to realize the functionalities of MPA. It
also includes empirical results gathered from experiments performed
on a simulated network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Topology of MPA Testbed . . . . . . . . . . . . . . . 4
2.1. MPA Testbed using Mobile IPv6 . . . . . . . . . . . . . . 4
2.2. MPA Testbed using SIP Mobility . . . . . . . . . . . . . . 9
3. Non-MPA-assisted Handover Scenario . . . . . . . . . . . . . . 14
4. Evaluation and Performance Results . . . . . . . . . . . . . . 16
4.1. Intra-technology, Inter-domain . . . . . . . . . . . . . . 16
4.2. Inter-technology, Inter-domain . . . . . . . . . . . . . . 20
4.3. MPA-assisted Layer 2 pre-authentication . . . . . . . . . 21
4.4. FMIPv6 and MPA performance comparison . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Dutta, et al. Expires January 9, 2008 [Page 2]
Internet-Draft MPA Implementation July 2007
1. Introduction
Media-independent Pre-Authentication (MPA), is a new handover
optimization mechanism that provides mobility optimization that is
not tightly couple with existing mobility management schemes. It is
designed to support mobile terminal with one or more interfaces and
is capable of securely crossing between administrative domains. It
also easily integrates with existing mobility management protocols,
such as MIPv6 and SIP-based mobility. The MPA architecture is
described in [I-D.ohba-mobopts-mpa-framework].
This document accompanies the MPA architectural document
[I-D.ohba-mobopts-mpa-framework] and describes how to implement MPA.
It also describes performace results gathered from these
implementations and can clearly show how one can use existing
protocols to provide MPA functionality. The following sections also
describe specific scenarios where both MPA and non-MPA approaches are
evaluated and results are compared.
Dutta, et al. Expires January 9, 2008 [Page 3]
Internet-Draft MPA Implementation July 2007
2. Network Topology of MPA Testbed
For the MPA evaluation, two testbeds were developed each using a
different mobility management protocol (MMP). The first
implementation uses Mobile IPv6 (MIPv6) [RFC3775] and the second uses
SIP Mobility (SIP-M) [SIPMM]. The results of the test from both
testbeds are described in the succeeding chapters. These results are
also compared against a non-MPA scenario to highlight the advantages
of using MPA.
2.1. MPA Testbed using Mobile IPv6
The initial MPA testbed uses Mobile IPv6 (MIPv6) to facilitate
mobility management functions between Mobile Node (MN) and the
Correspondent Node (CN). Figure 1 describes the basic topology for
the MPA testbed using MIPv6.
Network 1 Network 2 Network 4
(oPoA) (nPoA)
+-------------+
| Mobile IPv6 |
------------------------------------------| Home Agent |
| | (HA) |
| +-------------+
+--------+ +------------+
|Router 1|---------|Router 2(RA)|---------+
+---+----+ |PAA(AA) | | Network 3
| |Packet Buf | |
| +------------+ | +------------+
| | |-| MIPv6 CN |
| | | +------------+
| +-----+ | +-----+ |
|-|AP 1 | |-|AP 2 | |
+-----+ +-----+
: :
: :
+------------+ +------------+
|MN |---->|MN |
|MIPv6 Client| |MIPv6 Client|
|PaC | |PaC |
+------------+ +------------+
Figure 1: MPA Test Network using Mobile IPv6
There are four networks. Network 1 is the old point of attachment
(oPoA) where the mobile node (MN) intially resides prior to handover,
Network 2 is new point of attachment (nPoA) where the MN is moving
towards. Network 3 is where the correspondent node (CN) resides on.
Dutta, et al. Expires January 9, 2008 [Page 4]
Internet-Draft MPA Implementation July 2007
Network 4 is where the Home Agent (HA) resides. All networks need
not be adjacent. However, in the testbed each network is one IP hope
away from each other. IPv6 addressing are used in all networks and
prefixes are statically configured to reduce complexity. As an
initial state, the CN starts communicating with the MN while the MN
is in Network 1 by sending streaming (RTP) traffic towrds the MN via
HA within the MIPv6 tunnel. During handoff, the MIPv6 takes care of
the continuity of the RTP (Real-Time Transport Protocol) traffic.
Details of the topology of are as follows.
1. Network 1
* Router 1 (R1) - IPv6 Gateway to Network 1 and reachable via
Network 2 and Network 4.
* Access Point 1 (AP1) - 802.11 WLAN Access Point acting as oPoA
of the MN.
2. Network 2
* Router 2 (R2) - IPv6 Gateway to Network 2 and reachable via
Network 1 and Network 3. It has a co-located Authentication
Agent (AA) using PANA PAA (PAA) [I-D.ietf-pana-pana]. Packet
buffering is also available in R2 to assist during handover.
When packet buffering is used during handover, packet loss is
prevented at the cost of greater packet delay.
* Access Point 2 (AP2) - 802.11 WLAN Access Point acting as nPoA
for the MN
3. Network 3
* Correspondent Node (CN) - IPv6 source of voice and streaming
traffic via RTP/UDP using the RAT (Robust Audio Tool) media
agent.
4. Network 4
* Mobile IPv6 Home Agent (HA) - MIPv6 Home Agent (HA)
responsible for IPv6 source of voice/ streaming traffic via
RTP/UDP using the RAT (Robust Audio Tool) media agent.
5. MN
* MIPv6 mobile node (MN) - MN that binds with the HA in Network
3. It uses an 802.11 WLAN-optimized interface driver for
handover. There is also an optional kernel-based network
buffer for packet loss protection.
Dutta, et al. Expires January 9, 2008 [Page 5]
Internet-Draft MPA Implementation July 2007
In MIPv6, the MN creates an IPv6-IPv6 tunnel with the HA as part of
the mobility management. With the addition of MPA, a proactive
handover tunnel is created between the MN and R2 in Network 2. In
the testbed, this tunnel is based on IPsec tunnel mode ESP, PANA is
used for dynamically establishing and terminating the IPsec tunnel.
Note that for simplicity, the required cipher keys for IPsec tunnel
mode ESP are pre-configured on the MN and R2. Though IKE was not
used for establishing the IPsec tunnel mode ESP in the test scenario,
use of IKE before the handover will change the overall behavior. As
part of the MPA scheme, the MIPv6 tunnel traffic between the MN and
HA goes through the IPsec tunnel created by MPA with appropriate
IPsec policy settings. In the testbed, the required IPsec policy
parameters including nCoA are also carried in PANA messages. Details
of the MPA message flows is shown in Figure 2.
Dutta, et al. Expires January 9, 2008 [Page 6]
Internet-Draft MPA Implementation July 2007
Router 2 (RA)
MN AP1 AP2 PAA (AA) HA CN
|L2 Association| | | | |
| and oCoA assignment | | | |
|<------------>| | | | |
| MIPv6 and voice communication start | | |
|<------------------------------------------------->|<------>|
| Step 1 Pre-authentication with PAA | | |
|<-------------------------------------->| | |
| Step 2 Pre-configuration with R2 | | |
| and nCoA assignment preparations | | |
|<-------------------------------------->| | |
| | | | | |
|IPsec tunnel is established with R2 | |
|<-------------------------------------->| | |
| Step 3 MIPv6 Binding Update | | | |
|<------------------------------------------------->| |
|MIPv6 voice traffic goes through IPsec tunnel | |
|<======================================>|<----------------->|
| Step 4 Deletion of the IPsec tunnel | | |
| Start of buffering (optional) | | |
|<-------------------------------------->| | |
X Step 5 Association with AP 2| | | |
X<- - - - - - - - - - - - - - >| | | |
X MIPv6 voice traffic goes to nCoA | | |
| End of buffering (optional) | | | |
|<---------------------------------------------------------->|
<- - - - ->802.11 frame
<--------->IP packet
<=========>IPsec tunneling packet
X Potential Packet loss
Figure 2: MPA Communication Flow in the Test Environment with MIPv6
Initially state the MN associates itself with AP 1. It configures
itself based on a statically configured router IPv6 prefix. This IP
address is the old Care of Address (oCoA) that is sent to the HA via
the initial Binding Update (BU). Voice traffic then initiated from
CN to MN via the HA (inside the MIPv6 tunnel). The voice traffic is
carried over RTP/UDP.
MPA process starts when the MN pre-authenticates with Network 2.
This step is similar to SIP-mobility Section 2.2 and shows the
generic application of pre-authentication with any mobility
management scheme. Pre-authentication can be triggered by localized
policy that includes monitoring the MN's signal strength or maybe an
Dutta, et al. Expires January 9, 2008 [Page 7]
Internet-Draft MPA Implementation July 2007
indication of "link going down" event [802.21]. In the pre-
authentication procedure (Step 1 of Figure 2 ), the MN prepares for
link-layer handover and obtains all relevant information about the
target network. After successful completion of the pre-
authentication procedure, an MPA SA is established between the MN and
AA in Network 2. In the MIPv6 tested, information about the target
network is also obtained in Step 1. Note that in the testbed this
information is stored locally in the cache on MN before starting the
pre-authentication procedure.
In step 2, the pre-configuration procedure is executed to configure
parameters required for communicating via Network 2. Parameters
include nCoA and are communicated back via PANA messaging. As part
of the MIPv6 functions, the MN sends a Binding Update (BU) to HA to
update the mobility binding. Once HA is updated, MIPv6 will use nCoA
and traffic will flow via Network 2. Since the MN and R2 are aware
of nCoA, it is also used during the establishment of the IPsec
tunnel. The IPsec policies established between the MN and R2 will
allow MIPv6 traffic to be forwared through the IPsec tunnel. This
process is step 3 of Figure 2.
When MPA setup is completed, the MN can perform proactive secure
handover. The MN and R2 tear down the IPsec tunnel as part of this
process and MN associates with AP 2. Since the HA is already
configured with the nCoA, the MN does not need to send a BU to the HA
after handover. R2 should forward traffic for the MN as it is
managed by the HA. The signalling of the movement between MN and R2
are also similar to the SIP-mobility scenario in that it uses PANA-
Update-Request messages.
As shown in Figure 2, there is potential packet loss during period
'X'. In the testbed, an optional packet buffering mechanism has been
implemented to assist during handover. Prior to handover, step 4 in
Figure 2, the MN signals R2 so that buffering of packets that is
destined for the MN can begin. During the handover, R2 buffers all
packets that are already in transit and have destination of oCoA of
the MN. Once handover has successfully completed, the MN again
signals R2 that it can end buffering of packets and forward any
buffered packets to the MN at nCoA. This mechanism guarantees no
packet loss for incoming packet to the MN during the handover. The
results of MPA with and without buffering is shown in Section 4. As
shown in the results, adding buffering has a side effect of
increasing overall delay because of additional signaling as well as
delay caused by the act of buffering itself. A source of delay can
also be attributed to the fact that the packet sequence has to be
maintained during forwarding of buffered packets so newly arrived
packets have to wait until all buffered packets have been forwarded.
Dutta, et al. Expires January 9, 2008 [Page 8]
Internet-Draft MPA Implementation July 2007
2.2. MPA Testbed using SIP Mobility
The second MPA testbed uses SIP Mobility (SIP-M) to facilitate
mobility management functions between Mobile Node (MN) and the
Correspondent Node (CN). Figure 3 describes the basic topology for
the MPA testbed using SIP-M.
Network 1 Network 2 Network 3
(oPoA) (nPoA)
+--------+ +------------+
|Router 1|---------|Router 2(RA)|---------+
+---+----+ |PAA(AA) | |
| |Packet Buf | |
| |DHCP Relay | |
| +--------+ |Agent (CA) | | +------------+
|-|DHCP | +------------+ | |CN |
| |Server 1| | +------------+ |-|SIP-M Client|
| +--------+ |-|DHCP | | +------------+
| | |Server 2 | |
| | +------------+ |
| | |
| +-----+ | +-----+ |
|-|AP 1 | |-|AP 2 | |
+-----+ +-----+
: :
: :
+------------+ +------------+
|MN |---->|MN |
|SIP-M Client| |SIP-M Client|
|PaC | |PaC |
+------------+ +------------+
Figure 3: MPA Test Network using SIP Mobility
The topology for the SIP Mobility (SIP-M) testbed is very similar to
Figure 1. The first three networks have the same configuration
except that IPv4 addressing is used and mobility management is done
via SIP. Also, IP addressing is based on DHCP Server assignments
instead of static configurations. In addition, Network 4 is not
required since Home Agent (HA) is not present in the SIP-M tests.
1. Network 1
* Router 1 (R1) - IPv4 Gateway to Network 1 and reachable via
Network 2
* DHCP Server 1 (DHCPs1) - IP addressing needs for Network 1
Dutta, et al. Expires January 9, 2008 [Page 9]
Internet-Draft MPA Implementation July 2007
* Access Point 1 (AP1) - 802.11 WLAN Access Point acting as oPoA
of the MN
2. Network 2
* Router 2 (R2) - IPv4 Gateway to Network 2 and reachable via
Network 1 and Network 3. It has a co-located Authentication
Agent (AA) using PANA PAA (PAA), [I-D.ietf-pana-pana] and a
co-located DHCP relay-agent acting as Configuration Agent
(CA), [RFC3046]. Packet buffering is also available in R2 to
assist during handover. When packet buffering is used during
handover, packet loss is averted.
* DHCP Server 2 (DHCPs2) - IP addressing needs for Network 2.
It's reachability is extended by the DHCP relay-agent in R2
* Access Point 2 (AP2) - 802.11 WLAN Access Point acting as nPoA
for the MN
3. Network 3
* Correspondent Node (CN) - Co-located SIP Mobility Client and
source of voice/streaming traffic via RTP/UDP using the RAT
(Robust Audio Tool) media agent.
4. MN
* Co-located SIP Mobility Client that binds with the CN. It
uses an 802.11 WLAN optimized interface driver for handover.
There is also an optinal kernel based network buffer for
packet loss protection.
To simplify the scenario, SIP proxies are not involved to set up the
initial communication between the CN and MN. Router 2 provides IP-
in-IP tunneling [RFC1853] to facilitate routing to the MN while the
MN is still in Network 1. This is part of the MPA handover
procedure. The IP-in-IP tunnel will make it appear as though the MN
is already in Network 2 and the streaming traffic will be forwarded
via the tunnel. Details of the MPA message flows are shown in
Figure 4.
Dutta, et al. Expires January 9, 2008 [Page 10]
Internet-Draft MPA Implementation July 2007
Router 2 (RA)
PAA (AA)
DHCP DHCP Relay DHCP
MN AP1 Server 1 AP2 Agent Server 2 CN
|L2 Association| | | | | |
|<- - - - - - >| | | | | |
| oCoA assignment | | | | |
|<------------------->| | | | |
| SIP and voice communication start | | |
|<----------------------------------------------------------->|
| Step 1 Pre-authentication with PAA | | |
|<-------------------------------------->| | |
| Step 2 Pre-configuration with DHCP RA | | |
|<-------------------------------------->| | |
| | | | |DHCP MESGS | |
| | | | |<--------->| |
| nCoA assignment | | | | |
|<-------------------------------------->| | |
|IP-in-IP tunnel is established with R2 | |
|<-------------------------------------->| | |
|Step 3 SIP Re-INVITE goes through IP-in-IP tunnel | |
|<======================================>|<------------------>|
|Voice traffic goes through IP in IP tunnel | |
|<======================================>|<------------------>|
| Step 4 Deletion of the tunnel | | |
| Start of buffering (optional) | | |
|<-------------------------------------->| | |
X Step 5 Association with AP 2| | | |
X<- - - - - - - - - - - - - - >| | | |
X Voice traffic goes to nCoA | | | |
| End of buffering (optional) | | | |
|<----------------------------------------------------------->|
<- - - - ->802.11 frame
<--------->IP packet
<=========>IP in IP tunneling packet
X Potential Packet loss
Figure 4: MPA Communication Flow in the Test Environment with SIP-M
Initially, the MN associates itself with AP1 and obtains the IP
address from DHCP Server 1 in Network 1. The IP address obtained in
Network 1 is the old Care of Address (oCoA). To setup RTP traffic,
the CN's SIP user agent attempts to connect with the MN's SIP user
agent. After a successful SIP connection, voice traffic is initiated
from CN to MN. The voice traffic is carried over RTP/UDP using the
RAT (Robust Audio Tool) media agent.
Dutta, et al. Expires January 9, 2008 [Page 11]
Internet-Draft MPA Implementation July 2007
MPA test starts when the MN pre-authenticates with Network 2. This
step can be triggered by some localized policy that includes
monitoring the MN's signal strength or maybe an indication of "link
going down" event [802.21]. In anycase, pre-authentication prepares
the MN for the handover process by obtaining information about the
target network. Obtaining this information can be done via
information servers that maybe present in a reachable network
[802.21]. In the case of the testbed, information servers are not
present to simplify the network topology. Target network information
are pre-defined within the MN to simulate a successful information
server query. Since the relevant information is available, the MN
authenticates to the PAA and derives proper security keys and
establishes a security association (SA) with the MN. The pre-
authentication process is step 1 of Figure 4.
In step 2, the MN pre-configures with Network 2. The MN performs
pre-configuration by communicating with DHCP Proxy to obtain an IP
address for Network 2. Other implementation may require more than
just the IP address. In such a case, more information can pre-
provisioned and can be communicated to the MN during this phase. In
the testbed, the DHCP proxy and Authentication Agent (AA) are co-
located and the DHCP proxy provides IP assignment services to pre-
authenticated MN's via DHCP Server 2. The new IP address is relayed
back to the MN as part of the PANA exchanges. The newly obtained IP
address is the new Care of Address (nCoA) and is usable in Network 2.
Once the MN gets the nCoA, it can create an IP-in-IP tunnel with
Router 2 of Network 2 and assign the nCoA as a virtual interface
address of this tunnel.
Once a tunnel is created, the MN performs proactive secure handover.
Since the MN is configured with the nCoA, the MN can send a SIP Re-
invite to CN with nCoA as its new contact address via the tunnel. In
the testbed, all traffic between CN and MN will be carried within the
tunnel once SIP Re-invite completes. This traffic includes the voice
traffic initiated in the initial step.
The remaining steps allow the MN to perform the actual secure
proactive handover. As the mobile detects the nPoA and makes a
decision to switch over to Network 2 it starts association with AP 2.
Once association completes successfully, the MN configures itself by
tearing down the local tunnel end-point and re-assign the nCoA to the
physical interface associated with AP 2. In addition, it also
updates its local default route information with that of Network 2.
The MN then sends a PANA-Update-Request message to the access router
R2. The purpose of this message is to notify Router 2 to tear down
its tunnel end-point. The MN's ARP entry for nCoA is also be updated
in R2 upon receipt of this message. This reduces the delay due to
ARP exchanges that usually happens when a new IP address is first
Dutta, et al. Expires January 9, 2008 [Page 12]
Internet-Draft MPA Implementation July 2007
used in a network.
Similar to MIPv6 with MPA, a optional packet buffering exists in R2
to assist with packet loss during handover. The mechanism for
buffering remains the same as with MIPv6 with MPA as described in
Section 2.1. The results of MIPv6 MPA with buffering are also shown
in Section 4 and are consistent with MIPv6 results with buffering.
Dutta, et al. Expires January 9, 2008 [Page 13]
Internet-Draft MPA Implementation July 2007
3. Non-MPA-assisted Handover Scenario
For comparison purposes, non-MPA assisted handover is also described
in this section. The non-MPA scheme were tested using Figure 3.
Note that the expected behavior described in this section would be
similar if the testbed used was Figure 1. The non-MPA scheme does
not provide any proactive handover mechanism and therefore follow a
typical procedure for handover. To ensure good comparison with the
MPA scenario, the MN bootstraps itself in Network 1 and obtains an
oCoA from DHCP Server 1 in the non-MPA scenario. In addition, it
uses the same handover policy to decide when actual handover process
should begin, i.e., signal strength or link layer down event.
Once the policy indicates that handover should begin, the MN
disassociates with AP 1 and associates with AP 2. On successful
association, it obtains an IP address (nCoA) from DHCP Server 2, then
assigns that address to its physical interface. During this period,
no data can reach the MN. Even after associating with AP 2, traffic
towards the MN through Router 2 may not be allowed since the MN is
not yet authenticated in Network 2. So the authentication process
becomes part of the overall handover and hence the additional delay.
Only when the authentication is successful can packets be forwarded
to the MN via Network 2.
An additional requirement before packet forwarding can happen is to
send binding updates to inform the CN of the MN's nCoA. In the
testbed, the MN sends SIP Re-INVITE with the nCoA and causes voice
traffic to be forwarded via Network 2. This process also adds delay
and could have potentially taken an even longer amount of time if the
MB's target network and the CN are far apart.
Dutta, et al. Expires January 9, 2008 [Page 14]
Internet-Draft MPA Implementation July 2007
Router 2(RA)
PAA(AA)
DHCP DHCP Relay DHCP
MN AP1 Server 1 AP2 Agent Server 2 CN
|L2 Association| | | | | |
|<- - - - - - >| | | | | |
| IP address assignment | | | |
|<------------------->| | | | |
| SIP and voice communication start | | |
|<----------------------------------------------------------->|
| Association with AP 2 | | | |
X<- - - - - - - - - - - - - - >| | | |
X new IP address assignment | | | |
X<-------------------------------------------------->| |
X Authentication with PAA | | | |
X<-------------------------------------->| | |
X SIP Re-INVITE | | | |
X<----------------------------------------------------------->|
X Voice traffic goes to new IP address | | |
|<----------------------------------------------------------->|
<- - - - ->802.11 frame
<--------->IP packet
X Potential Packet loss
Figure 5: Communication Flow for Non-MPA Assisted Handover in the
Test Environment using SIP-M
Dutta, et al. Expires January 9, 2008 [Page 15]
Internet-Draft MPA Implementation July 2007
4. Evaluation and Performance Results
We have experimented with MPA techniques for two types of
heterogeneous handovers as defined in
[I-D.ohba-mobopts-heterogeneous-requirement]. We provide the details
of two of these: I) Intra-technology and Inter-domain, II) Inter-
technology and Inter-domain. Section 4.1 discusses the results of
case I whereas Section 4.2 discusses the results of case II. We have
also experimented with MPA to bootstrap layer 2 security for both
roaming and non-roaming cases. In non-roaming case the mobile does
not need to communicate with home AAA server during the EAP
authentication, but in case of roaming mobile needs to communciate
with AAA server. Section 4.3 discusses the results obtained from
MPA-assisted layer 2 pre-authentication and compares these with EAP
authentication and IEEE 802.11i's pre-authentication techniques.
4.1. Intra-technology, Inter-domain
Measurements taken from testbed Figure 1 are shown in Figure 6 and
testbed Figure 3 are shown in Figure 7. Measurements are based on
the following common scenarios for both testbed and the values are
mean values taken from three test samples.
o AP 1 and AP 2 are 802.11b access points operating on separate
channels.
o L2 handoff measurements are based on complete open mode
association sequence. Measurement from a set of 10 sets is a mean
value in milliseconds.
o L3 handoff measurements are based on Linux network layer
configuration including routing table updates, neighbor cache or
ARP table updates and interface address assignment. Measurement
is a mean value from ten samples expressed in milliseconds.
o Average packet loss is number of packets that failed to reach the
MN during L2 and L3 handoff periods. Measurement is a mean value
from ten samples.
o Average inter-packet arrival interval is the average time interval
between each RTP packets as they arrive in the MN. The
measurement is taken from the MN. This value mostly reflects the
RTP packet generation rate in the CN where the RTP traffic comes
from. However, variation in packet propagation time due to
congestion may affect the packet inter-arrival time resulting in
jitter. Measured value of inter-packet arrival interval is 16 ms.
Dutta, et al. Expires January 9, 2008 [Page 16]
Internet-Draft MPA Implementation July 2007
o Average inter-packet arrival time during handover is the amount of
time in miliseconds between the last RTP packet received by the MN
before handover and the first RTP packet received by the MN after
handover. This will include the binding update signaling (SIP and
MIPv6) as well as any buffer signaling. Measurement is a mean
value in millisecond.
o Average packet jitter is the avg. inter-packet arrival time during
handover minus the expected avg. inter-packet arrival interval.
This provides a measurement of the avg. additional delay incurred
because of the handover process.
o R2 buffering is an optional mechanism in the router to perform IP
packet buffering on behalf of the MN during handoff period. It is
a measure of the length of the buffering period. Measurement is a
mean value in millisecond.
o "Buffered packets" is the number of packets buffered and
eventually forwarded to the MN after handoff. This is available
only if buffering is enabled.
o Non-critical portions of the process is omitted such as pre-
authorization. Such process can be implemented in any network
infrastructure though it is not critical for the purpose of
handover measurements.
o Pre-authentication protocol used is PANA to establish SA between
MN and Network 2. Also, handover signaling information is carried
by PANA messages after successful pre-authentication.
o RO is MIPv6 route optimiziation where the CN sends RTP packets
directly to the MN's nCoA bypassing the HA.
o All IP nodes in both testbed uses Linux 2.6.x with Helsinki
University of Technology (HUT) implementation of Mobile IPv6.
The results for MIPv6 and SIP mobility are shown in Figure 6 and
Figure 7, respectively.
Dutta, et al. Expires January 9, 2008 [Page 17]
Internet-Draft MPA Implementation July 2007
Buffering Buffering Buffering Buffering
(disabled) (enabled) (disabled) (enabled)
& RO & RO & RO & RO
(disabled) (disabled) (enabled) (enabled)
-------------------------------------------------------------------
L2 handoff (ms) 4.00 4.33 4.00 4.00
L3 handoff (ms) 1.00 1.00 1.00 1.00
Avg. packet loss 1.33 0 0.66 0
Avg. inter-packet 16.00 16.00 16.00 16.00
arrival interval
(ms)
Avg. inter-packet n/a 45.33 n/a 66.60
arrival time during
handover
(ms)
Avg. packet jitter n/a 29.33 n/a 50.60
(ms)
Buffering Period n/a 50.00 n/a 50.00
(ms)
Buffered Packets n/a 2.00 n/a 3.00
Figure 6: Mobile IPv6 with MPA Results
Dutta, et al. Expires January 9, 2008 [Page 18]
Internet-Draft MPA Implementation July 2007
Buffering Buffering
disabled enabled
-----------------------------------------------
L2 handoff (ms) 4.00 5.00
L3 handoff (ms) 1.00 1.00
Avg. packet loss 1.50 0
Avg. inter-packet 16.00 16.00
arrival interval
(ms)
Avg. inter-packet n/a 29.00
arrival time during
handover
(ms)
Avg. packet jitter n/a 13.00
(ms)
Buffering Period n/a 20.00
(ms)
Buffered Packets n/a 3.00
Figure 7: SIP Mobility with MPA Results
For all measurement, we did not experience any performance
degradation during handover in terms of the audio quality of the
voice traffic.
With the use of buffering during handover, packet loss during the
actual L2 and L3 handover is eliminated with an appropriate and
reasonable settings of buffering period for both MIP6 and SIP
mobility. In the case of MIP6, there is not a significant difference
in results with and without route optimization. It should be noted
that results with more samples would be necessary to do more detailed
analysis.
In case of non-MPA assisted handover, handover delay and associated
packet loss occurs from the moment the link-layer handover procedure
begins up to successful processing of the binding update. During
this process, IP address acquisitions via DHCP incurs the longest
delay. This is due to the detection of duplicate of IP address in
the network before DHCP request completes. Binding update exchange
also experiences long delay if the CN is too far from the MN. As a
result, the Non-MPA assisted handover took an average of 4 seconds to
Dutta, et al. Expires January 9, 2008 [Page 19]
Internet-Draft MPA Implementation July 2007
complete with an approximate packet loss of about 200 packets. The
measurement is based on the same traffic rate and traffic source as
the MPA assisted handover.
4.2. Inter-technology, Inter-domain
Handoff involving heterogeneous access can take place in many
different ways. We limit the experiment to two interface and
therefore results in several possible setup scenarios depending upon
the activity of the second interface. In one scenario, the second
interface comes up when the link to the first interface goes down.
This is a reactive scenario usually gives rise to undesirable packet
loss and handoff delay. In a second scenario, the second interface
is being prepared while the mobile still communicates using the old
interface (Sec 5.8.2 of accompanying document). Preparation of the
second interface should include setup of all the required state and
security associations (e.g., PPP state, LCP, CHAP). Such lengthly
process is established ahead of time, it reduces the time taken for
the secondary interface to be attached to the network. After
preparation, the mobile can decides to use the second interface as
the active interface. This results in less packet loss as it uses
make-before-break techniques. This is a proactive scenario and can
have two(2) flavors. The first is where both interfaces are up and
the second is when only the old interface is up the prepared
interface is brougth up only when handoff is about to occur. This
scenario may be beneficial from a battery management standpoint.
Devices that operate two interfaces simultaneously can rapidly
deplete their batteries. However, by activating the second interface
only after an appropriate network has been selected may utilize
battery effectively. Information discovery and MPA remain the same
as in Section 5.1 with intra-technology handover. In this experiment
we add new optimization techniques such as faster link down detection
mechanism and a copy-forwarding technique at the access router to
help reduce transient packet loss during the handover. Detailed
discussion of faster link down detection and copy-forwarding
mechanisms are out of scope for the current document.
As compared to non-optimized handover that may result in delay up to
18 sec and 1000 packet loss during handover from WLAN to CDMA, we
were able to achieve 0 packet loss, and 50 ms handoff delay between
the last pre-handoff pa We have experimented iwtcket and first in-
handoff packet. This handoffelay includes the time due to link down
detection and time needed to delete the tunnel after the mobile has
moved. However we observed about 10 duplicate packets because of the
copy-forwarding mechanism at the access routers. But these duplicate
packets are usually handled easily by the upper layer protocols.
Dutta, et al. Expires January 9, 2008 [Page 20]
Internet-Draft MPA Implementation July 2007
4.3. MPA-assisted Layer 2 pre-authentication
MPA framework draft [xref target=I.D.ohba-mobopts-mpa-framework'/>
discusses about the mechanism of bootstrapping layer two
authentication in the neighboring access networks where the mobile is
impending to move. We describe the mechanism briefly here.
Initially, during the discovery phase, MN discovers through some
means the target AP and PAA's IP address that manages the target AP.
Then MN pre-establishes a PANA Security Association (SA) (pre-
authentication phase) with the candidate access network (CTN) via its
existing network by performing an EAP exchange between MN and PAA.
PAA could rely on a backend AAA server to carry out an EAP
authentication method. Then MN obtains configuration information
that allows it to participate in the new network. From MSK (used as
a root key), PAA can derive a distinct PSK per AP. PAA installs
these keys in those APs (pre-configuration phase), and provide MN
with the required information (APs MAC addresses) to generate the
same PSKs. Then MN moves to the AP and, after association, runs a
4-way handshake by using the PSKap generated during PANA pre-
authentication. At this point the handoff is complete. Thus, by
pre-authenticating and pre-configuring the link, the security
association establishment during handoff reduces to 4-way handshake
only. We then provide the details of the experimental setup and
compare these results with IEEE 802.11i pre-authentication. Figure 8
shows the experimental testbed where we have conducted the MPA-
assisted pre-auth experiment.
Dutta, et al. Expires January 9, 2008 [Page 21]
Internet-Draft MPA Implementation July 2007
+------------------+
| +-----+ |
Radius/Diameter| + | |
+----------------|---+ | |
| | |AAAh | |
| | | | |
| | | | |
+-------------------------+-------+ | +-----+ |
| | | | |
| +--+--+ | | Home Domain |
| | + | +------------------+
| Network A ____| | |
| | |AAAv | | +-----------------------+
| | | | | | |
| Roaming AAA | | | | | Network B |
| Domain | +-----+ | | |
| | | | |
| --|- | | /----\ |
| / \ | | / \ |
| | nAR | | | | pAR | |
| | PAA +-----------+--+---- \ / |
| \ / | | \--+-/ |
| --+- | | | |
| | | | | |
| | | | | |
| | | | +----+---+ |
| +------+------+ | | | | |
| | IEEE | | | | AP0 | |
| | 802.11i | | | +--------+ |
| +-+---+ +--+--+ | | |
| | | | | | | |
| | AP2 | | AP1 | | |PANA Pre-auth |
| +-----+ +-----+ | | |
| +-----+ +-----+ | | +------+ |
| | MN |----->| MN | <--------| MN | |
| +-----+ +-----+ | | +------+ |
+---------+----+------------------+ +-----------------------+
Figure 8: Experimental Testbed for MPA-assisted L2 Pre-authentication
We have experimented with three types of movement scenarios involving
both roaming and non-roaming cases using the testbed shown in figure
8. In roaming case, MN is visiting in a domain different than its
home domain. Consequently, the AAAh needs to be contacted which is
placed in a far from the visiting domain. For the non-roaming case,
we assume the MN is moving within its home domain and only local AAA
server (AAAv) is contacted. First scenario does not involve any pre-
Dutta, et al. Expires January 9, 2008 [Page 22]
Internet-Draft MPA Implementation July 2007
authentication. MN is initially connected to AP0 and moves to AP1.
Because neither network-layer authentication is enabled nor IEEE
802.11i pre-authentication is used, MN needs to engage in a full EAP
authentication with AP1 to gain access to the network after the move
(post-authentication). This experiment shows the effect of absence
of any kind of pre-authentication. Second scenario involves 802.11i
pre-authentication and involves movement between AP1 and AP2. MN is
initially connected to AP2, and starts IEEE 802.11i pre-
authentication with AP1. This is an ideal scenario to compare the
values obtained from 802.11i pre-authentication with that of network-
layer assisted pre-authentication. Both first and this second
scenarios use RADIUS as AAA protocol (APs implements a RADIUS
client). Third scenario takes advantage of network layer assisted
link-layer pre-authentication. It involves movement between two APs
(e.g., between AP0 and AP1) that belong to two different subnets
where 802.11i pre-authentication is not possible. Here, Diameter is
used as AAA protocol (PAA implements a Diameter client). In this
third movement scenario, MN is initially connected to AP0. MN starts
PANA pre-authentication with the PAA which is co-located on the AR in
the new candidate target network (nAR in network A) from the current
associated network (network B). After authentication, PAA installs
two keys, PSKap1 and PSKap2 in both AP1 and AP2 respectively by using
a pre-emptive key installation method. Finally because PSKap1 is
already installed, AP1 starts immediately the 4-way handshake. We
have used measurement tools such as ethereal and kismet to analyze
the measurements for the 4-way handshake and PANA authentication.
These measurements reflect different operations involved during
network-layer pre-authentication. In our experiment, as part of the
discovery phase, we assume that the MN is able to retrieve PAAs IP
address and all required information about AP1 and AP2 (e.g. channel,
security-related parameters, etc.) at some point before the handover.
This avoids the scanning during link-layer handoff. We have applied
this assumption to all three scenarios. Because our focus is on
reducing the time spent on authentication part during handoff, we do
not discuss the details of how we avoid the scanning.
Dutta, et al. Expires January 9, 2008 [Page 23]
Internet-Draft MPA Implementation July 2007
====================================================================
Types |802.11i | 802.11i | MPA-assisted
|Post | Pre | Layer 2
|Authentication | Authentication | Preauthentication
====================================================================
Operation | Non | Roaming | Non | Roaming |Non | Roaming|
| Roaming | | Roaming | |Roaming| |
===================================================================
Tauth | 61 ms | 599 ms | 99 ms | 638 ms | 177 ms| 831 ms|
-------------------------------------------------------------------
Tconf | -- | -- | -- | -- | 16 ms | 17ms |
-------------------------------------------------------------------
Tassoc+4 | | | | | | |
way | 18 ms | 17 ms | 16 ms | 17 ms | 16 ms | 17 ms |
------------------------------------------------------------------|
Total | 79 ms | 616 ms | 115 ms | 655 ms | 208 ms| 865 ms|
------------------------------------------------------------------|
Time | | | | | | |
affecting| 79 ms | 616 ms | 16 ms | 17 ms | 15 ms |17 ms |
handover | | | | | | |
------------------------------------------------------------------|
Figure 9: Results of MPA-assisted Layer 2 results
Figure 9 shows the timing (rounded off to the most significant
number) associated with some of the handoff operations we have
measured in the testbed. We describe each of the timing below.
Tauth refers to the execution of EAP-TLS authentication. This time
does not distinguish whether this authentication was performed during
pre-authentication or a typical post-authentication.
Tconf refers to time spent during PSK generation and installation
after EAP authentication is complete. In case of network-layer pre-
authentication is not used, this time is not considered.
Tassociation+4way refers to the time dedicated to the completion of
association and the 4-way handshake with the target AP after the
handoff.
4.4. FMIPv6 and MPA performance comparison
MPA and proactive FMIPv6 provide fast-handover techniques in
different fashion. However an initial experimental analysis
demonstrates that proactive handoff of FMIPv6 [RFC4068] and MPA over
IPv6 do exhibit similar performance characteristics. Both of these
approaches limit the handoff delay to layer 2 delay only. Some of
the performance results for proactive FMIPv6 [FMIP-results]
Dutta, et al. Expires January 9, 2008 [Page 24]
Internet-Draft MPA Implementation July 2007
demonstrate the fact that handoff delay is bounded by the layer 2
handoff delay. Without any layer 2 optimization and information
discovery techniques, experimental results from MPA also demonstrate
that the delay is bounded by layer 2 delay. However our experimental
results presented in this document are derived from an MPA prototype
augmented by the information discovery scheme proposed by IEEE
802.21. The information about the neighboring network elements helps
to reduce the layer 2 handoff delay contributed due to scanning and
layer 2 authentication. Besides optimizing layer 2 handoff
attributed due to scanning and authentication, MPA can also provide
pre-authentication support at layer 3 in case of inter-domain handoff
thereby reducing the delay due to layer 3 authentication during
handoff. MPA's optimized handoff techniques is not limited to MIPv6
only, but can also be used for other mobility protocols such as MIPv4
and SIP as well. In addition pre-authentication technique and
stateful pre-configuration technique associated with MPA can also be
used with FMIPV6 to enhance its operation in certain deployment
scenarios.
Dutta, et al. Expires January 9, 2008 [Page 25]
Internet-Draft MPA Implementation July 2007
5. Security Considerations
This document's intent is to describe different implementations of
the MPA framework defined in [I-D.ohba-mobopts-mpa-framework]. To
this end, any security concerns with this document are likely a
reflection of security concerns with the MPA framework itself.
Dutta, et al. Expires January 9, 2008 [Page 26]
Internet-Draft MPA Implementation July 2007
6. IANA Considerations
This document has no actions for IANA.
Dutta, et al. Expires January 9, 2008 [Page 27]
Internet-Draft MPA Implementation July 2007
7. Acknowledgments
We would like to thank Kensaku Fujimoto and Provin Gurung for MPA
prototype implementation support.
Dutta, et al. Expires January 9, 2008 [Page 28]
Internet-Draft MPA Implementation July 2007
8. References
8.1. Normative References
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-17 (work in
progress), June 2007.
8.2. Informative References
[RFC4881] El Malki, K., "Low-Latency Handoffs in Mobile IPv4",
RFC 4881, June 2007.
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[I-D.ohba-mobopts-mpa-framework]
Ohba, Y., "A Framework of Media-Independent Pre-
Authentication (MPA)", draft-ohba-mobopts-mpa-framework-04
(work in progress), March 2007.
[I-D.ohba-mobopts-heterogeneous-requirement]
Dutta, A., "Problem Statement for Heterogeneous Handover",
draft-ohba-mobopts-heterogeneous-requirement-01 (work in
progress), March 2006.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[802.21] "IEEE 802.21", IEEE .
[FMIP-results]
Cabellos-Apaicio, A., Nunez-Martinez, J., Julian-Bertomeu,
H., Jakab, L., Serral-Gracia, R., and J. Domingo-Pascual,
"Evaluation of Fast Handover Implementation for Mobile
Dutta, et al. Expires January 9, 2008 [Page 29]
Internet-Draft MPA Implementation July 2007
IPv6 in a Real Testbed", IPOM 2005 LNCS 3751.
[SIPMM] Schulzrinne, H. and E. Wedlund, "Application Layer
Mobility Using SIP", ACM MC2R.
Dutta, et al. Expires January 9, 2008 [Page 30]
Internet-Draft MPA Implementation July 2007
Authors' Addresses
Ashutosh Dutta
Telcordia Technologies
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 3130
Email: adutta@research.telcordia.com
Victor Fajardo
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5368
Email: vfajardo@tari.toshiba.com
Kenichi Taniuchi
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Email: rafa@dif.um.es
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5305
Email: yohba@tari.toshiba.com
Dutta, et al. Expires January 9, 2008 [Page 31]
Internet-Draft MPA Implementation July 2007
Kenichi Taniuchi
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5308
Email: ktaniuchi@tari.toshiba.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
Dutta, et al. Expires January 9, 2008 [Page 32]
Internet-Draft MPA Implementation July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dutta, et al. Expires January 9, 2008 [Page 33]