MOBOPTS Research Group A. Dutta Internet-Draft Telcordia Expires: January 2, 2006 Y. Ohba K. Taniuchi V. Fajardo (Ed.) TARI H. Schulzrinne Columbia Univ. July 2005 Media-Independent Pre-Authentication (MPA) Implementation Results draft-ohba-mobopts-mpa-implementation-00 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 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes an initial implementation of Media- independent Pre-Authentication (MPA) optmization. MPA is a mobile- assisted, secure handover optimization scheme that works over any Dutta, et al. Expires January 2, 2006 [Page 1] Internet-Draft MPA Implementation July 2005 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 result gathered from experiments performed on a simulation network where the implementation resides. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Network Topology of MPA Testbed . . . . . . . . . . . . . . . 4 3. MPA Assisted Handover Scenario . . . . . . . . . . . . . . . . 6 4. Non-MPA Assisted Handover Scenario . . . . . . . . . . . . . . 9 5. Evaluation and Performace Results . . . . . . . . . . . . . . 11 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Normative References . . . . . . . . . . . . . . . . . . . 13 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Dutta, et al. Expires January 2, 2006 [Page 2] Internet-Draft MPA Implementation July 2005 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 one method of implementating MPA. It also describes performace results gathered from the implementation experience and can clearly show how one can use exsiting protocols to provide MPA functionality. The succeeding sections also describes specific scenarios where both MPA and non-MPA approaches are evaluated and results of thier comparison is described. Dutta, et al. Expires January 2, 2006 [Page 3] Internet-Draft MPA Implementation July 2005 2. Network Topology of MPA Testbed The experimental MPA network topology is shown in Figure 1. Network 1 Network 2 Network 3 (oPoA) (nPoA) +--------+ +------------+ |Router 1|---------|Router 2(RA)|---------+ +---+----+ |PAA(AA) | | | |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 1: Network Topology There are three networks defined in the implementation environment. Network 1 is old point of attachment (oPoA), Network 2 is new point of attachment (nPoA), and network 3 is where the correspondent node (CN) resides. The mobile node (MN) is initially in Network 1 and starts communicating with the CN. Network 1, network 2, and network 3 do not need to be adjacent. However, in the test scenario, network 1, network 2 and network 3 are one IP hop away. During handoff, a specific Mobility Management Protocol (MMP) can take care of the IP continuity of the streaming traffic. Network 1 consists of DHCP Server 1, access point (AP) 1 and Access Router 1. Network 2 consists a DHCP Server 2, AP 2 and Access Router 2. AP 1 and AP 2 are 802.11 wireless LAN access points. Router 2 also works as a PANA Authentication Agent (PAA) [I-D.ietf-pana-pana] and a DHCP Relay Agent [RFC3046] for Network 2, though they do not have to be co-located. DHCP relay-agent also acts like a Configuration Agent (CA) that helps obtaining the IP address assignments for the mobile during pre-authentication. Network 3 Dutta, et al. Expires January 2, 2006 [Page 4] Internet-Draft MPA Implementation July 2005 consists of the CN that communicates with the MN in Network 1. Both the CN and MN are equipped with mobility enabled SIP client. Mobile SIP client is also equipped with PANA Client (PaC). To simplify the scenario, SIP proxies are not involved to set up the initial communication between the CN and MN. The MN uses 802.11 wireless LAN interfaces and associates with AP 1 prior to handoff. During the handoff process, the MN moves to Network 2 by associating with AP 2. The Mobility Management Protocol (MMP) is SIP Mobility (SIP-M). The configuration protocol is DHCP and the authentication agent (AA) is a PANA PAA. The configuration agent (CA) is DHCP Relay Agent. The Access Router (AR) Router 2 provides IP-in-IP tunneling [RFC1853] to facilitate routing via the MN's pre-provisioned IP address on Network 2. In turn, the MN also has a corresponding IP-in-IP tunneling management function to match Router 2. Although, the current testbed uses IPv4 but it is not limited to it. MIPv6 or SIP mobility over IPv6 can also be used to provide the same functionality. Dutta, et al. Expires January 2, 2006 [Page 5] Internet-Draft MPA Implementation July 2005 3. MPA Assisted Handover Scenario The communication flow for MPA test environment is described below and is represented in Figure 2 Step 0: As the MN bootstraps, it associates itself with AP 1 and obtains the IP address from DHCP Server 1 in Network 1. This IP address is the old Care of Address (oCoA). Then the MN's SIP user agent attempts to connect with the CN's SIP user agent. After a successful SIP connection, voice traffic is initiated and it flows between from CN to MN. The voice traffic is carried over RTP/UDP using the RAT (Robust Audio Tool) media agent. Step 1: 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 level going down" event [802.21]. In anycase, pre- authentication prepares the MN to start 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 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 with the PAA and derives proper security keys which defines the security association (SA) between the MN and Network 2. 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. Note that the DHCP Proxy gets the IP address from DHCP Server 2. The new IP address is relayed back to the MN as part of the pre-authentication process. This IP address is the new Care of Address (nCoA) and is usable in Network 2. Once the MN gets the nCoA, it configures this address on a virtual interface and sets up an IP-in-IP tunnel to Router 2. The IP-in-IP tunneling between MN and Router 2 can be best be described in [RFC1853] where the signaling can be cryptographically protected by using the MN-CA key. Step 3: The MN performs proactive secure handover of application traffic. Since the MN is configured with the nCoA and an IP-in-IP tunnel has been created, the MN can send a SIP Re-invite to CN with nCoA as its new contact address. In the testbed, all traffic between Dutta, et al. Expires January 2, 2006 [Page 6] Internet-Draft MPA Implementation July 2005 CN and MN will be carried over the tunnel once SIP Re-invite finishes. This includes the RTP/UDP traffic that was initiated in Step 0. Steps 4, 5 and 6: The MN performs secure proactive handover pre- switching, switching and post-switching phase. 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 assigning the nCoA to its physical interface and updates its local default route information with the default route information for Network 2 obtained in step 2. The MN then sends a PANA- Update-Request message to the access router R2. The purpose of this message is to tear down the IP-in-IP tunnel between MN and R2. The MN will delete the tunnel end-point local to itself prior to sending PANA-Update-Request and R2 will delete its tunnel end-point once it receives the PANA-Update-Request. 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 used in a network. Dutta, et al. Expires January 2, 2006 [Page 7] Internet-Draft MPA Implementation July 2005 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 Router 2 | | |<-------------------------------------->| | | | Step 3 SIP Re-invite | | | | |<======================================>|<------------------>| |Voice traffic goes through IP in IP tunnel | | |<======================================>|<------------------>| | Step 4 Deletion of the tunnel | | | |<-------------------------------------->| | | X Step 5 Association with AP 2| | | | X<- - - - - - - - - - - - - - >| | | | X Voice traffic goes to nCoA | | | | |<----------------------------------------------------------->| <- - - - ->802.11 frame <--------->IP packet <=========>IP in IP tunneling packet X Voice Packet loss is happened. Figure 2: MPA Communication Flow in the Test Environment Dutta, et al. Expires January 2, 2006 [Page 8] Internet-Draft MPA Implementation July 2005 4. Non-MPA Assisted Handover Scenario For the comparison purposes, non-MPA assisted handover is also described in this section. The non-MPA scheme does not provide any proactive handover mechanism as such but follows standard handover procedure. The following are the steps involved in the non-MPA scheme. The steps involved as part of bootstrap process remains the same as in step 0 of the MPA assisted case. This scenario also uses the same localized policy as with the MPA assisted handover to decide when handover should begin, i.e. signal strength. Step 1: The MN disassociates with AP 1 and associates with AP 2. On successful association, it obtains an IP address from DHCP Server 2, then assigns that address to its network interface. At this point, no data can flow through R2 for the MN since MN is not yet authenticated in Network 2. Step 2: The MN authenticates with the PAA. Since the authentication period happens as part of the handover, it adds delays in the overall handover process. Once authentication is successful, forwarding of packets for the MN will be allowed in Network 2. Step 3: The MN sends SIP Re-invite with the new IP address obtained from the DHCP server in the Network 2 which causes the voice traffic to be forwarded to the MN which is now in Network 2. This binding update could have potentially taken potentially a longer amount of time if the MB's target network and the CN are far apart. Dutta, et al. Expires January 2, 2006 [Page 9] Internet-Draft MPA Implementation July 2005 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 Voice Packet loss is happened. Figure 3: Communication Flow for Non-MPA Assisted Handover in the Test Environment Dutta, et al. Expires January 2, 2006 [Page 10] Internet-Draft MPA Implementation July 2005 5. Evaluation and Performace Results In case of MPA assisted handover, there is no packet loss during pre- authentication before link-layer handover takes place. Delay and packet loss is observed during the actual link-layer handover. Delay is also introduced in the network layer during tunnel deletion and IP address re-assignments. The total observed handover delay is limited to 170 ms. The traffic rate is approximately one pacekt every 20 msec (though the RTP source does not equally space them). This amounts to an observable packet loss of 6 RTP packets during the entire handover period. Optimizing the link-layer delay using a scheme such as [MACD] will further reduce the packet loss. It is important to note that the scheme described in [MACD] uses HOSTAP driver only. It is also noted that the end-host processing contributes to the handoff delay such as tunnel deletion and signal processing. Thus further system optimizations can still help reduce the handoff delay. 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 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. Dutta, et al. Expires January 2, 2006 [Page 11] Internet-Draft MPA Implementation July 2005 6. Notes In the testbed, a 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. Protocols used in the testbed can always be replaced by the other existing protocols. For example, Mobility management protocol can be replaced by Mobile IPv4 or Mobile IPv6. In such case, the Home Agent (HA) could be in Network 3, similarly the tunnel management protocol can always be replaced by IKEv2 and IPsec tunnel mode. It is normal to assume that the performance results will be differ based on the type of protocols used. The test results also show that link-layer delay can vary based on the drivers and operating system used. Some examples of link-layer are Cisco Aironet 350 which takes almost 200- 300 ms under Linux 2.4.x operating system. Orinoco and Dlink using Hostap drivers takes around 100-160 ms and 400-600 ms respectively under Linux 2.4.x operating system. Though the Orinoco card takes about 250 ms under Windows XP using pre-packaged drivers. Hostap driver with managed mode takes about 30 ms and is comparable to that obtained by [MACD]. Dutta, et al. Expires January 2, 2006 [Page 12] Internet-Draft MPA Implementation July 2005 7. References 7.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-08 (work in progress), May 2005. 7.2 Informative References [I-D.ietf-mobike-design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-02 (work in progress), February 2005. [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-00 (work in progress), February 2005. [802.21] "IEEE 802.21", IEEE . [MACD] Shin, S., "Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs", MOBIWAC Workshop . Dutta, et al. Expires January 2, 2006 [Page 13] Internet-Draft MPA Implementation July 2005 Authors' Addresses 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 Victor Fajardo Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5308 Email: ktaniuchi@tari.toshiba.com Dutta, et al. Expires January 2, 2006 [Page 14] Internet-Draft MPA Implementation July 2005 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 2, 2006 [Page 15] Internet-Draft MPA Implementation July 2005 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 (2005). 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. Dutta, et al. Expires January 2, 2006 [Page 16]