mipshop Internet Draft P. McCann Document: draft-ietf-mipshop-80211fh-01.txt Lucent Technologies Expires: January 2005 July 2004 Mobile IPv6 Fast Handovers for 802.11 Networks Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Abstract This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 McCann Expires - January 2005 [Page 1] 802.11 Fast Handover July 2004 3. Deployment Architectures for Mobile IPv6 on 802.11.............4 4. 802.11 Handovers in Detail.....................................5 5. FMIPv6 Message Exchanges.......................................7 6. Beacon Scanning and NAR Discovery..............................7 7. Scenarios......................................................8 7.1 Scenario 1abcdef23456g.....................................9 7.2 Scenario ab123456cdefg.....................................9 7.3 Scenario 123456abcdefg....................................10 8. Security Considerations.......................................10 9. Conclusions...................................................11 10. References...................................................12 11. Acknowledgments..............................................13 12. Author's Address.............................................13 1. Introduction The Mobile IPv6 Fast Handover protocol [2] has been proposed as a way to minimize the interruption in service experienced by a Mobile IPv6 node as it changes its point of attachment to the Internet. Without such a mechanism, a mobile node cannot send or receive packets from the time that it disconnects from one point of attachment in one subnet to the time it registers a new care-of address from the new point of attachment in a new subnet. Such an interruption would be unacceptable for real-time services such as Voice-over-IP. The basic idea behind a Mobile IPv6 fast handover is to leverage information from the link-layer technology to either predict or rapidly respond to a handover event. This allows IP connectivity to be restored at the new point of attachment sooner than would otherwise be possible. By tunneling data between the old and new access routers, it is possible to provide IP connectivity in advance of actual Mobile IP registration with the home agent or correspondent node. This removes such Mobile IP registration, which may require time-consuming Internet round-trips, from the critical path before real-time service is re-established. The particular link-layer information available, as well as the timing of its availability (before, during, or after a handover has occurred), differs according to the particular link-layer technology in use. This document gives a set of deployment examples for Mobile IPv6 Fast Handovers on 802.11 networks. We begin with a brief overview of relevant aspects of basic 802.11 [3]. We examine how and when handover information might become available to the IP layers that implement Fast Handover, both in the network infrastructure and on the mobile node. Finally, we give details on how the proposed Mobile IPv6 Fast Handover protocol would work in this environment. McCann Expires - January 2005 [Page 2] 802.11 Fast Handover July 2004 2. Terminology This document borrows all of the terminology from Mobile IPv6 Fast Handovers [2], with the following additional terms from the 802.11 specification [3] (some definitions slightly modified for clarity): Access Point (AP): Any entity that has station functionality and provides access to the distribution services, via the wireless medium (WM) for associated stations. Association: The service used to establish access point/station (AP/STA) mapping and enable STA access to the Distribution System. Basic Service Set (BSS): A set of stations controlled by a single coordination function, where the coordination function may be centralized (e.g., in a single AP) or distributed (e.g., for an ad-hoc network). The BSS can be thought of as the coverage area of a single AP. Distribution System (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS). Extended Service Set (ESS): A set of one or more interconnected basic service sets (BSSs) and integrated local area networks (LANs) that appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. The ESS can be thought of as the coverage area provided by a collection of APs all interconnected by the Distribution System. It may consist of one or more IP subnets. Inter-Access Point Protocol (IAPP): A protocol defined for use between access points [4] at handover time that allows for the old association with the old AP to be deleted, and for context to be transferred to the new AP. Station (STA): Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). McCann Expires - January 2005 [Page 3] 802.11 Fast Handover July 2004 3. Deployment Architectures for Mobile IPv6 on 802.11 In this section we describe the two most likely relationships between Access Points (APs), Access Routers (ARs), and IP subnets that are possible in an 802.11 network deployment. Here we consider only the infrastructure mode [3] of 802.11. A given STA may be associated with one and only one AP at any given point in time; when a STA moves out of the coverage area of a given AP it must handover (re- associate) with a new AP. It is important to understand that 802.11 offers great flexibility, and that handover from one AP to another does not necessarily mean a change of AR or subnet. AR AR AR | AR AR | AR \ | / \ | / Subnet 1 Subnet 2 / / | \ \ / / | \ \ / / | \ \ / / | \ \ / | | | \ / | | | \ AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 AP9 AP10 Figure 1: An 802.11 deployment with relay APs. Figure 1 depicts a typical 802.11 deployment with two IP subnets, each with three Access Routers and five Access Points. Note that the APs in this figure are acting as link-layer relays, which means that they transport Ethernet-layer frames between the wireless medium and the subnet. Each subnet is implemented as a single LAN or VLAN. Note that a handover from AP1 to AP2 does not require a change of AR because all three ARs are link-layer reachable from a STA connected to any AP1-5. Therefore, such handoffs are outside the scope of IP- layer handover mechanisms. However, a handoff from AP5 to AP6 would require a change of AR, because the STA would be attaching to a different subnet. An IP-layer handover mechanism would need to be invoked in order to provide low-interruption handover between the two ARs. Internet / | \ / | \ / | \ AR AR AR AP1 AP2 AP3 Figure 2. An 802.11 deployment with integrated APs/ARs. McCann Expires - January 2005 [Page 4] 802.11 Fast Handover July 2004 Figure 2 depicts an alternative 802.11 deployment where each AP is integrated with exactly one AR. In this case, every change of AP would result in a necessary change of AR, which would require some IP-layer handover mechanism to provide for low-interruption handover between the ARs. Also, the AR shares a MAC-layer identifier with its attached AP. In the next section, we examine the steps involved in any 802.11 handover. Subsequent sections discuss how these steps could be integrated with an IP-layer handover mechanism in each of the above deployment scenarios. 4. 802.11 Handovers in Detail An 802.11 handover takes place when a STA changes its association from one AP to another ("re-association"). This process consists of the following steps: 1. The STA performs a scan to see what APs are available. The result of the scan is a list of APs together with physical layer information, such as signal strength. 2. The STA chooses one of the APs and performs a join to synchronize its physical and MAC layer timing parameters with the selected AP. 3. The STA requests authentication with the new AP. For an "Open System", such authentication is a single round-trip message exchange with null authentication. 4. The STA requests association or re-association with the new AP. A re-association request contains the MAC-layer address of the old AP, while a plain association request does not. 5. If operating in accordance with the IAPP [4], the new AP performs a lookup based on MAC-layer address to obtain the IP address of the old AP by consulting a local table or RADIUS server. It opens a UDP or TCP connection, protected by IPSec encryption, to the old AP. Via the secure connection, it informs the old AP of the re-association so that information about the STA is deleted from the old AP. Note that IAPP can only be invoked based on a re-association message, as the plain association message does not contain the old AP's MAC-layer address. McCann Expires - January 2005 [Page 5] 802.11 Fast Handover July 2004 6. The new AP sends a Layer 2 Update frame on the local LAN segment to update the learning tables of any connected Ethernet bridges. Note that in some existing 802.11 implementations, steps 1-4 are performed by firmware that is on-board the 802.11 PCMCIA card. This might make it impossible for the host to take any actions (including sending or receiving IP packets) before the handoff is complete. In other 802.11 implementations, it is possible to invoke the scan (step 1) and join (step 2) operations independently under host control. This would make it possible to, e.g., perform step 1 far in advance of the handover and perhaps in advance of any real-time traffic. This could substantially reduce the handover latency, as one study has concluded that the 802.11 beacon scanning function may take several hundred milliseconds to complete [5] during which time sending and receiving IP packets is not possible. However, scanning too far in advance may make the information out-of-date by the time of handoff, which would cause the subsequent join operation to fail if radio conditions have changed so much in the interim that the target AP is no longer reachable. A given implementation of FMIPv6 over 802.11 must weigh this tradeoff carefully. Even if steps 1 and 2 are performed in rapid succession, there is no guarantee that an AP found during step 1 will be available during step 2 because radio conditions can change dramatically from moment to moment. The STA may then decide to associate with a completely different AP. Often, this decision is implemented in firmware and the attached host would have no control over which AP is chosen. There is no standardized trigger for step 1. It may be performed as a result of decaying radio conditions on the current AP or at other times as determined by local implementation decisions. During step 5, IAPP is used to communicate with the old AP. The IPSec tunnel between the two APs is originally established with key distribution via RADIUS, but can be subsequently re-used for different MNs that may need to handover between the same pair of APs. Note that the SA is between the pair of APs and has nothing to do with any security association that might be in place between the MN and either of the APs. During IAPP operation, link-layer context may be transferred from the old AP to the new AP. The IAPP defines a container for context information. However, no such context has currently been defined or standardized by IEEE. The coverage area of a single AP is known as a Basic Service Set (BSS). Note that both APs in the above description are considered to belong to the same Extended Service Set (ESS). This is to trigger a re-association (rather than plain association) from the STA, which contains information about both the old and new AP. All APs should McCann Expires - January 2005 [Page 6] 802.11 Fast Handover July 2004 therefore broadcast the same ESSID. If two APs belong to different administrative domains, this may require some inter-domain coordination of the ESSID. Otherwise, there may not be sufficient information to construct the link-layer triggers required by some handover mechanisms. A change of BSS within an ESS may or may not require an IP-layer handover, depending on whether the APs provide STAs access to different or the same IP subnets. If an IP-layer handover is required, then FMIPv6 may be used to decrease the overall latency of the handover. The main goal of this document is to describe the most reasonable scenarios for how the events of an 802.11 handover may interleave with the message exchanges in FMIPv6. 5. FMIPv6 Message Exchanges An FMIPv6 handover nominally consists of the following messages: a. The MN sends a Router Solicitation for Proxy (RtSolPr) to find out about neighboring ARs. b. The MN receives a Proxy Router Advertisement (PrRtAdv) containing one or more [AP-ID, AR-Info] tuples. c. The MN sends a Fast Binding Update (FBU) to the Previous Access Router (PAR). d. The PAR sends an HI message to the New Access Router (NAR). e. The NAR sends a HAck message to the PAR. f. The PAR sends a Fast Binding Acknowledgement (FBack) message to the MS the new link. The FBack is also optionally sent on the previous link if the FBU was sent from there. g. The MN sends FNA to the NAR after attaching to it. The MN may connect to NAR prior to sending the FBU if the handover is un-anticipated. In this case, the FNA (step g) would contain the FBU (listed as step c above) and then steps d, e, and f would take place from there. 6. Beacon Scanning and NAR Discovery The RtSolPr message is used to request information about the router(s) connected to one or more APs. The APs are specified by link layer address in the RtSolPr and associated IP-layer information McCann Expires - January 2005 [Page 7] 802.11 Fast Handover July 2004 is returned in the PrRtAdv. In the case of an 802.11 link, the link layer address is the BSSID of some AP. Beacon scanning (step 1 from Section 4) produces a list of available APs along with signal strength information for each. This list would supply the necessary BSSIDs to fill into the RtSolPr messages. To obtain this list the host needs to invoke the MLME-SCAN.request primitive (See Section 10.3.2.1 of the 802.11 specification [3]). Because beacon scanning takes on the order of a few hundred milliseconds to complete, and because it is generally not possible to send and receive IP packets during this time, the MN needs to schedule these events with care so that they do not disrupt ongoing real-time services. For example, the scan could be performed at the time the MN attaches to the network prior to any real-time traffic. However, if the interval between scanning and handoff is too long, the neighbor list may be out of date. For example, the signal strengths of neighboring APs may have dramatically changed, and a handoff directed to the apparently best AP from the old list may fail. If the handoff is executed in firmware, the STA may even choose a new target AP that is entirely missing from the old list (after performing its own scan). Both cases would limit the ability of the MN to choose the correct NAR for the FBU in step c during an anticipated handover. Note that, aside from physical layer parameters such as signal strength, it may be possible to obtain all necessary information about neighboring APs by using the wildcard form of the RtSolPr message. This would cause the current access router to return a list of neighboring APs, and would not interrupt ongoing communication with the current AP. This request could be made at the time the MN first attaches to the access router, and periodically thereafter. This would enable the MN to cache the necessary [AP-ID, AR-Info] tuples and might enable it to react more quickly when a handover becomes necessary due to a changing radio environment. However, because the information does not include up-to-date signal strength, it would not enable the MN to predict accurately the next AP prior to a handoff. Also, if the scale of the network is such that a given access router is attached to many APs, then it is possible that there may not be room to list all APs in the PrRtAdv. 7. Scenarios In this section we look at a few of the possible scenarios for using FMIPv6 in an 802.11 context. Each scenario is labeled by the sequence of events that take place, where the numbered events are from Section 4 and the lettered events are from Section 5. For example, "1abcde23456fg" is the sequence where the MN performs a McCann Expires - January 2005 [Page 8] 802.11 Fast Handover July 2004 scan, then the MN executes the FMIPv6 messaging to obtain NAR information and send a binding update, then the PAR initiates HI/HAck exchange, then the 802.11 handover completes, and finally the HAck is received at the PAR and the MN sends an FNA. Each scenario is followed by a brief description and discussion of the benefits and drawbacks. 7.1 Scenario 1abcdef23456g This scenario is the predictive mode of operation from the FMIPv6 specification. In this scenario, the host executes the scan sometime prior to the handover, and is able to execute most of the FMIPv6 protocol prior to handover. Only the FNA is sent after the handoff. This mode of operation requires that the scan and join operations (steps 1 and 2) can be performed separately and under host control, so that steps a-f can be inserted between 1 and 2. Steps 1ab may be executed far in advance of the handover, which would remove them from the critical path. This would minimize the service interruption from beacon scanning, and allow at least one RtSolPr/PrRtAdv exchange to complete so that the host has link layer information about some NARs. Note that if steps ab were delayed until handoff is eminent, there would be no guarantee that the RtSolPr/PrRtAdv exchange would complete especially in a radio environment where the connection to the old AP is deteriorating rapidly. However, if there were a long interval between the scan and the handover, then the FBU (step c) would be created with out-of-date information. There is no guarantee that the MN will actually attach to the desired new AP after it has sent the FBU to the oAR, because changing radio conditions may cause nAR to be suddenly unreachable. If this is the case, then the handoff would need to devolve into one of the reactive cases given below. 7.2 Scenario ab123456cdefg This is the reactive mode of operation from the FMIPv6 specification. This scenario does not require host intervention between steps 1 and 2. However, it does require that the MN obtain the link-layer address of NAR prior to handover, so that it has a link-layer destination address for outgoing packets (default router information). This would then be used for sending the FNA (with encapsulated FBU) when it reaches the new subnet. McCann Expires - January 2005 [Page 9] 802.11 Fast Handover July 2004 7.3 Scenario 123456abcdefg In this scenario the MN does not obtain any information about the NAR prior to executing the handover. It is completely reactive, and consists of soliciting a router advertisement after handover, and then sending an FNA with encapsulated FBU immediately. This scenario may be appropriate when it is difficult to learn the link-layer address of the NAR prior to handover. This may be the case, e.g., if the scan primitive is not available to the host and the wildcard PrRtAdv form returns too many results. It may be possible to skip the router advertisement/solicitation steps (ab) in some cases, if it is possible to learn the NAR's link-layer address through some other means. In the deployment illustrated in Figure 2, this would be exactly the new AP's MAC layer address, which can be learned from the link-layer handoff messages. However, in the case of Figure 1, this information must be learned through router discovery of some form. Also note that even in the case of Figure 2, the MN must somehow be made aware that it is in fact operating in a Figure 2 network and not a Figure 1 network. 8. Security Considerations The FBU message (the only FMIPv6 message that sets up forwarding state) is protected by well-understood Mobile IPv6 security mechanisms, so the PAR can guarantee it was actually generated by the MS. However, if the association with the new AP is not protected using mutual authentication, it may be possible for a rogue AP to fool the MN into sending an FBU to the PAR when it is not in its best interest to do so. There are several security issues of note with the underlying 802.11 handoff mechanisms. Note that steps 5 and 6 from Section 4 install layer-2 forwarding state that can redirect user traffic and cause disruption of service if they can be triggered by malicious nodes. Note that step 3 from Section 4 could potentially provide some security; however, due to the identified weaknesses in WEP shared key security [6], there is currently no authentication algorithm for step 3 that is both standardized and secure. It may be the case that many deployments are configured as "Open Systems", which will rely instead on higher-layer authentication such as 802.1X Port-Based Network Access Control [7]. According to published standards, such authentication techniques would happen only after association or re-association takes place, which leaves the re- association messages unprotected. This would allow malicious nodes to redirect traffic to a different AP on the same subnet. Work is McCann Expires - January 2005 [Page 10] 802.11 Fast Handover July 2004 currently underway to better integrate 802.1X with 802.11 [8] but it is not yet complete. The 802.1X standard defines a way to encapsulate EAP on 802 networks (EAPOL, for "EAP over LANs"). With this method, the client and AP participate in an EAP exchange which itself can encapsulate any of the various EAP authentication methods. The EAPOL exchange can output a master key, which can then be used to derive transient keys, which in turn can be used to encipher/authenticate subsequent traffic. It is possible to use 802.1X pre-authentication [8] between a STA and a target AP while the STA is associated with another AP; this would enable authentication to be done in advance of handover, which would both protect the re-association message and allow fast resumption of service after roaming. However, because EAPOL frames carry only MAC-layer instead of IP-layer addresses, this is currently only specified to work within a single subnet, where IP layer handoff mechanisms are not needed anyway. In our case (roaming across subnet boundaries) the 802.1X exchange would need to be performed after roaming to, but prior to re-association with, the new AP. This would introduce additional handover delay while the 802.1X exchange takes place, which may also involve round-trips to RADIUS or Diameter servers. Perhaps faster cross-subnet authentication could be achieved by leveraging the context transfer features of the IAPP to carry security credentials, or with the use of pre-authentication using an IP-layer mechanism that would cross subnet boundaries. To our knowledge this sort of work is not currently underway in the IEEE. The security considerations of these new approaches would need to be carefully studied. 9. Conclusions The Mobile IPv6 Fast Handoff specification presents a protocol for shortening the period of service interruption during a change in link-layer point of attachment. This document attempts to show how this protocol may be applied in the context of 802.11 access networks. There are currently serious security problems in the published specifications that define the 802.11 handover process that must be fixed before even intra-subnet mobility can be considered secure. In-progress specifications may fix these problems but may also introduce additional delay for handover across different subnets. Usually, only the APs themselves are aware that good link-layer security is in place. This information could be made available to ARs with the use of a new protocol, but such mechanisms are prone to be link-layer specific. McCann Expires - January 2005 [Page 11] 802.11 Fast Handover July 2004 The particular implementation of the 802.11 hardware and firmware may dictate how FMIPv6 is able to operate. For example, to execute a predictive handover, the scan request primitive must be available to the host and the firmware must execute join operations only under host control, not autonomously in response to its own handoff criteria. Obtaining the desired PrRtAdv and sending an FBU immediately prior to handover requires that messages be exchanged over the wireless link during a period when connectivity is degrading. In some cases the scenario given in Section 7.1 may not complete successfully or the FBU may redirect traffic to the wrong NAR. However, in these cases it seems that the scenario from Section 7.2 or at worst the scenario from Section 7.3 present reasonable fall-back strategies. 10. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2 Koodli, R. (editor), "Fast Handovers for Mobile IPv6", draft-ietf- mipshop-fast-mipv6-01.txt, February 2004. Work In Progress. 3 "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition. 4 "Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE Std 802.11f/D4, July 2002. Work In Progress. 5 Mitra, A., Shin, M., and Arbaugh, W., "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, University of Maryland Department of Computer Science, September 2002. 6 Borisov, N., Goldberg, I., and Wagner, D., "Intercepting Mobile Communications: The Insecurity of 802.11", Proceedings of the Seventh Annual International Conference on Mobile Computing and Networking, July 2001, pp. 180-188. 7 "Port-Based Network Access Control", IEEE Std 802.1X-2001, October, 2001. 8 "Draft Supplement to IEEE 802.11: Specification for Enhanced Security", IEEE Std 802.11i/D2.2, July 2002. Work In Progress. McCann Expires - January 2005 [Page 12] 802.11 Fast Handover July 2004 11. Acknowledgments Thanks to Bob O'Hara for providing explanation and insight on the 802.11 standards. Thanks to James Kempf, Erik Anderlind, and Rajeev Koodli for providing comments on an earlier draft. 12. Author's Address Pete McCann Lucent Technologies Rm 9C-226R 1960 Lucent Lane Naperville, IL 60563 Phone: +1 630 713 9359 Fax: +1 630 713 1921 Email: mccap@lucent.com McCann Expires - January 2005 [Page 13] 802.11 Fast Handover July 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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 At the time of submission the author is not aware of any intellectual property rights that pertain to the implementation or use of the technology described in this document. However, this does not preclude the possibility that Lucent Technologies, Inc. or other entities may have such rights. The patent licensing policy of Lucent Technologies, Inc. is on file with the IETF Secretariat. 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. McCann Expires - January 2005 [Page 14] 802.11 Fast Handover July 2004 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McCann Expires - January 2005 [Page 15]