MOBOPTS Research Group V. Fajardo (Ed.) Internet-Draft TARI Expires: April 25, 2007 A. Dutta Telcordia Y. Ohba K. Taniuchi R. Lopez TARI H. Schulzrinne Columbia Univ. October 22, 2006 Media-Independent Pre-Authentication (MPA) Implementation Results draft-ohba-mobopts-mpa-implementation-03 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 April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an initial implementation of Media- Fajardo (Ed.), et al. Expires April 25, 2007 [Page 1] Internet-Draft MPA Implementation October 2006 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 could be leveraged to realize the functionalities of MPA. It also includes empirical results gathered from experiments performed on a simulated network where the implementation resides. 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 Fajardo (Ed.), et al. Expires April 25, 2007 [Page 2] Internet-Draft MPA Implementation October 2006 1. Introduction Media-independent Pre-Authentication (MPA), is a new handover optimization mechanism that provides mobility optimization that is decoupled from existing mobility management schemes. It is designed to support a mobile terminal with one or more interfaces and is capable of securely crossing administrative domains. It also easily integrates with existing mobility management protocols. The MPA architecture is described in [I-D.ohba-mobopts-mpa-framework]. This document accompanies MPA architectural document [I-D.ohba- mobopts-mpa-framework] and it provides practical methods of implementing 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 succeeding sections also describe specific scenarios where both MPA and non-MPA approaches are evaluated and results of their comparison are described. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 3] Internet-Draft MPA Implementation October 2006 2. Network Topology of MPA Testbed For the MPA evaluation, two(2) testbeds where developed each using a different mobility management protocol (MMP). The first implementation uses Mobile IPv6 (MIPv6) and the second uses SIP Mobility (SIP-M). The results of the test from both testbeds are described in the succeeding chapters. These results are also compared against a non-MPA scenario and describes 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 3 Network 4 (oPoA) (nPoA) +-------------+ | Mobile IPv6 | ------------------------------------------| Home Agent | | | (HA) | | +-------------+ +--------+ +------------+ |Router 1|---------|Router 2(RA)|---------+ +---+----+ |PAA(AA) | | | |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 and Fajardo (Ed.), et al. Expires April 25, 2007 [Page 4] Internet-Draft MPA Implementation October 2006 finally 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 schemes 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 IP continuity of the RTP traffic. Details of the topology of is 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 averted. * 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/ 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 optinal kernel based network buffer for packet loss protection. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 5] Internet-Draft MPA Implementation October 2006 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 additionally created between the MN and R2 in Network 2. In the testbed, this tunnel is based on IPsec tunnel mode ESP and 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 not impact on the overall scheme. 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 6] Internet-Draft MPA Implementation October 2006 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 As an initial state the MN associates itself with AP 1. It configures based on a statically configure 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 using the RAT (Robust Audio Tool) media agent. 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 some localized policy that includes monitoring the MN's signal strength or Fajardo (Ed.), et al. Expires April 25, 2007 [Page 7] Internet-Draft MPA Implementation October 2006 maybe an 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 these information are locally stored on the 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. Such parameters include nCoA and are communicated back via PANA messaging. As part of the MIPv6 functions, the MN sends a 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 naturally forwards 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 'X'. In the testbed, an optional packet buffering mechanism has been implemented to assist during handover. Prior to handover, setp 4 in Figure 2, the MN signals R2 so that buffering of packets that is destined for the MN can begin. So during the handover, R2 buffers all packets that is already in transit and has a 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 has to wait until all buffered packets has been forwarded. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 8] Internet-Draft MPA Implementation October 2006 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 (3) 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 Fajardo (Ed.), et al. Expires April 25, 2007 [Page 9] Internet-Draft MPA Implementation October 2006 * 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 is shown in Figure 4. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 10] Internet-Draft MPA Implementation October 2006 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 Relay | | | | | | |<--------->| | | 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 As an initial state 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 streaming 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 11] Internet-Draft MPA Implementation October 2006 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 Fajardo (Ed.), et al. Expires April 25, 2007 [Page 12] Internet-Draft MPA Implementation October 2006 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 is also shown in Section 4 and is consistent with MIPv6 results with buffering. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 13] Internet-Draft MPA Implementation October 2006 3. Non-MPA Assisted Handover Scenario For the 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 make a good comparison with the MPA scenario, the MN boostraps 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 14] Internet-Draft MPA Implementation October 2006 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 Fajardo (Ed.), et al. Expires April 25, 2007 [Page 15] Internet-Draft MPA Implementation October 2006 4. Evaluation and Performance Results We have experimented 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, Inter- domain, II) Inter-technology, 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 (3) 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 is a mean value in millisecond. o L3 handoff measurements are based on linux network layer configuration including routing table updates, neighbhor cache or ARP table updates and interface address assignment. Measurement is a mean value in millisecond. o Avg. packet loss is number of packets that failed to reach the MN during L2 and L3 handoff periods. Measurement is a mean value. o Avg. 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 RTP traffic comes from. However, it should also include the propagation time from CN to MN including tunneling (MIPv6 and IPsec) but this propagation time is orders of magnitude smaller than the packet generation rate. The measured value of this is 16 msec. o Avg. inter-packet arrival time during handover is the amount of time in msec between the last RTP packet received by the MN before Fajardo (Ed.), et al. Expires April 25, 2007 [Page 16] Internet-Draft MPA Implementation October 2006 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 Avg. 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-athentication 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 Helsinkin University of Technology (HUT) implementation of Mobile IPv6. The results for MIPv6 and SIP mobility are shown in Figure 6 and Figure 7, respectively. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 17] Internet-Draft MPA Implementation October 2006 Buffering Buffering Buffering Buffering (disabled) (enabled) (disabled) (enabled) RO RO RO RO (disabled) (disabled) (enabled) (enabled) ------------------------------------------------------------------- L2 handoff (msec) 4.00 4.33 4.00 4.00 L3 handoff (msec) 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 (msec) Avg. inter-packet n/a 45.33 n/a 66.60 arrival time during handover (msec) Avg. packet jitter n/a 29.33 n/a 50.60 (msec) Buffering Period n/a 50.00 n/a 50.00 (msec) Buffered Packets n/a 2.00 n/a 3.00 Figure 6: Mobile IPv6 with MPA Results Fajardo (Ed.), et al. Expires April 25, 2007 [Page 18] Internet-Draft MPA Implementation October 2006 Buffering Buffering disabled enabled ----------------------------------------------- L2 handoff (msec) 4.00 5.00 L3 handoff (msec) 1.00 1.00 Avg. packet loss 1.50 0 Avg. inter-packet 16.00 16.00 arrival interval (msec) Avg. inter-packet n/a 29.00 arrival time during handover (msec) Avg. packet jitter n/a 13.00 (msec) Buffering Period n/a 20.00 (msec) 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 Fajardo (Ed.), et al. Expires April 25, 2007 [Page 19] Internet-Draft MPA Implementation October 2006 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 20] Internet-Draft MPA Implementation October 2006 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 21] Internet-Draft MPA Implementation October 2006 +------------------+ | +-----+ | 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- Fajardo (Ed.), et al. Expires April 25, 2007 [Page 22] Internet-Draft MPA Implementation October 2006 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 23] Internet-Draft MPA Implementation October 2006 ==================================================================== 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] Fajardo (Ed.), et al. Expires April 25, 2007 [Page 24] Internet-Draft MPA Implementation October 2006 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 25] Internet-Draft MPA Implementation October 2006 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. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 26] Internet-Draft MPA Implementation October 2006 6. IANA Considerations This document has no actions for IANA. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 27] Internet-Draft MPA Implementation October 2006 7. Acknowledgments We would like to thank Kensaku Fujimoto and Provin Gurung for MPA prototype implementation support. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 28] Internet-Draft MPA Implementation October 2006 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-12 (work in progress), August 2006. 8.2. Informative References [I-D.ietf-mobike-design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", draft-ietf-mobike-design-08 (work in progress), March 2006. [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-02 (work in progress), March 2006. [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, Fajardo (Ed.), et al. Expires April 25, 2007 [Page 29] Internet-Draft MPA Implementation October 2006 H., Jakab, L., Serral-Gracia, R., and J. Domingo-Pascual, "Evaluation of Fast Handover Implementation for Mobile IPv6 in a Real Testbed", IPOM 2005 LNCS 3751. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 30] Internet-Draft MPA Implementation October 2006 Authors' Addresses Victor Fajardo Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5368 Email: vfajardo@tari.toshiba.com Ashutosh Dutta Telcordia Technologies 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 3130 Email: adutta@research.telcordia.com Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5305 Email: yohba@tari.toshiba.com Kenichi Taniuchi Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5308 Email: ktaniuchi@tari.toshiba.com Fajardo (Ed.), et al. Expires April 25, 2007 [Page 31] Internet-Draft MPA Implementation October 2006 Kenichi Taniuchi Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Email: rafa@dif.um.es 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 Fajardo (Ed.), et al. Expires April 25, 2007 [Page 32] Internet-Draft MPA Implementation October 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fajardo (Ed.), et al. Expires April 25, 2007 [Page 33]