Scalable voip mobility intedration and deployment- P26 potx

250 Chapter 6 www.newnespress.com 3. At this point, if the new access point is on a different channel, the client will change the channel of its receiver. 4. If the new channel is a DFS channel, the client is required to wait until it receives a beacon frame from the access point, unless it has recently heard one as a part of a passive scanning procedure. 5. The client will send an Authentication message to the new access point, establishing the beginnings of a relationship with this new access point, but not yet enabling data services. 6. The access point will respond with its own Authentication message, accepting the client. A rejection can occur if load balancing is enabled, and the access point decides that it is oversubscribed, or if key state tables in the access point are full. 7. The client will send a Reassociation Request message to the access point, requesting data services. 8. The access point will send a Reassociation Response message to the access point. If the message has a status code for success, the client is now associated with and connected to this access point, and only this access point. Controller-based wireless architectures will usually ensure this by immediately destroying any connection that may have been left over if step 2 has not been performed. The access point may reject the association if it is oversubscribed, or if the additional services the client requests (mostly security or quality-of-service) in the Reassociation Request will not be supported. At this point, the client is associated and data services are available. Usually, the access point or controller behind it will send a broadcast frame, spoofed to appear as if it were sent by the client, to the connected Ethernet switch, informing it of the client’s presence on that particular link and not on any one that may have been used previously. If no security is employed, skip ahead to the admission control mechanisms, towards the endofthelist.IfPSKsecurityisemployed,skipaheadtothefour-wayhandshake. Otherwise, if 802.1X and RADIUS authentication is employed (WPA/WPA2 Enterprise), we’ll continue immediately next. For any security mechanisms, you may wish to flip to Section 5.6 for more details on the mechanisms. 9. The access point and client can only exchange EAP messages at this point. The client may solicit the EAP exchange with an optional EAP Start message. 10. The access point will request the client to log in with an EAP Request Identity message. 11. Depending on the EAP method required by the RADIUS server on the network, the clientandaccesspointwillcontinuetoexchangeanumberofdataframes,allEAPOL. Voice Mobility over Wi-Fi 251 www.newnespress.com 12. The access point relays the RADIUS server’s EAP Success or EAP Failure message. If this is a failure, the access point will also likely send a Deauthentication or Disassociation message to the client, to kick it off of the access point. Atthispoint,theclientandaccesspointhaveagreedonthepairwisemasterkey(PMK), based on the key material generated during the RADIUS exchange and sent to the access point when the authentication process concluded. But, as Section 5.6.1.2 showed, the access pointandclientstillneedtogenerateaper-connection,pairwisetransientkey(PTK),which willbeusedtodotheactualencryption.Pre-sharedkey(PSK)networksskippedthelisted EAPexchanges,andusethePSKasthemasterkey. 13. The access point send the first message in the RSN (802.11i) four-way handshake. ThisisanEAPOLKeyframe. 14. The client sends the second message in the four-way handshake. 15. The access point sends the third message in the four-way handshake. 16. The client sends the fourth message in the four-way handshake. At this point, all data services are enabled, and the client and access point can exchange data frames. However, if a call is in progress, and WMM Admission Control is enabled, the client is required to request the voice resources before it can send or receive a single voice packet with priority. Until this point, both sides may either buffer the packets or send the voice packets as best-effort. Section 6.1.1.2 has the details on WMM Admission Control. 17. The client sends the access point an ADDTS Request Action frame, with a TSPEC that specifies the over-the-air resources that both the upstream and downstream part of the voice call will occupy. 18. The access point weighs whether it has enough resources to accept or deny the request. It sends an ADDTS Response Action frame with the results. 19. If the request was successful, the client and access point will be sending voice traffic and the call successfully handed off. On the other hand, if the request fails, the client will disconnect from the access point with a Disassociation message, because, although it is allowed to remain on the access point, it can’t send or receive any voice traffic. Hopefully, everything went well and the handoff completed. On the other hand, if any of the processes failed, the connection is broken. The old connection was abandoned early on—in step 8 for sure and step 2 for more charitable clients. In order to not drop the phone call, the phone will need to restart the process from the beginning with another access point—perhaps the original access point it just left, if none is available. 252 Chapter 6 www.newnespress.com You will notice that the client has a lot of work to do to make the handoff successful, and there are many places where the procedure can go wrong. Even if every request were to be accepted, any loss of some of the messages can cause long timeouts, often up to a second, as each side waits to make sure that no messages are passing each other by. If nothing at all is done to optimize this transition, the handoff mechanics can take an additional second or two, on top of the second or so taken by the scanning process before the handoff decision was made. In the worst case, the 802.1X communication can take a number of seconds. Part of the issue is that the mechanisms are nearly the same for a handoff as they are for when the client initially connects. This lack of memory within the network within basic Wi-Fi prevents any optimizations and requires a fresh start each time. 6.2.4 Reducing Security Handoff Overhead with Opportunistic Key Caching The good news is that the 802.1X mechanisms can be taken out of the picture for handoffs, for wireless architectures with a controller (or large number of radios in one access point). This mechanism, available today for many vendors, is known as opportunistic key caching (OKC).Thenamecomesfromthemainconceptunderlyingthetechnology.Onceaclient performstheauthenticationwiththeRADIUSserver,andhasaPMK,thereisnoreasonfor ittohavetonegotiateanewonejusttohandoffandcreateanewPTKjustforthataccess point.Theterm“opportunistic”isusedbecausethemechanismwasdesignedtobeasimple extensionof802.11i,andtheclientisnotmadeawarethatOKCisenabled.Ifitworks,it works. If not, no problems arise except the increased time required for doing the handshake. ThemainprotocolforOKCisidenticaltotheordinarykeycachingmentionedinSection 5.6.2.3. The only difference is that whereas ordinary key caching requires that the client is returning to an access point where it had already performed 802.1X, opportunistic key cachingrequiresonlythatthenewaccesspointsomehowhaveaccesstothePMK,even though it was created on a different access point. Howcanthiswork?ThePMK,ifyourecall,doesnothaveanyinformationuniquetothe wireless network within it. It is a function purely of the EAP protocol in use between the wireline RADIUS server and the wireless client. There is no intrinsic reason that the same PMKcannotbeusedfordifferentaccesspoints,aslongasthefollowingtworestrictions areheldto:thePMKmustneverbetransmittedasplaintextorusingweakencryption,and thePMKmustnothaveexpired. Inpractice,opportunistickeycachingimplementationsnevermovearoundthePMK. Instead, these implementations take advantage of the architecture of the WPA2 protocol and how it interacts with 802.1X. 802.1X doesn’t know about clients and access points. Instead, it uses a different language, in which the role of the user is held by a supplicant, and the Voice Mobility over Wi-Fi 253 www.newnespress.com role of the network is held by an authenticator. These terms and roles were described in Section 5.6.2, when 802.1X was introduced. The mapping of the supplicant to real devices is clear: the supplicant is a part of the client. The authenticator, on the other hand, has flexibility built in. For standalone access point architectures, the authenticator is a part of the access point. For controller-based architectures, however, the authenticator is almost always in the controller. Nowwegetasenseforthescaleofopportunistickeycaching.ThePMKwasoriginally created in the authenticator, and most opportunistic key caching architectures leave the PMKinsidetheauthenticator,nevertocomeout.Forcontroller-basedarchitectures,the controllergeneratesthePTKwithintheauthenticator,andthendistributesittothe encryption engine, which may be located locally in the controller or in the access points. Withopportunistickeycaching,then,theonlychangeistoallowaclientwithaPMKto associatetoanewaccesspoint,andtousethePMKforthenewconnectionasifithad been negotiated on that access point. There is no addition of protocols or state changes in opportunistic key caching, which explains why it is so prevalent within network implementations. The only changes are to clients,whohavetocreateanewPMKID,basedontheoriginalPMK,whentheyassociate toanewaccesspoint,andtotheauthenticator,whichneedstolookpastthataPMKIDwas notcreatedforthePMK,createthenewone,andthencontinueasifnothingunusualhad happened. You should look for wireless clients and network infrastructure that supports opportunistic keycachingwhenrollingoutavoicemobilitynetwork.OKChasbeengenerallyembraced by the industry, though there are a few notable exceptions, and is generally used as the solution to the 802.1X overhead. 6.2.5 An Alternative Handoff Optimization: 802.11r As good as opportunistic key caching sounds, it does have its flaws. The major flaw is that the client has no way of knowing whether a new access point it is associating to has the PMKalready.Thisisnotamajoraw,inthattheopportunisticnatureofthekeycaching doesn’t require the client to make the correct guess. However, in areas where access points from multiple authenticators overlap, such as at the border area between two controllers’ domains, it is possible for the client to be unable to take advantage of the optimizations. For this reason, as well as some detailed interest in having a key caching mechanism that is specified in the 802.11 standard—opportunistic key caching is a well-known mechanism, but neither IEEE nor the Wi-Fi Alliance officially recognize it nor test for interoperability or performance of the mechanisms—the IEEE created an effort to produce a standard version. This standard version is known by the amendment 802.11r. 254 Chapter 6 www.newnespress.com 802.11r,entitled“FastBSSTransition,”isfundamentallyamoreelaborated-uponversionof opportunistic key caching. The general goal and concept is the same: eliminate the overhead of802.1XbyallowingmultipleaccesspointstousethesamePMKtohavetheirownPTKs created. The difference is that where opportunistic key caching specifies nothing about how this happens, 802.11r specifies some structure so that there can be a better sense of what is happening. However, 802.11r is more ambitious. In addition to standardizing key caching, 802.11r made two optimizations. The first optimization is to allow the original Authentication and Reassociation messages be used to piggyback the four-way handshake, eliminating the need for those extra frames. WMM Admission Control is piggybacked as well, allowing the elimination of the ADDTS protocol for handoffs. The second optimization is to allow the client to start the first part of the handoff before the handoff actually occurs, providing a semblance of make-before-break behavior into Wi-Fi. 6.2.5.1 802.11r Key Caching Let’srstlookatthekeycachingchanges.WPA2hasaverysimplekey hierarchy, or a nestingofkeys.The802.1XexchangecreatesthePMK,andthePMKisusedtocreatea uniquePTKforeachassociationofthatclient.802.11rexpandsthatkeyhierarchytoallow forintermediatestepsandprovidewaysfortheclienttoknowwhichPMKisshared between two access points. The key hierarchy for 802.11r is more complicated. There is the original master key from the RADIUS authentication, followed by a PMK-R0, a PMK-R1 ,andnallybythePTK. Let’sstartwiththePMK-R0.Thisistherstlevelofthehierarchy,andisstoredina central authenticator that is to be shared across the entire mobility domain, which is the advertisedsetofaccesspointsthatcansharekeystate.ThePMK-R0isderivedusingthe same master key that was generated with 802.1X, but also includes the SSID and the client’sEthernetaddress,aswellassomeotheridentiers.ThisPMK-R0isforeverconned within the mobility domain, and remains in the central location where the RADIUS server is accessed from. (For controller-based architectures, this is always within the controller.) This holder is named the R0 key holder (R0KH). Whenanaccesspointisintroducedintothemobilitydomain,acorrespondingPMK-R1is derivedbytheR0keyholder.ThePMK-R1addstothePMK-R0theEthernetaddressof the access point or the controller—wherever the group keys are generated from. This entity is named the R1 key holder (R1KH). WhenaclientassociateswithaspecicBSS,theR1keyholdercreatesthePTK.ThisPTK servestheidenticalfunctionasthePTKfromWPA2,and,infact,plugsdirectlyintothe WPA2encryptioninthesamewayasthePTKfromtheoriginal802.11ifour-way handshake. Voice Mobility over Wi-Fi 255 www.newnespress.com 6.2.5.2 802.11r Transitions Stepping back, we can see what this means for clients. Every access point that belongs to the same controller (R0 key holder) can belong to the same mobility domain. The mobility domain is advertised in the beacons, within the Mobility Domain IE, shown in Table 6.7. Table 6.7: Mobility domain information element Element ID Length Mobility Domain ID FT Capabilities and Policy 1 byte 1 byte 2 bytes 1 byte Table 6.8: Authentication request/response frame body Algorithm Number Authentication Sequence RSN IE Mobility Domain IE Fast BSS Transition IE 1 byte 1 byte variable variable variable The Mobility Domain ID is a two-byte field, chosen by the network administrator to uniquely identify the mobility domain, and to distinguish it from other mobility domains that may be in the area. The FT Capabilities and Policy field specifies two bits. The first bit, when set, enables over-the-DS transitions, which will be described shortly. The second bit, when set, enables the use of pre-authentication resource reservations. First, let’s look at the changes to the transition, for a completely over-the-air scenario. 802.11r eliminates the frames that carried the four-way handshake, WMM AC resource requests, and the 802.1X exchange for a handoff. The process for handoff thus changes from the steps mentioned in Section 6.2.3 to the following, starting from that section’s step 5. 1. The client will send an Authentication message to the new access point, establishing the beginnings of a relationship with this new access point, but not yet enabling data services. This Authentication message is called an Authentication Request, and has the structure shown in Table 6.8. The Algorithm Number specifies equals 2 to use 802.11r. The RSN IE contains a similar RSN IE to the Association Request for the original WPA2, except that one PMKIDwillbegiven(justaswithopportunistickeycaching)butwiththeIDforthe PMK-R0,andthekeymanagementsuitewillbegivenas00:0F:AC,3,meaningtouse 802.11r for the key derivation, rather than WPA2. The Mobility Domain IE matches the one in the beacon. The Fast BSS Transition IE contains the client’s nonce, and thus establishes a similar purpose as the first message in the 802.11i four-way handshake. 2. The access point, if it will accept the client, sends an Authentication Response message. This Authentication message has the same structure as the Authentication 256 Chapter 6 www.newnespress.com Request, except that the contents of the Fast BSS Transition IE are different. That IE now contains the authenticator’s nonce, as well as repeats the client’s nonce. This corresponds to the second message in the Four-Way handshake. At this point, the 802.11“Authentication”processisdone,but802.11risonlyhalfwaythrough. 3. The client sends the access point a Reassociation Request message. This message has all of the same fields as a normal Reassociation Request message, but also includes the fields given in Table 6.9. Table 6.9: Additional 802.11r fields for the Reassociation Request RSN IE Mobility Domain IE Fast BSS Transition IE RIC Descriptor IE TSPEC … variable variable variable variable variable Here,theRSNIE’sPMKIDhasnowchangedtothatforPMK-R1,signifyingthat this phase of the communication is now for the R1 key holder, and does not need to involve R0 at this point. Furthermore, the Fast BSS Transition IE holds a MIC, or secure hash, of the information elements added to the frame for 802.11r, thus protecting the admission control requests from being forged or modified. The RIC Descriptor IE states that one or more TSPECs are following, and that these TSPEC information elements, which would ordinarily be a part of the ADDTS Request for WMM Admission Control, are actually related to this transaction. Note that the access point will choose one and only one of the multiple possible TSPECs given, as each one is considered an alternative. In this way, the protocol of requests and responses for TSPECs have been embedded in the Reassociation Request. This message serves as message three of the four-way handshake. 4. The access point, if it accepts the client and the client has not failed the security handshake, will send a Reassociation Response. The Reassociation Response carries the usual fields, but also the same fields as in the previous Reassociation Request. The RIC Descriptor IE from the request is returned, but with the status code within properly set to inform the client of whether the request was accepted. On an accepted resource request, the TSPEC that corresponds to the accepted request is returned. On a failed request—which is still a part of a valid, successful Reassociation Request—a TSPEC that might still work can be returned by the access point, to give the client an option to submit an ADDTS with something that might succeed. At this point, the client is associated, data is flowing, and the admission control request has been either accepted or rejected. This only took four frames, and so the over-the-air overhead has been dramatically reduced. We can notice, however, that the first two frames of the exchange do not change where the client is associated or how its traffic flows. They affect only the establishment of the Voice Mobility over Wi-Fi 257 www.newnespress.com security keys. Because of this, there is one more change that can be made, and this one can ease the transition burden even more. Instead of the first two Authentication frames going over the air, on the channel of the new access point, the client may have the option of sending the contents of those frames to the current access point. This is allowed only if the current access point states that it supports this feature in the FT Capabilities field. This type of transition is called an over-the-DS transition. Over-the-DS transitions, named because of the term distribution service (DS) referring to the nebulous wireline interconnection between access points that, for standalone access point systems, is normally only a switched Ethernet network, requires that the current access point be able to forward the messages intended to the new access point. The added contents of the Authentication frames specified in the steps, starting from the RSN IE, are, instead, placed into an FT Action frame. The FT Action frame has the format given in Table 6.10. Table 6.10: FT action request/response frame body Category Action Client Address Target BSSID RSN IE Mobility Domain IE Fast BSS Transition IE 1 byte 1 byte 6 bytes 6 bytes variable variable variable The main difference between the Authentication frames and these Action frames, besides the obvious one that the Action frames go to and from the current access point, is that the Action frames contain the BSSID of the access point that the client wishes to hand off to. In a mobility domain, the current access point will invoke some sort of unspecified mechanism to get the message to the target access point, with exactly the same effects as if the message had been sent directly to the target access point over the air. The previous list of steps reads the same, if one just substitutes FT for Authentication and remembers that the frames are sent to the current access point for those FT messages. This sort of handoff is not a part of a make-before-break scheme, because there is no commitment on the part of the client to make the transition when performed over the air or the DS, and the data path is unambiguously owned by only one of the two access points. 6.2.5.3 Preauthentication Resource Allocation 802.11r allows for one more mode. Preauthentication resource allocation allows a client to request resources on the new access point before leaving the old one. These resources are requested by inserting two additional steps into the handoff, right after the Authentication/ FT Response. These two steps, known as Authentication/FT Confirm and Authentication/FT Acknowledgement, serve a somewhat similar purpose for resource reservation as the 258 Chapter 6 www.newnespress.com Reassociation steps do. Essentially, the resource reservation part of the protocol is moved forward, from the Reassociation messages to the new Confirm and Acknowledgement messages. In this manner, the resources can be requested before the client makes the transition, thus allowing the client to have more confidence that the resources will be available before the transition. An important part of the protocol is that the target access point is not required to specifically allocate the resources that were a part of the accepted resource requests, and can specifically deny the resource request when the client finishes the protocol with the Reassociation Request, by rejecting the Reassociation. This flexibility exists to allow the network to avoid certain greedy client behavior, where a client who wishes to hand off may feel compelled to allocate resources for a second and third backup, thus hogging valuable airtime without using it. The network, however, is allowed to take these essentially provisional resource allocations, known as accepted rather than active resources, into account when admitting or denying other clients. Even with this mechanism, the handoff scheme is still one of break-before-make, as the client is forbidden from using over-the-air data resources on two access points simultaneously. 6.2.5.4 802.11r in Wireless Architectures With a better understanding of the mechanisms employed in 802.11r, we can now look back and answer the question of how this fits in across the variety of different architectures. Because 802.11r has such a strong focus on a central authority, one might ask the question of whether 802.11r requires a controller or can still be used for standalone access points. Themappingtocontrollersisratherobvious.ThecontrollerneedstobetheR0KeyHolder, andcommunicatesdirectlywiththeRADIUSserver,justaswithWPA2.TheR1Key Holder doesn’t need to be located elsewhere, so it can be present on the controller as well, usuallyinthesamemodule.Thisway,thetwolevelsofPMKholderscollapse,andwork justaswiththeonePMKholderwithopportunistickeycaching.Whentheclienthandsoff toasecondaccesspoint,thataccesspointrequeststhePTKfromthecontroller,which generatesanewPMK-R1alongtheway,andstoresitinternallyifneededforlateruse. Figure 6.8(a) shows one such setup. Minor alterations can be encountered, such as having thePTKholderinthecontrollerforarchitectureswhoencrypttheirpacketscentrally. So, how can this possibly map to a standalone access point model? Figure 6.8(b) shows one method.ThemajorchangeisfortheremovalofanyonecentralizedPMKholder.Instead, access points are both R0 and R1 key holders, but with the R1 key holders being different access points from the one R0 key holder. When a client performs 802.1X for the first time, thataccesspointbecomestheR0keyholder.Alongtheway,itgeneratesaPMK-R1anda PTK.Butwhentheclienthandsoff,thenewaccesspointwillalsobecomeanR1key Voice Mobility over Wi-Fi 259 www.newnespress.com holder. The challenge in the architecture is for the system to have some sort of protocol where the new access point can find out which other access point is the R0 key holder. Oncethatisfound,thenewaccesspointrequestsaPMK-R1fromtheoldaccesspoint, generatesaPTK,andstartsworking.TheidentityoftheR0keyholderdoesnotchange, until the key expires or 802.1X is performed again. In this way, there are many R1 key holders to each R0 key holder, and every access point can be an R0 key holder. So, the good news is that standalone architectures can also participate in the 802.11r protocol. One final note about key exchanges. There is no standard in 802.11i, 802.11r, or WPA2 that speciesjusthowthesePMKsandPTKsgetmovedaround.Everyvendorisallowedtouse its own proprietary protocol, and they do. The only requirement is that whatever protocol is used to move keys around provide for privacy and integrity. Controller-based architectures already have these protocols, and so there should be no concern. For standalone access points, a protocol will have to be created. You may have heard of 802.11F, the Inter-Access Point Protocol (IAPP), in previous years. This withdrawn recommendation—it was not even a standard—had tried to describe some earlier methods for communication. But it was not adequate for more modern technologies, and the controller-based architectures had lead to its being abandoned. Therefore, whatever protocol is created will likely be proprietary or lightly used. An issue also arises about 802.11r mobility domains across vendors. Mobility domains do not extend across access points from two different vendors, even if both vendors support 802.11r. Because the key exchange protocols are vendor-specific, there is no way to connect the access points of multiple vendors together into one mobility domain. This is not likely to change, as there is quite a bit more to managing the security state of a client than swapping keys, and so there would not be a one-size-fits-all protocol. 6.2.6 Network Assistance with 802.11k In Section 6.2.1, we considered the difference between network assistance and network control. Here, we will go through the details of the technologies that allow network assistance to happen. 802.11k,labeled“RadioResourceMeasurement”(similarlynamedasradioresource management [RRM], but actually distinct), is a collection of protocols designed to improve the flow and exchange of information between the client and the access point. The basic mechanism of 802.11k is designed around the concept of reports. These reports are requested by one side of the conversation and furnished by the other. Many of the reports require time to produce, mostly because they require the reporter to engage in some sort of scanning behavior. . everything went well and the handoff completed. On the other hand, if any of the processes failed, the connection is broken. The old connection was abandoned early on—in step 8 for sure and step 2 for. same mobility domain. The mobility domain is advertised in the beacons, within the Mobility Domain IE, shown in Table 6.7. Table 6.7: Mobility domain information element Element ID Length Mobility. results. 19. If the request was successful, the client and access point will be sending voice traffic and the call successfully handed off. On the other hand, if the request fails, the client will disconnect