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]