Scalable voip mobility intedration and deployment- P26 potx

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.. The

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

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

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

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 flaw, 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

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 first 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 finally by the PTK

Let’s start with the PMK-R0 This is the first 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 identifiers This PMK-R0 is forever confined 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 specific 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

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

Table 6.8: Authentication request/response frame body

Algorithm

Number

Authentication Sequence

Domain IE

Fast BSS Transition IE

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

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

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

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

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

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

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 specifies 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