Telecom Made Simple

Reducing Security Handoff Overhead with Opportunistic Key Caching

noreply@blogger.com (JohnJenin) — Mon, 30 Apr 2012 10:31:00 +0000

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. Hi, 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. 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. IX, 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. IX. 802. IX 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. 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.

The Wi-Fi Break-Before-Make Handoff

noreply@blogger.com (JohnJenin) — Thu, 26 Apr 2012 09:42:00 +0000

Basic Wi-Fi handoffs are always either break-before-make or just-in-time. In other words, there is no ability for a wireless phone to decide on a handoff and establish a relationship with a new access point without disconnecting from the previous one. The rules of 802.11 are rather simple here: no client is allowed to associate (send an Association message to one while maintaining data connectivity to another) to two access points at the same time. The reason for this is to remove any ambiguity as to which access point should forward wireline traffic destined to the client; otherwise, both access points would have the requirement of receiving the client's traffic, and therefore would not work in a switched wireline environment.

However, almost all of the important protocols for Wi-Fi happen only after a data connection has been established. This prevents clients from gaining much of a head start on establishing a connection when the old one is at risk.

Let's look at the contents of the Wi-Fi handoff protocol itself step by step. It will be helpful for further information.

Once a client has decided to hand off, it need not break the connection to the original access point, but it must not use it any longer.
The client has the option of sending a Disassociation message to the old access point, a good practice that lets the old access point free up network resources.
At this point, if the new access point is on a different channel, the client will change the channel of its receiver.
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.
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 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.
The client will send a Reassociation Request message to the access point, requesting data services.
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.
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.
The access point will request the client to log in with an EAP Request Identity message.
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.
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, 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.
The access point send the first message in the RSN (802. Hi) four-way handshake. This is an EAPOL Key frame.
The client sends the second message in the four-way handshake.
The access point sends the third message in the four-way handshake.
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.
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.
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.
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.

When Scanning Happens | Inter-Access Point Handoffs

noreply@blogger.com (JohnJenin) — Sun, 22 Apr 2012 13:17:00 +0000

The client's handoff is only as good as its scanning table. The more the client scans, the more accurate the information it receives, and the better decision the client can make, thus ensuring a more robust call. However, scanning can cost as much in call quality as it saves, and most certainly diminishes battery life. So how do phones determine when to scan?

The most obvious way for a client to decide to scan is for it to be forced to scan. If the phone loses connection with the access point that it is currently attached to, then it will have no choice but to reach out and look for new options. Clients mainly determine that they have lost the connection with their current access point in three different ways.

The first method is to observe the beacons for loss. As mentioned earlier, beacon frames are transmitted on specific intervals, by default every 102.4ms. Because the beacons have such a strict transmission pattern, clients—even sleeping clients—know when to wake up to catch a beacon. In fact, they need to do this regularly, as a part of the power saving mechanisms built into the standard. A client can still miss a beacon, for two reasons: either the beacon frame was collided with (and, because beacon frames are sent as broadcast, there are no retransmissions), or because the client is out of the range that the beacons' data rates allow. Therefore, clients will usually observe the beacon loss rate. If the client finds itself unable to receive enough beacons according to its internal thresholds, it can declare the access point either lost or possibly suffering from heavy congestion, and thus trigger a new scan, as well as deprioritize the access point in the scanning table. The sort of loss thresholds used in real clients often are based on a combination of two or more different types of thresholds, such as triggering a scan if a certain number of beacons are lost consecutively, as well as triggering if a certain percentage is lost over time. These thresholds are likely not to directly specifiable by the user or administrator.

The second method is to observe data transmissions for loss. This can be done for received or transmitted frames. However, it is difficult for a client to adequately or accurately determine how many receive frames have been lost, given that the only evidence of a retransmission prior to a lost frame is the setting of the Retry bit in the frame's header, something that is not even required in the newer 802.1 In radios. Therefore, clients tend to monitor transmission retries. The retry process is invoked for a frame. Retransmissions are performed for both collisions and adapting to out-of-range conditions— because the transmitter does not know which problem caused the loss, both are handled by the transmitter simultaneously reducing the transmit data rate, in hopes of extending range, and increasing backoff, in hopes of avoiding further collisions for this one frame. Should a series of frames back-to-back be retransmitted until they time out, the client may decide that the root cause is for being out of range of the access point. Again, the thresholds required are not typically visible or exposed to the user or administrator.

Voice clients tend to be more proactive in the process of scanning. The two methods just described are for when the client has strong evidence that it is departing the range of the access point. However, because the scanning process itself can take as long as it does, clients may choose to initiate the scan before the client has disconnected. (This may sound like the beginnings of a make-before-break handoff scheme, but read on to Section 6.2.3, where we see that such a scheme does not, in fact, happen.) Clients may chose to start scanning proactively when the signal strength from the access point begins to dip below a predetermined threshold (the signal strength itself is usually measured directly for the beacons). Or, they may take into account increasing—but not yet disruptive—losses for data. Or, they may add into account observed information about channel conditions, such as an increasing noise floor or the encountering of a higher density of competing clients, to trigger the scan. In any event, the client is attempting to make some sort of preprogrammed expense/reward tradeoff. This tradeoff is often related to the problems of handoff, as mentioned shortly.

Scanning may also happen in the background, for no reason at all. This is less common in voice clients, where the desire to ensure battery life acts as a deterrent, but nevertheless is employed from time to time. The main reason to do this sort of background scanning is to ensure that the client's scanning table is generally not as stale, or to serve as a failsafe in case the triggered scanning behavior does not go off as expected. One of the chief problems with determining when to scan is that the client has no way of knowing whether it is moving or how fast it may be moving. A phone held in the hands of a forklift driver can rapidly go from having been standing still for many minutes to racing by at 15 miles per hour in a warehouse. This sort of scanning, not being triggered, is the least likely to lead to a change in access point selection, but may still serve its appropriate place in a network. For data clients, as a comparison, this form of background scanning, triggered for no reason, is often driven by the operating system. Windows-based systems often scan, for example, every 65 seconds, just to ensure that the operating system has a good sense of the networks that are available, in case the user should want to hop from one network to another. This sort of scanning causes a noticeable hit in performance for a short period of time on a periodic basis.

The Scanning Process | Inter-Access Point Handoffs

noreply@blogger.com (JohnJenin) — Thu, 19 Apr 2012 08:30:00 +0000

The scanning table's contents come from beacons and probe requests. Scanning is a process that can be requested explicitly the user—often by performing an operation that is labeled "Reconnect." "Update," or "Scan." But far more often, scanning is a process that happens in the background or when the client decides that it is needed. To understand why the client makes those choices, we will need to look at the mechanisms of scanning itself.

There are two ways that the scanning table can be updated. When a client is associated to an access point, it has the ability to gather information about other access points on that channel. Especially when the client is not in power save mode, the client will usually ask its hardware to let it receive all beacon frames from any access point. Each beacon frame is then used to update the scanning table entry for that access point.

On the other hand, the client may want to survey other channels to find out what other access point options are out there. To do this, the client clearly needs to leave the channel of its access point for at least a small amount of time. Therefore, before engaging in this process, the client will usually tell the access point that it is going into power save mode, even though it is doing no such thing. That way, the access point will buffer traffic for the client, who can then look around the network with impunity.

When the client changes channels, it has two methods it can use to find out about the access points. The quickest method is to send out the probe request mentioned earlier. This probe request contains the SSID the client desires (with the option of a null SSID, an empty string, if the client wants to learn about all SSIDs), and is picked up by all access points in range that support the SSID and wish to make themselves known to the client. Each access point that wishes to answer and that supports the SSID in question will respond with the probe response, a frame that is nearly identical to a beacon but is sent, unicast, directly to the client who asked for it. This procedure is called active scanning, though it can also be called probing, given the name of the frames that carry out the procedure. The other option is called passive scanning, and, as the name suggests, involves sending no frames out by the client. Instead, the client waits around for a beacon. Keep in mind that passive scanning clients do not know, ahead of time, how many access points are on a channel or when these access points may transmit the beacons. Therefore, a client may need to wait for at least one beacon period to maximize its chances of seeing beacons from every access point of possible interest.

In these two ways, the client goes from channel to channel, collecting as much information as possible about the available networks.

Clients may choose between active or passive scanning for a number of reasons. The advantage of active scanning is that the client will get definitive answers about the access points that are on that channel and in range in short order. Sometimes the client needs to send more than one probe request, just to make sure that none of those broadcast frames were lost because of transient RF effects or collisions. But the process itself concludes rather quickly. Furthermore, active scanning with probe requests is the only way to learn about which access points serve SSIDs that are hidden, where hidden SSIDs are not put in beacons and require the user to enter the SSID by hand. On the other hand, active scanning comes with two major penalties. The first one is for sheer network overhead. A probe request can trigger a storm of probe responses to the client, all of which take up valuable airtime. Especially when there is a network fluctuation (access point reboots, power outages, or RF interference), all of the probes pile onto an already fragile network, making traffic significantly worse. The second penalty is that active scanning is simply not allowed on the majority of the 5GHz channels. Any channel that is in a DFS band cannot be used with active scanning. Instead, the client is always required to wait for a beacon (an enabling signal), to know that the channel is allowed for operation, does not have a radar, and thus can be used. (Note that, once a client has an enabling signal, it is allowed to proceed with a probe request to discover hidden SSIDs. However, the time hit has been taken, and the process is no faster than a normal passive scan.)

Therefore, to better understand scanning, we need to look at the timing of scanning. Active scanning, of course, is the quicker process, but it too has a delay. Active scanning is limited by a probe delay, required by the standard to prevent clients from tuning into a channel in the middle of an existing transmission. The potential problem is that a client abruptly tuning into a channel might not be able to detect that a transmission is under way—carrier sense mechanisms that are based on detecting the preamble will miss out, and thus produce a false reading of a clear channel. Thus, if the client were then to send a probe request, the client could very well destroy the ongoing transmission and lose out on the access points' seeing the probe request, because of a collision. As it turns out, many voice clients set that probe delay to a trivial value, in order to not have to wait. But the common value for that delay is 12ms, which is a long time in the world of voice. Passive scanning is worse. Most access points send their beacons every 102.4ms, or as close as they can get. This means that a client who tunes to a channel has a good chance of having to wait 50ms just to get a beacon, and may have to wait the entire 100ms in the worst case, for just that one access point.

The timescale that dominates, for voice mobility, is the voice packet arrival interval. Normally, that value is 20ms (though it can be 30ms in some cases). A client will usually want to get all of the scanning it can get done in those 20ms, so that it can return to its original channel and not miss the next voice packet. Certainly, the client will not want to take 100ms unless it has to, because 100ms is a long enough jitter that it can be quite noticeable. Again, this tends to make active scanning the choice for voice clients, who are always in a hurry to learn about new access points.

If the client is going to scan between the voice packets, then the client's ability to scan will probably be limited to one channel at a time. When limited this way, the client may take up to a second, easily, to scan every possible channel. There are 11 channels in 2.4GHz, 9 non-DFS channels in 5GHz, and 11 more in the DFS bands, for a total of 31 channels to scan (or 23 channels if clients make the assumption that service is provided only on channels 1, 6, and 11 in the 2.4GHz band). Of course, scanning is also a battery-intensive process, and so a client may choose to spread out the scanning activity over time.

Furthermore, the process of changing channels is not always instantaneous. Depending on the radio chip vendor, some clients will have to wait through a multimillisecond radio settling and configuration time, reprogramming the various aspects of the radio in order to ensure proper transmission on the new channel. This adds additional padding time to the individual scanning channel transitions.

Overall, this scanning delay is a major source of handoff delays, and some methods for reducing the scanning time have been created, which we will examine shortly.

The Scanning Table

noreply@blogger.com (JohnJenin) — Sun, 15 Apr 2012 17:34:00 +0000

Let's look at the scanning table in a bit more detail. This table is primarily a list of access point addresses (BSSIDs), and the parameters that the access point advertises. The 802.11 standard lists at least some parameters that may be useful to hold in the client's scanning table, as in Table 1.

Table 1: Scanning table contents from 802.11
Field	Meaning
BSSID	The Ethernet address of the access point's service for this SSID
SSID	The SSID text string
BSS Type	Whether the access point is a real access point, or an ad hoc device
Beacon Period	Number of microseconds between beacons
DTIM Period	How many beacons must go by before broadcast/multicast frames are sent
Timestamp	The time the last beacon or probe response was scanned for this client
Local Time	The value of the access point's time counter
Physical Parameters	What type of radio the access point is using, and how it is configured
Channel	The channel of the access point
Capabilities	The capabilities the access point advertises in the Capabilities field
Basic Rate/MCS Set	The minimum rates (and MCS for 802.11 n) that this client must support to gain entry
Operational Rate/MCS Set	The allowed rates (and MCS for 802.11n) that this client can use once it associates
Country	The country and regional information for the radio
Security Information	The required security algorithms
Load	How loaded the access point reports itself to be
WMM Parameters	The WMM parameters that the client must use once it associates
Other Information	Depends on the standards that the client and access point supports

This table contains the fields taken from the access point's beacons and probe responses. Most of the information is necessary for the client to possess before it can associate, because this information contains parameters that the client needs to adopt upon association. By looking at this table, clients can easily see which access points have the right SSID, but will not allow the client to associate. Examples are for access points that require a higher grade of security than the client is configured for, or require a more advanced radio (such as 802.1 In) than the client supports. Most of the time, however, a properly configured network will not advertise anything that would prevent a properly configured client from entering.

In addition to all of this mostly static, configuration information that the access point reports, clients may collect other information that they may themselves find useful when deciding to which access point they should associate. This information is unique to the client, based on environmental factors. Generally, this information (not that in Table 1) is far more important in determining how a client chooses where to hand off or associate to. Table 2 contains some more frequent examples of information that different clients may choose to collect. Again, there is no standard here; clients may collect whatever information they want. Roughly, the information they collect is divided into two types: information observed about the access point, and information observed about the channel the access point is on. This split is necessary, because clients have to choose which channel to use as a part of choosing which access point to associate to. Properties like noise floor or observed over-the-air activity belong to the channel at the point in place and time that the client is in. On the other hand, some properties belong directly to the access point without regard to channel, such as the power level at which the client sees the access point's beacon frames. Furthermore, some of the per-access-point information may have been collected from previous periods when the client had been associated to that access point, and measured the quality of the connection.

Table 2: Other possible scanning table contents
Field	Meaning
Signal Strength	The power level of the beacon or probe response from the access point
Channel Noise	The measured noise floor value on the channel the access point is on
Channel Activity	How often the channel the access point is on is busy
Number of Observed Clients	How many clients are on the channel the access point is on
Beacon Loss Rate	How often beacons are missed on that channel, even though they are expected
Probe Request Loss Rate	How many times probe requests had to be sent to get a probe response
Previous Data Loss Rate	If associated earlier, how much loss was present between the access point and client
Probe Request Needed	Whether the client needed to send a probe request

The scanning table is something that the client maintains over time, as a fluid, "living" menu of options. One of the challenges the client has is in determining how old, or stale, the information may be—especially the performance information—and whether it has observed that channel or access point long enough to have some confidence in what it has seen. This is a constant struggle, and different clients (even different software versions from the same client vendor) can have widely different ways of judging how much of the table to trust and whether it needs to get new information. This is one of the sources of the variability present in Wi-Fi.

The Difference between Network Assistance and Network Control

noreply@blogger.com (JohnJenin) — Wed, 07 Mar 2012 05:34:00 +0000

If you have read the sections on cellular handoff, you'll know that there are broadly two different methods for phone handoffs to occur. The first method, network control, is how the network determines when the phone is to hand off and to which base station the phone is to connect. In this method, the mobile phone may participate by assisting in the handoff process, usually by providing information about the radio environment. The second method, network assistance, is where the network has the ability to provide that assistance, but the mobile phone is fundamentally the device that decides.

For transitions across basic service sets (BSSs) in Wi-Fi, the client is in control, and the network can only assist. Why is this? An early design decision in Wi-Fi was made, and the organization broke away from the comparatively long history of cellular networking. In the early days of Wi-Fi, each cell was unmanaged. An access point, compared to a client, was thought of as the dumber of the two devices. Although the access point was charged with operating the power saving features (because it is always plugged in), the client was charged with making sure the connection to the network stayed up. If anything goes wrong and a connection drops, the client is responsible for searching out for one of any number of networks the client might be configured to connect to, and the network needed to learn only about the client at that point. It makes a fair amount of sense. Cellular networks are managed by service providers, and the force of law prevents people from introducing phones or other devices that are not sanctioned and already known about by the service provider. Therefore, a cell phone could be the slave in the master/slave relationship. On the other hand, with Wi-Fi putting the power of the connection directly into the hands of the client, the network never needs to have the client be provisioned beforehand, and any device can connect. In many ways, this fact alone is why Wi-Fi holds its appeal as a networking technology: just connect and go, for guest, employee, or owner.

This initial appeal, and tremendous simplicity which comes with it, has its downsides, and quickly is meeting its limitations. Cellular phones, being managed entities, never require the user to understand the nature of the network. There are no SSIDs, no passphrases to enter. The phone knows what it is doing, because it was built and provisioned by the service provider to do only that. It simply connects, and when it doesn't, the screen shows it and users know to drive around until they find more bars. But in Wi-Fi, as long as the handset owns the process of connecting, these other complexities will always exist.

Now, you might have noticed that SSIDs and passwords have to do only with selecting the "service provider" for Wi-Fi, and once the user has that down (which is hopefully only once, so long as the user is not moving into hotspots or other networks), the real problem is with the BSSID, or the actual, distinct identities of each cell. That way of thinking has a lot to it, but misses the one point. The Wi-Fi client has no way of knowing that two access points—even with the same SSID—belongs to the same "network." In the original Wi-Fi, there is not even a concept of a "network," as the term is never used. Access points exist, and each one is absolutely independent. No two need to know about each other. As long as some Ethernet bridge or switch sits behind a group of them, clients can simply pass from one to the other, with no network coordination. This is what I mean, then, by client control. In this view of the world, there really is no such thing as a handoff. Instead, there is just a disconnection. Perhaps, maybe, the client will decide to reconnect with some access point after it disconnects from the first. Perhaps this connection will even be quick. Or perhaps it will require the user to do something to the phone first. The original standards remain silent—as would have phones, had the process not been improved a bit.

Network assistance can be added into this wild-west mixture, however. This slight shift in paradigm by the creators of the Wi-Fi and IEEE standards is to give the client more information, providing it with ways of knowing that two access points might belong to the same network, share the same backend resources, and even be able to perform some optimizations to reduce the connection overhead. This shift doesn't fundamentally change the nature of the client owning the connection, however. Instead, the client is empowered with increasingly detailed information. Each client, then, is still left to itself to determine what to do and when to do it. It is an article of faith, if you will, that how the client determines what to do is "beyond the scope of the standard," a phrase in the art meaning that client vendors want to do things their own way. The network is just a vessel—a pipe for packets.

You'll find, as you explore voice mobility deployments with Wi-Fi as a leg, that this way of thinking is as much the problem as it is a way to make things simple. Allowing the client to make the choice is putting the steering wheel of the network—or at least, a large portion of the driving task—in the hands of hundreds of different devices, each made by its own manufacturer in its own year, with its own software, and its own applications. The complexity can become overwhelming, and the more successful voice mobility networks find the right combinations of technologies to make that complexity manageable, or perhaps to make it go away entirely.

Inter-Access Point Handoffs

noreply@blogger.com (JohnJenin) — Sat, 03 Mar 2012 23:33:00 +0000

In a voice mobility network with Wi-Fi as a major component, we have to look at more than just the voice quality on a particular access point. The end-user of the network, the person with a phone in hand, has no idea where the access points are. He or she just walks around the building, going in and out of range of various access points in turn, oblivious to the state of the underlying wireless network. All the while, the user demands the same high degree of voice quality as if he or she had never started moving.

So now, we have to turn our focus towards the handoff aspect of Wi-Fi voice networks. Looking back on how Wi-Fi networks are made of multiple cells of overlapping coverage, we can see that the major sources for problems with voice are going to come from four sources:

How well the coverage extends through the building
How well the phone can detect when it is exiting the coverage of one access point
How well the phone can detect what other options (access points) it has available
How quickly the phone can make the transition from the old access point to the new one

Let's try to gain some more appreciation of this problem. Figure 1 shows the wireless environment that a mobile phone is likely to be dwelling within.

Figure 1: The Handoff Environment

As the caller and the mobile phone move around the environment, the phone goes into range and out of range of different access points. At any given time, the number of access points that a client can see, and potentially connect to, can be on the order of a dozen or more in environments with substantial Wi-Fi coverage. The client's task: determine whether it is far enough out of range of one access point that it should start the potentially disruptive process of looking for another access point, and then make the transition to a new access point as quickly as possible. The top part of Figure 1 shows the phone zigzagging its way through a series of cells, each one from an access point on a different channel. Looking at the same process from the point of view of the client (who knows only time), you can see how the client sees the ever-varying hills and valleys of the differing access points' coverage areas. Many are always in range; hopefully, only one is strong at a time.

The phone is a multitasker. It must juggle the processes of searching for new access points and handing off while maintaining a good voice connection. In this section, we'll go into details on the particular processes the phone must go through, and what technologies exist to make the process simpler in the face of Wi-Fi. But first, we will need to get into some general philosophy.

Active Voice Quality Monitoring

noreply@blogger.com (JohnJenin) — Thu, 01 Mar 2012 05:29:00 +0000

A large part of determining whether a voice mobility network is successful is in monitoring the voice quality for devices on the network. When the network has the capability to measure this for the administrator on an ongoing basis, the administrator is able to devote attention to other, more pressing matters.

Active voice quality monitoring comes in a few flavors. SIP-based schemes are capable of determining when there is a voice call. This is often used in conjunction with SIP-based admission control. With SIP calls, RTP is generally used as the bearer protocol to carry the actual voice, SIP-based call monitoring schemes can measure the loss and delay rates for the RTP traffic that makes up the call, and report back on whether there are phones with suffering quality. In these monitoring tools, call quality is measured using the standard MOS or R-value metrics.

SIP-based schemes can be found in a number of different manifestations. Wireline protocol analyzers are capable of listening in on a mirror port, entirely independent of the wireless network, and can report on upstream loss. Downstream loss, however, cannot be detected by these wireline mechanisms. Wireless networks themselves may offer built-in voice monitoring tools. These leverage the SIP-tracking functions already used for firewalling and admission control, and report on the quality both measured by uplink and downlink loss. Purely wireless monitoring tools that monitor voice quality can also be employed. Either located as software on a laptop, or integrated into overlay wireless monitoring systems, these detect the voice quality using over-the-air packet analysis. They infer the uplink and downlink loss rates of the clients, and use this to build out the expected voice quality. Depending on the particular vendor, these tools can be thrown off when presented with WPA- and WPA2-encrypted voice traffic, although that can sometimes be worked around.

Voice call quality may also be monitored by measurements reported by the client or other endpoint. RTCP, the RTP Control Protocol, may be transmitted by the endpoints. RTCP is able to encode statistics about the receiver, and these statistics can be used to infer the expected quality of the call. RTCP may or may not be available in a network, based on the SIP implementation used at the endpoints. Where available, RTCP encodes the percentage of packets lost, the cumulative number of packets lost, and interarrivai packet jitter, all of which are useful for inferring call quality. At a lower layer, 802.11k, where it is supported, provides for the notion of traffic stream metrics. These metrics also provide for loss and delay, and may also be used to determine call quality. However, 802.11k requires upgrades to the client and access point firmware, and so is not as prevalent as RTCP, and nowhere near as simple to set up as overlay or traffic-based quality measurements.

^[*]Of course, there had to be a catch. Some devices can carry two calls simultaneously, if they renegotiate their one admitted traffic stream to take the capacity of both. Because WMM Admission Control views flows as being only between clients and access points, the ultimate other endpoint of the call does not matter. However, this is not something you would expect to see in practice.

Spectrum Management | Voice Mobility with Wi-Fi

noreply@blogger.com (JohnJenin) — Sun, 26 Feb 2012 16:28:00 +0000

Spectrum management is the technology used by virtualization architectures to manage the available wireless resources. Unlike radio resource management, which is focused on adjusting the available wireless resources on a per-access-point basis, to ensure that the clients of that access point receive reasonable service without regard to the neighbors, spectrum management takes a view of the entire unlicensed Wi-Fi spectrum within the network, and applies principles of capacity management to the network to organize and optimize the layout of channel layers. In many ways, spectrum management is radio resource management, applied to the virtualized spectrum, rather than individual radios.

Spectrum management focuses on determining which broad swaths of unlicensed spectrum are adequate for the network or for given applications within the network. One advantage of channel layering is that channels are freed from being used to avoid interference, and thus can be used to divide the spectrum up by purposes. Much as regulatory bodies, such as the FCC, divide up the entire radio spectrum by applications, setting aside one band for radio, another for television, some for wireless communications, and so on, administrators of virtualization architectures can use spectrum management to divide up the available channels into bands that maximize the mutual capacity between applications by separating out applications with the highest likely bandwidth needs onto separate channel layers.

The constraints of spectrum management are fairly simple. A deployment has only a given number of access points. The number and position of the access points limits the number of independent channel layers that can be provided over given areas of the wireless deployment area. It is not necessary for every channel layer to extend across the entire network—in fact, channel layers are often created more in places with higher traffic density, such as libraries or conference centers. The number of channel layers in a given area is called the network thickness. Spectrum management can detect the maximum number of channel layers that can be created given the current deployment of access points, and is then able to determine when to create multiple layers by spreading channel assignments of close access points, or when to maximize signal strength and SNR by setting close access points to the same channel. Thus, spectrum management can determine the appropriate thickness for each given square foot. For 802.1 In networks, spectrum management is able to work with channel widths, as well as band and channel allocations, and is thus able to make very clear decisions about doubling capacity by arranging channels as needed.

Spectrum management also applies the neighboring-interference-avoidance aspects that RRM uses to prevent adjacent networks from being deployed in the same spectrum, if it can at all be avoided. Because there is no per-channel performance compromise in compressing the thickness of the network, spectrum management can avoid some of the troublesome aspects of radio resource management when dealing with edge effects from multiple, independent networks. Furthermore, spectrum management is not required to react to transient interference, as the channel layering mechanism is already better suited to handle transient changes through RF redundancy. This allows spectrum management to reserve network reconfigurations for periods of less network usage and potential disruption (such as night), or to make changes at a deliberate pace that ensures network convergence throughout the process.

Voice-Aware Radio Resource Management

noreply@blogger.com (JohnJenin) — Thu, 23 Feb 2012 14:06:00 +0000

The concept of voice-aware radio resource management is to build upon the measurements used for determining network capacity and topology, and integrate them into the decision-making process for dynamic microcell architectures.

Basic radio resource management is more concerned with establishing minimum levels of coverage while avoiding interference from neighboring access points and surrounding devices. This is more suitable for data networks. Voice-aware RRM shifts the focus towards providing a more consistent coverage that voice needs, often adjusting the nature of the RRM process to avoid destroying active voice calls. Voice-aware RRM is a crucial leg of voice mobility deployments based on microcell technology. (Layered or virtualized deployments do not use the same type of voice-aware RRM, as they have different means of ensuring high voice quality and available resources.)

The first aspect of voice-aware radio resource management is ironically to disable radio resource management. Radio resource management systems work by the access points performing scanning functions, rather similar to those performed by clients when trying to hand off. The access point halts service on a channel, and then exits the channel for a short amount of time to scan the other channels to determine the power levels, identities, and capacities of neighboring access points. These neighboring access points may be part of the same network, or may belong to other interests and other networks. Unlike with client scanning, in which the client can go into power save to inform the access point to buffer frames, however, access point scanning has no good way for clients to be told to buffer frames. Moreover, whereas client scanning can go off channel between the packets of the voice call, only to return when the next packet is ready, an access point with multiple voice calls will likely not have any available time to scan in a meaningful way. In these cases, scanning needs to be disabled. In RRM schemes without voice-aware services, administrators often have to disable RRM by hand, thus nullifying the RRM benefits for the entire network. Voice-aware RRM, however, has the capability to turn off scanning on a temporary basis for each access point, when the access point is carrying voice traffic. There are unfortunately two downsides to this. The first is that RRM is necessary for voice networks to ensure that coverage holes are filled and that the network adapts to varying density. Disabling the scanning portion of RRM disables RRM, effectively, and so voice-aware RRM scanning works best when each given access point does not carry voice traffic for uninterrupted periods of time. Second, RRM scanning is usually the same process by which the access points scan for wireless security problems, such as rogue access points and various i ntrusions. Disabling scanning in the presence of voice leaves access points with voice more vulnerable, which is unacceptable for voice mobility deployments. Here, the solution is to deploy dedicated air monitors, either as additional access points from the same network vendor, but set to monitor rather than serve, or from a dedicated WLAN security monitoring vendor, as an independent overlay solution.

The second aspect of voice-aware radio resource management is in using coverage hole detection and repair parameters that are more conservative. Although doing so increases the likelihood of co-channel interference, which can have a strong downside to voice mobility networks as the network scale and density grows, it is necessary to ensure that the radio resource management algorithms for microcells do not leave coverage holes stand by idle. Coverage holes disproportionately affect the quality of voice traffic over data traffic. Increasing the coverage hole parameters ensures that these coverage holes are reduced. Radio resource management techniques often detect the presence of a coverage hole by inferring them from the behavior of a client. RRM assumes that the client is choosing to hand off from an access point when the loss becomes too high. When this assumption is correct, the access point will infer the presence of a coverage hole by noticing when the loss rate for a client increases greatly for extended periods of time. This is used as a trigger that the client must be out of range, and informs the access point to increase its power levels. It is better for voice mobility networks for the coverage levels to be increased prior to the voice mobility deployment, and then for the coverage hole detection algorithm to be made less willing to reduce coverage levels. Unfortunately, the coverage hole detection algorithms in RRM schemes are proprietary, and there are no settings that are consistent from vendor to vendor. Consult your microcell wireless network manufacturer for details on how to make the coverage hole detection algorithm be more conservative.

The final aspect of voice-aware RRM is for when proprietary extensions are used by the voice client and are supported by the network. These extensions can provide some benefit to microcell deployments, as they allow the network to alter some of the tuning parameters that clients use to hand off. Unfortunately, the aspects of voice-aware radio resource management trade off between coverage and quality of service, and so operating these networks can become a challenge, especially as the density or proportion of network use of voice increases. Monitoring tools for voice quality are especially important in these networks

Power Control | Voice Mobility with Wi-Fi

noreply@blogger.com (JohnJenin) — Mon, 20 Feb 2012 15:10:00 +0000

Power control, also known as transmit power control (TPC), is the ability of the client or the access point to adjust its transmit power levels for the conditions. Power control comes in two flavors with two different purposes, both of which can help and hurt a voice mobility network. The first, most common flavor of power control is vested in the client. This TPC exists to allow the client to increase its battery life. When the client is within close range to the access point, transmitting at the highest power level and data rate may not be necessary to achieve a similar level of voice performance. Especially as the data rates approach 54Mbps for 802.11a and 802.11g, or higher for 802.1 In, the preamble and per-packet backoff overhead becomes in line with the over-the-air resource usage of the voice data payload itself. For example, the payload of a voice packet at the higher data rates reduces to around 20 microseconds, on par with the preamble length for those data rates. In these scenarios, it makes sense for the client to back off on its power levels and turn off portions of the radio concerned with the more processing-intensive data rates, to extend battery life while in a call. To do this, the client will just directly reduce its transmit power levels, as a part of its power saving strategy. This mechanism can be used for good effect within the network, as long as the client is able to react to an increase in upstream data loss rates quickly enough to restore power levels should the client have turned power levels down too low for the range, or if increasing noise begins to permeate the channel.

The other TPC is vested within the network. Microcell networks, specifically, use access point TPC to reduce the amount of co-channel interference without having to relocate or disable access points. By reducing power levels, cell sizes in every direction are reduced, keeping in line with the goals of microcell. Reducing co-channel interference is necessary within microcell networks, to allow a better isolation of cells from fluctuations in their neighboring cells, especially those related to the density of mobile clients.

Network TPC has some side effects, however, that must be taken into account for voice mobility deployments. The greatest side effect is the lack of predictability of coverage patterns for the access points. This can have a strong effect on the quality of voice, because voice is more sensitive than data to weak coverage, and areas where voice performs poorly can come and go with the changing power levels, of both the access point the client is associated to and of the neighbors. Unfortunately, power levels in microcell networks usually fluctuate on the order of a few seconds or a few minutes, especially when clients are associated, as the network tries to adapt its coverage area to avoid causing the increase in packet rate and traffic caused by the clients from affecting neighboring cells. Site surveys, which are performed to determine the coverage levels of the network, are always snapshots in time and cannot take TPC into account. However, the TPC variation is necessary for proper microcell operation, and unfortunately needs to happen when phones are associated and in calls. Therefore, it can cause a strong network-induced variation in call quality. It is imperative, in microcell deployments, for the coverage and call quality to be continuously monitored, to ensure that the TPC algorithms are behaving properly. Follow the manufacturer's recommendations, as you may find in Voice over WLAN design guides, to ensure that problems can be detected and handled accordingly.

Understanding the Balance | Load Balancing

noreply@blogger.com (JohnJenin) — Thu, 16 Feb 2012 10:00:00 +0000

Explicit in the concept of load balancing is that it is actually possible to balance load—that is, to transfer load from one access point to another in a predictable, meaningful fashion. To understand this, we need to look at how the load of a call behaves from one access point to another, assuming that neither the phone nor the access points have moved.

Picture the environment in Figure 1. There are two access points, the first one on channel 1 and the second on channel 11. A mobile phone is between the two access points, but physically closer to access point 1. The network has two choices to distribute, or balance, the load. The network can try to guide the phone into access point 1, as shown in the top of the figure, or it can try to guide the phone into access point 2, as shown in the bottom of the figure.

Figure 1: Load Balancing across Distances

This is the heart of load balancing. The network might choose to have the phone associate to access point 2. We can imagine that access point 1 is more congested—that is, it has more phone calls currently on it. In the extreme case, access point 1 can be completely full, and might be unable to accept new calls. The advantage of load balancing is that the network can use whatever information it sees fit—usually, loads—to guide clients to the right access points.

There are a few wrinkles, however. It is extremely unlikely that, in a non-channel-layered environment, the phone is at the same distance from each of the two access points. It is more likely that the phone is closer to one access point than another. The consequence of the phone being closer to an access point is that it can get higher data rates and SNR, which then allows it to take less airtime and less resources. It may turn out that, if the network chooses to move the phone from access point 2 to access point 1, that the increase in data rate because the phone is closer to access point 1 allows possibly two calls in for access point 2. In this case, the same call produces unequal load when it is applied to different access points, all else being equal.

For this reason, within-band load balancing has serious drawbacks for networks that do not use channel layering. Load balancing should be thought of as a way to distribute load across equal resources, but within-band load balancing tends to work rather differently and can lead to performance problems. If the voice side of the network is lightly used—such as having a small CAC limit—and if the impact of voice on data is not terribly important, then this sort of load balancing can work to ease the rough edges on networks that were not provisioned properly. However, for more dense voice mobility networks, we need to look further. The concept of load balancing among near equals does exist, however, with band load balancing. Band load balancing can be done when the phones support both the 2.4 GHz and 5 GHz bands (some newer ones do) and the access points are dual-radio, having one 2.4 GHz radio and another 5 GHz radio in the same access point. In this case, the two choices are collocated: the client can get similar SNR and data rates from either radio, and the choice is much closer to one-to-one. Figure 2 illustrates the point.

Figure 2: Load Balancing across Bands

A variant of band load balancing is band steering. With band steering, the access point is not trying to achieve load balancing across the two bands, but rather is prioritizing access to one band over the other—usually prioritizing access to the 5GHz band for some devices. The notion is to help clear out traffic from certain devices, such as trying to dedicate one band for voice and another for data. Using differing SSIDs to accomplish the same task is also possible, and works across a broader range of infrastructures.

There are differences between the two bands, of course, most notably that the 5 GHz band does not propagate quite as far as the 2.4GHz band. The 5GHz band also tends to be unevenly accessed by multiband phones: sometimes, the phones will avoid the 5GHz band unless absolutely forced to go there, leading to longer connection times. On the other hand, the 2.4GHz band is subject to more microwave interference. And, finally, this mechanism will not work for single-band phones. (The merits of each band for voice mobility are summarized later in this chapter.) Nevertheless, band load balancing is an option for providing a more even, one-to-one balance.

For environments with even higher densities, where two channels per square foot are not enough, or where the phones support only one band or where environmental factors (such as heavy microwave use) preclude using other bands, channel layering can be employed to provide three, four, or many more choices per square foot. Channel layering exists as a benefit of the channel layering wireless architecture, for obvious reasons, and builds upon the concept of band load balancing to createcollocated channel load balancing. The key to collocated channel load balancing is that the access points that are on different channels are placed in roughly the same areas, so that they provide similar coverage patterns. Because channels are being taken from use as preventatives for co-channel interference and are instead being deployed for coverage, channel layering architectures are best suited for this. In this case, the phone now has a choice of multiple channels per square foot, of roughly similar, one-to-one coverage. Figure 3 illustrates this.

Figure 3: Collocated Channel Load Balancing with Channel Layering

Bear in mind that the load balancing mechanisms are in general conflict with the client's inherent desire to gain access to whatever access point it chooses and to do so as quickly as possible (see Section 6.2.2). The network is required to choose an access point and then must ignore the client, if it should come in and attempt to learn about the nonchosen access points. This works reasonably well when the client is first powered up, as the scanning table may be empty and the client will blindly obey the hiding of access points as a part of steering the load. On the other hand, should the client already have a well-populated scanning table—as voice clients are far more likely to do—load balancing can become a time-consuming proposition, causing handoff delays and possible call loss. Specifically, what can happen is that the client determines to initiate a handoff and consults the information in its scanning table, gathered from a time when all of its entries were options, based on load. The client can then directly attempt to initiate a connection with an access point, sending an Authentication or Reassociation frame (depending on whether the client has visited the access point before) to an access point that may no longer wish to serve the client. The access point can ignore or reject the client at that point, but usually clients are far less likely to abandon an access point once they choose to associate than when they are scanning. Thus, the client can remain outside the access point, persistently knocking on the door, if you will, unwilling to take the rejection or the ignoring as an answer for possibly long periods of time. This provides an additional reason why load balancing in an environment where multiple handoffs are likely can have consequences for the quality of voice calls.

Load Balancing | Voice Mobility with Wi-Fi

noreply@blogger.com (JohnJenin) — Mon, 13 Feb 2012 05:19:00 +0000

Load balancing is the ability for the network to steer or direct clients towards more lightly loaded access points and away from more heavily loaded ones. Client decides to which access point the client will connect. However, the network has the ability to gently influence or guide the client's decision.

First, let's recap what is meant by wireless load. The previous discussion on admission control first introduced the concept of counting airtime or calls. This is one measure of load—a real-time one. However, this counts only phones in active calls. There is likely to be far more phones not in active calls, and these should be balanced as well. The main reason for balancing inactive phones is that the network has little ability, once the phone starts a call, to transfer the phone to another access point without causing the call to fail going through. To avoid that, load balancing techniques attempt to establish a more even balance up front. The thinking goes that if you can get the phones evenly distributed when the connect to the network, then you have a better shot at having the calls they place equally distributed as well.

Mechanics of Load Balancing

Let's start with the basic mechanics of load balancing. Because the client chooses which access point to associate to, based on scanning operations, the only assured way to prevent a client from associating to an overloaded access point is for that overloaded access point to ignore the client. The access point can do this in a few ways. When the client sends probe requests, trying to discover whether the SSID it wants is still available on the access point, the access point can ignore the request, not sending out a probe response. Hopefully, the client will not enter on the basis of that alone. However, the client may have scanned before, when it could have (but chose not to) enter the access point, and may remember a prior probe response. Or, it can see the beacon, and so it knows that the access point is, in fact, providing the service in any event.

To prevent the client from associating, then, the access point has no choice but to ignore or reject Authentication and Association Request messages from the client. This will have the desired effect of preventing a burdensome load from ending up on the access point, but may not cause the client to choose the correct access point quickly.

Assuming, for the moment, that load balancing is effective in causing clients to distribute their load evenly, we need to look at what the consequences of balancing load are.

Voice Mobility with Wi-Fi Capacity

noreply@blogger.com (JohnJenin) — Tue, 31 Jan 2012 16:06:00 +0000

How the Capacity is Determined

Through either admission control scheme, the network needs to keep track of how much capacity is available. From the previous discussions on the effects of RF variability and cellular overlap, you can appreciate that this is a difficult problem to completely solve. As devices get further away from the access points, data rates drop. Changing levels of interference, from within the network or without, can cause increasing retransmissions and easily overrun surplus bandwidth allowances.

In the end, networks today adopt one of two stands, and may even show both to the user. The more complicated stand for the network—but simpler for the user—is for the network to automatically take the variability of RF into account, and to determine its own capacities. In systems that do this, there is no notion of a static maximum number of calls. Instead, the system accepts however many calls as it can handle. If conditions change, and fewer calls can be handled in the system, the network reserves the right to proactively end a client's reservation, often in concert with load balancing.

The other stand, simpler for the network but far more complicated for the user, is for the administrator to be required to enter the maximum number of calls per access point (or some other static metric). The idea here is that the administrator or installer is assumed to have gone through a planning process to determine how many calls can besafely allowed per access point, while still leaving room for best effort data. That number is usually far lower than the best-case maximum capacity, and is designed to be a low water mark: barring external changes, the network will be able to achieve that many calls most of the time. This number is then manually input into the wireless network, which then counts the number of calls. If the maximum number of calls is reached on that access point, the system will not let any more in. These static metrics may be entered either as the number of calls, or a percentage of airtime. Systems that work as a percentage of airtime can sometimes take in a padding factor to allow for calls that are roaming into the network.

Setting these values can be fraught with difficulty. Pick a number that's too low, and airtime is being wasted. Pick a number that's too high, however, and sometimes call quality will suffer. Even percentage of airtime calculations are not very good, because they may not take into account airtime that is unusable because of variable channel conditions or co-channel interference that the access point cannot directly see, such as client-to-client interference

All in all, you might find vendors recommending setting the values to a low, safe value that allows for voice to work even if there is plenty of variability in the network. This works well for networks that are predominantly data-oriented, but voice-only networks cannot usually afford that luxury.

WMM Admission Control | Voice Mobility with Wi-Fi

noreply@blogger.com (JohnJenin) — Fri, 27 Jan 2012 13:05:00 +0000

Building on even more of the specification in the 802.11e quality-of-service amendment is WMM Admission Control. This specification and interoperability program from the Wi-Fi Alliance, which is required to achieve Voice Enterprise certification, uses an explicit layer-2 reservation scheme. This scheme, in a similar vein as the lightly used RSVP protocol (RFC 2205), requires the mobile device to reach out and request resources explicitly from the access point, using a new protocol built on top of 802.11 management frames.

This protocol is heavily dependant on the concept of a traffic specification (TSPEC). The TSPEC is created by the mobile phone, and specifies how much of the air resources either or both directions of the call (or whatever resource is being requested) will be taken. The access point processes the request as an admission controller (a function often placed literally on the controller, by coincidence), which is in charge of maintaining an account of which clients have requested what resources and whether they are available.

The overall protocol is rather simple. The mobile device, usually when it determines that it has a call incoming our outgoing, will send an Add Traffic Stream (ADDTS)Request message (a special type of Action management frame) to the access point, containing the TSPEC that will be able to carry the phone call. The access point will decide whether it can carry that call, based on whatever scheme it uses (see following discussion), and send an ADDTS Response message stating whether the stream was admitted.

WMM Admission Control can be set to mandatory or optional for each access category. For example, WMM Admission Control can be required for voice and video, but not for best effort and background data. What this would mean is that no client is allowed to transmit voice or video packets without first requesting and being granted admission for flows in those access categories, whereas all clients would be allowed to freely transmit best effort and background data as they see fit. Which access categories require admission control is signaled as a part of the WMM information element, which goes out in beacons and some other frames.

For WMM Admission Control, it is worth looking at the details of the concepts. The main concept is one of a traffic stream itself, and how it is identified and recognized. Traffic streams are represented by Traffic Identifiers (TID), a number from 0-7 (the standard allows up to 15, but WMM limits this to only 7) that represents the stream. Each client gets its own set of eight TIDs to use.

Each traffic stream, represented by its TID, maps onto real traffic by naming which of the eight priority values in WMM will belong to this traffic stream. Thus, if the phone intends to send and knows it is going to receive priority 7—recall that this is the highest of the two voice AC priorities—it can establish a traffic stream that maps priority 7 traffic to it, and get both sides of the call. In order for that to work, the client can specify whether the traffic stream is upstream-only, downstream-only, or bidirectional. It is possible for the client to request both an upstream-only and downstream-only stream mapping to the same priority (different TIDs, though!), if it knows that the airtime used by the downstream side is different than the upstream side—useful for video calls—or it may request both at once in one TID, with the same airtime usage. All of this freedom leads to some complexity, but thankfully there is a rule preventing there from being more than one downstream and one upstream flow (bidirectional counts as one of each) for each access category. Thus, the AC_VO voice access category will only have one admitted bidirectional phone call in it at any given time.^[*]

The client requests the traffic stream using the TSPEC.

Table 1 shows the contents of the TSPEC that is carried in an ADDTS message.

Table 1: WMM admission control TSPEC

TS Info	Nominal MMSDU Size	Maximum MSDU Size	Minimum Service Interval	Maximum Service Interval	Inactivity Interval	Suspension Interval	Service Start Time
3 bytes	2 bytes	2 bytes	4 bytes	4 bytes	4 bytes	4 bytes	4 bytes

Minimum Data Rate	Mean Data Rate	Peak Data Rate	Maximum Burst Size	Delay Bound	Minimum PHY Rate	Surplus Bandwidth Allowance	Medium Time
4 bytes	4 bytes	4 bytes	4 bytes	4 bytes	4 bytes	2 bytes	2 bytes

There's quite a lot of information in a TSPEC, so let's break it down slowly, using the example of a 20 millisecond G.711 (nearly uncompressed) one-way traffic flow:

The TS Info field (see Table 2) identifies the TID for the stream, the priority of the data frames that belong to this stream, what direction the stream is going in (00 = up, 01 = down, 10 = reserved, 11 = bidirectional), and whether the AC the stream belongs to is to be WMM Power Save delivery enabled (1) or not (0). The rest of the fields are not used in WMM Admission Control, and have specific values that will never change (Access Policy = 01, the rest are 0).

Table 2: The TS info field
	Traffic Type	TID	Direction	Access Policy	Aggregation	WMM Power Save	Priority	TSInfo Ack Policy	Schedule	Reserved
Bit:	0	1-4	5-6	7-8	9	10	11-13	14-15	16	17-23

The Nomimal MSDU Size field mentions the expected packet size, with the highest-order bit set to signify that the packet size never changes. G.711 20ms packets are 160 bytes of audio, plus 12 bytes of RTP header, 8 bytes of UDP header, 20 bytes of IP header, and 8 bytes of SNAP header, creating a data payload (excluding WPA/WPA2 overhead) of 208 = 0×D0. Because the packet size for G.711 never changes, this field would be set to 0×80D0.
The Maximum MSDU Size field specifies what the largest a data packet in the stream can get. For G.711, that's the same as the nominal size. There is no special bit for fixed sizes, so the value is 208 = 0×00D0. This can also be left as 0, as it is an optional field.
The Inactivity Interval specifies how long the stream can be idle—no traffic matching it—in microseconds, before the access point can go ahead and delete the flow. 0 means not to delete the flow automatically, and that's the common value.
The Mean Data Rate specifies, in bits per second, what the expected throughput is for the stream. For G.711, 208 bytes every 20 milliseconds results in a throughput of 83200 bits per second.
The Minimum Data Rate and Peak Data Rate specify the minimum and maximum throughput the traffic stream can expect. These are optional and can be set to 0. For G.711, these will be the same 83,200 bits per second.
The Minimum PHY Rate field specifies what the physical layer data rate assumptions are for the stream, in bits per second. If the client is assuming that the data rate could drop as low as 6Mbps for 802. Hag, then it would encode the field at 6Mbps = 6,000,000bps = 0×005B8D80.
The Surplus Bandwidth Allowance is a fudge factor that the phone can request, to account for that packets might be retransmitted. It's a multiplier, in units of l/8192nds. A value of 1.5 times as an allowance would be encoded as 0×3000 = 001.1000000000000, in binary.
The other fields are unused by the client, and can be set to 0.

In other words, the client simply requests the direction, priority, packet size, data rate, and surplus allowance.

The access point gets this information, and churns it using whatever algorithms it wants— this is not specified by the standard, but we'll look at what sorts of considerations tend to be used. Normally, we'll assume that the access point knows what percentage of airtime is available. The access point will then decide how much airtime the requested flow will take, as a percentage, and see whether it exceeds its maximum allowance (say, 100% of airtime used). If so, the flow is denied, and a failing ADDTS Response is sent. If not, the access point updates its measure of how much airtime is being used, and then allows the flow. The succeeding ADDTS Response has a TSPEC in it that is a mirror of the one the client requested, except that now the Medium Time field is filled in. This field specifies exactly how much airtime, in 32-microsecond units per second, the client can take for the flow.

The definition of how much airtime a client uses is based on what packets are sent to it or that it sends as a part of a flow. Both traffic sent by the client to the access point and sent by the access point to the client are counted, as well as the times for any RTSs, CTSs, ACKs, and interframe spacings that are between those frames. Another way of thinking about it is that the time from the first bit of the first preamble to the last bit of the last frame of the TXOP counts, including gaps in between. In general, you will never need to try to count this. Just know that WMM Admission Control requires that the clients count their usage. If they exceed their usage in the access category they are using, they have to send all subsequent frames with a lower access category—and one that is not admission control enabled—or drop them.

One advantage of WMM Admission Control is that it works for all traffic types, without requiring the network to have any smarts. Rather, the client is required to know everything about the flows it will both send and receive, and how much airtime those flows will take. The network just plays the role of arbiter, allowing some flows in and rejecting others. Thus, if the client is sufficiently smart, WMM Admission Control will work whether the protocol is SIP, H.323, some proprietary protocol, or even video or streaming data. The disadvantage of that, however, is that the client is required to be smart, and all of its pieces—from wireless to phone software—have to be well integrated. That pretty much eliminates most softphones, and brings the focus squarely on purpose-built phones. Furthermore, the client needs to know what type of traffic the party on the other side of the call will send to it. Some higher-level signaling protocols can convey this, such as with SDP within SIP, but doing so may be optional and may not always be followed. For a phone talking to a media gateway, for example, the phone needs to know exactly how the media gateway will send its traffic, including knowing the codec and packet rate and sizing, before it can request airtime. That can lead to situations in which the call needs to be initiated and agreed to by both parties before the network can be asked for permission to admit the flow, meaning that the call might have to be terminated by the network midway through ringing, if airtime is not available. Because WMM Admission Control is so new—by the time of publication, WMM Admission Control should be launching shortly and large amounts of devices may not yet be available—it remains to be seen how well all of the pieces will fit together. It is notoriously difficult for general-purpose devices to be built that run the gamut of technologies correctly, and so these new programs might be more useful for highly specific purpose-built phones.

SIP-Based Admission Control | Voice Mobility with Wi-Fi

noreply@blogger.com (JohnJenin) — Tue, 24 Jan 2012 16:03:00 +0000

The first method is to rely on the call setup signaling. Because the most common mechanism today is SIP, we can refer to this as SIP-based admission control. The idea is fairly simple. The access point, most likely in concert with a controller if the architecture in use has one, uses a firewall-based flow-detection system to observe the SIP messages as they are sent from the phones to the SIP servers and back. Specifically, when the call is initiated, either by the phone sending a SIP Invite, or receiving one from another party, the wireless network determines whether there is available capacity to take the call. If there is available capacity, then the wireless network lets the messages flow as usual, and the call is initiated.

On the other hand, if the wireless network determines that there is no room for the call, it will intercept the SIP Invite messages, preventing them from reaching the other party, and interject its own message to the caller (as if from the called party, usually), with one of a few possible SIP busy statuses. The call never completes, and the caller will get some sort of failure message, or a busy tone.

Other, more advanced behaviors are also possible, such as performing load balancing, once the network has determined that the call is not going to complete.

The advantage of using SIP flow detection to do the admission control is that it does not require any added sophistication on the mobile devices than they would already have with SIP. Furthermore, by having that awareness from tracking the SIP state, the network can provide a list of both calls in progress and registered phones not yet in a call. The disadvantage is that this system will not work for SIP calls that are encrypted end-to-end, such as being carried over a VPN link.

Wi-Fi Multimedia (WMM) Power Save

noreply@blogger.com (JohnJenin) — Sun, 22 Jan 2012 13:15:00 +0000

To provide power saving while the mobile device is in a call, the Wi-Fi Alliance came up with the second power saving technique, WMM Power Save. This technique, based on the quality-of-service additions in the 802.11e amendment to the standard, acts as a parallel scheme to the legacy one, using similar concepts but in a way that avoids having to wait for beacons and can apply on a per-access-category basis.

If you notice, there is nothing in the standard that prevents clients that are using the legacy power save scheme from ignoring beacons, for the most part, and sending PS Polls whenever they want. If the client were sure that there is going to be a packet for it waiting every so often—say, 20 milliseconds—then it could just send PS Polls every 20 milliseconds, collect its data, and have real-time power save. Of course, this doesn't happen for legacy power save, because the client has no guarantee that it won't get some other frames rather than what it is looking for. However, this is the concept that WMM Power Save builds on.

WMM Power Save is optional, and support for it is signaled by the WMM information elements in the Association messages and the beacons. Unlike with legacy power save, WMM Power Save (capitalized, as it is a formal name) is aware of the WMM access categories and can apply to a subset of them. The two subsets are delivery-enabledaccess categories and trigger-enabled access categories.

First, let's start with the polling protocol. The client no longer checks the beacons to see if there is traffic. Instead, it is responsible for knowing that traffic is waiting for it, and how often. For phones, this is not a problem, as voice is bidirectional and consistent. Instead of sending a PS Poll frame, or using the PSNonPoll mechanism, the phone sends data frames in access categories that it has specified to be trigger-enabled. The access point looks for those data frames, and uses that as a trigger—just as it does in legacy with Power Save Poll frames—sending packets in response from the power save buffer. Those packets, however, can only come from the delivery-enabled access categories. Which categories are delivery- and trigger-enabled are usually specified in the Association Request from the client—there, a bitmask specifies which categories are legacy and which are delivery and trigger enabled together—or in TSPEC messages, which we will come to later.

Here's a common example. The phone associates, and tells the access point that it wants the voice category (AC_VO) to be delivery- and trigger-enabled. That means that the other three categories work on the legacy scheme. If packets come in for those other categories while the client is asleep, the TIM bit on the beacon will be set and the client will use legacy power save mechanisms to get the frames. But when a voice packet is sent to the access point, the access point silently holds onto the packet. The only way the client can get the voice packet is to send a voice packet of its own.

When it does, that causes the access point to respond with one or more voice packets in its buffer. Unlike with legacy power save, the client can ask for more than one packet at a time. Using the concept of a service period, which is set at Association time by the client and specifies the number of frames the client wants to get for every trigger (either two, four, six, or all), the access point will send out the correct number of frames. The last frame, whether because the buffer is empty or the service period has been exceeded, will have a special end of service period (EOSP) bit set in the QoS header. Once the client gets that frame, it can go back to sleep.

As you can see, the legacy and WMM Power Save schemes operate simultaneously and independently. The only overlap is that the client goes into to power save mode for both schemes simultaneously. This means that devices that are actively using WMM Power Save should never use the PSNonPoll method during that time, because the client waking up from power save mode will cause the access point to send all frames, whether they are from the legacy or WMM Power Save access categories.

The capability to support WMM Power Save should be considered nearly mandatory for most voice equipment. Some mobile devices use proprietary mechanisms that may or may not be supported by every access point, but the trend is towards using WMM Power Save.

Legacy Power Save | Voice Mobility over Wi-Fi

noreply@blogger.com (JohnJenin) — Wed, 18 Jan 2012 10:52:00 +0000

The first mode, known as legacy power saving because it was the original power saving technique for Wi-Fi, is used for saving battery during standby operation.

This power save mode is not designed for quality-of-service applications, but rather for data applications. The way it works is that the mobile device tells the access point when it is going to sleep. After that time, the access point buffers up frames directed to the mobile device, and sets a bit in the beacon to advertise when one or more frames are buffered. The mobile device is expected to wake every so many beacons and look for its bit set in the beacon. When the bit is set, the client then uses one of two mechanisms to get the access point to send the buffered frames.

This sort of system can be thought of as a paging mechanism, as the client is told when the access point has data for it—such as notification of an incoming call. Figure 1 shows the basics of the protocol.

Figure 1: Wi-Fi Legacy Power Save

The most important part of the protocol is the paging itself. Each client is assigned an association ID (AID) when it associates. The value is given out by the access point, in a field in the Association Response that it sent out when the client connected to it. The AID is a number from 1 to 2007 (an extremely high number for an access point) that is used by the client to figure out what bit to look at in the beacon. Each beacon carries a Traffic Indication Map (TIM), which is an abbreviated bit field. Each client who has a frame buffered for it has its bit set in the TIM, based on the AID. For example, if a client with AID of 10 has one or more frames buffered for it, the tenth bit (counting from zero) of the TIM would be set.

Because beacons are set periodically, using specific timing that ensures that it never goes out before its time, each client can plan on the earliest it needs to wake up to hear the beacon. That doesn't guarantee that the client will hear the beacon at exactly that time, however. Beacons can be delayed if the air is occupied at that time. Furthermore, because beacons are sent out as broadcasts, the client might just miss the beacon or the beacon can be collided with. If the client does hear the beacon, it can then go to sleep so long as no traffic is buffered for it.

Clients may also skip beacons. They would do this to save additional battery, at the expense of increasing the amount of time the frames would be buffered. Clients usually let the access points know how many beacons they will skip by sending a listen interval in their Association Request messages. A listen interval of 1 means that the client will wake for every beacon; a listen interval of 10 means that the client will wake only for every tenth beacon. Be careful, however; some clients do not follow the listen interval they state, waiting either for more or less beacons than they advertise.

The client signals that it is going to sleep by using the power management bit in any unicast frame it sends to the access point (except for non-Action management frames). The power management bit is in the Frame Control field for the frame. When the client sends a frame with the power management bit set and when it gets an Acknowledgement in response, it knows that the access point has heard the client's change of state and can now go to sleep. From this moment on, the access point will buffer frames, until the client sends any frame to the access point with the power management bit not set. That signals that the client is now awake, and can be sent packets as usual.

While the client is in power save mode, and it wakes to find that its TIM bit is set to signify that it has frames available for it, the client has two choices on how to gather those frames. The first choice is known as the PSPoll mechanism, and uses the Power Save Poll (PS Poll) frames. After the beacon with the client's TIM bit set, the client would send a PS Poll frame to the access point. This frame, which is usually acknowledged right away, triggers the access point to deliver exactly one of the buffered frames for the client. That buffered frame is put into the transmit queue, using the appropriate access category for WMM. The frame that is sent also has its More Data bit in the Frame Control field set if there are subsequent frames that are buffered. Once the client has the frame, it can chose to send another PS Poll to get another frame. This one-PS-Poll/one-data-frame exchange continues until the access point's buffer is drained or the client wishes to sleep more.

The other option the client has is to use the PSNonPoll mechanism. This mechanism is quite simple: the client simply sends a data frame, usually a Null data frame, stating that it is no longer sleeping, by clearing the power management bit. The access point will proceed to queue all of the buffered frames, each using its own WMM access category. The client can then wait for a certain amount of time, hoping that it got all of the frames it was going to get, after which it can send another Null data frame, signifying it is going back to sleep. Any frames that may have still been in a transmit queue might get buffered again by the access point, for a later PSNonPoll exercise. The advantage of the PSNonPoll mechanism is that it is simple and doesn't require a significant back-and-forth. The disadvantage is that the client has no way of knowing if there are any remaining frames for it, without going to sleep and waiting for the next beacon.

The choice between PSPoll and PSNonPoll modes is often left up to the client's software implementation, and not exposed to you. However, some clients do give a choice up front, or have specific behavior where they will use one method or the other, depending on how aggressive you set its power save settings to (using a slider, say). It should be clear that neither mode is good for quality-of-service traffic, because the client can be forced to wait as much as a beacon interval (times its listen interval) before it finds out traffic is available. If the beacon interval is set to the typical 100 milliseconds, and the listen interval is 10, then that can be up to a second of delay.

Broadcast and multicast frames are also covered in the legacy scheme. However, no polling is necessary for those frames to be delivered. Instead, the access point sets aside a certain number of the beacons for multicast traffic. If any client on the access point is in legacy power save mode, the access point will buffer all multicast traffic. The special beacons known as Delivery Traffic Indication Messages (the poorly named DTIM) are just like regular beacons, except that they come every so many beacons—when the next one is coming is signaled as a part of the TIM in every beacon—and they signal if multicast traffic is buffered. If multicast traffic is buffered, the TIM has the zeroth bit, corresponding to AID 0, set. If clients receive a beacon with that bit set, they know that the next frames coming from the access point will be all of the multicast frames buffered. Each multicast frame, except for the last one, will have the More Data bit set. Thus, clients can stay awake to collect all multicast traffic, and then go back to sleep after the last multicast data frame, with the cleared More Data bit, comes through. (Of course, if that last frame is lost, being multicast, the clients will have to decide on their own when to return to sleep.) The consequence of the all-or-nothing multicast buffering is that multicast traffic on Wi-Fi when any device is in power save is not generally suitable for real-time traffic! Look for architectures that provide solutions for this problem if real-time multicast is a priority for your network.

Finally, I haven't gone into details on how the TIM bits are compressed. It is not easy to read the TIM bits by hand, but a good wireless protocol analyzer will be able to read them for you, and let you know which AIDs are set in any beacon.

How Wi-Fi Multimedia (WMM) Works?

noreply@blogger.com (JohnJenin) — Sat, 14 Jan 2012 12:47:00 +0000

It is not easy to directly see what the consequences are by WMM creating multiple queues that act to access the air independently. But it is important to understand what makes WMM works, to understand how WMM—and thus, voice—scales in the network.

Looking at the common WMM parameters, we can see that the main way that WMM provides priority for voice is by letting voice use a faster backoff process than data. The shorter AIFS helps, by giving voice a small chance of transmitting before data even gets a chance, but the main mechanism is by allowing voice transmit, on average, with a quarter of the waiting time that best effort data has.

This mechanism works quite well when there is a small amount of voice traffic on a network with a potentially large amount of data. As long as voice traffic is scarce, any given voice packet is much more likely to get on the air as soon as it is ready, causing data to build up as a lower priority. This is one of the consequences of having different queues for traffic. As an analogy, picture the security lines at airports. Busy airports usually have two separate lines, one line for the average traveler, and another line for first-class passengers and those who fly enough to gain "elite" status on the airlines. When the line for the average traveler—the "best effort" line—is full of people, a short line for first class passengers gives those passengers a real advantage. In other words, we can think of best effort and voice as mostly independent. The problem, then, is if there are too many first-class passengers. For WMM, the problem happens when there is "too much" voice traffic. Unlike with the children of Lake Wobegone, not everyone can be above average.

Let's look at this more methodically. The backoff value is the primary mechanism that Wi-Fi is affected by density. As the number of clients increases, the chance of collision increases. Unfortunately, WMM provides for quality of service by reducing the number of slots of the backoff, thus making the network more sensitive to density. Again, if voice is rare, then its own density is low, and so a voice packet is not likely to collide with other voice packets, and the aggressive backoff settings for voice, compared to data, allow for voice to get on the network with higher probability. However, when the density of voice goes up, the aggressive voice backoff settings cause each voice packet to fight with the other voice packets, leading to more collisions and higher loss.

One solution for this problem is to limit the number of voice calls in a cell, thus ensuring that the density of voice never gets that high. This is called admission control. Another and an independent solution is for the system to provide a more deterministic quality of service, by intelligently setting the WMM parametersaway from the defaults. This exact purpose is envisioned by the standard, but most equipment today expects the user to hand-tune these values, something which is not easy.

Quality of Service with WMM-How Voice

noreply@blogger.com (JohnJenin) — Wed, 11 Jan 2012 14:06:00 +0000

Quality of Service with WMM-How Voice and Data Are Kept Separate

The first challenge is to address the unique nature of voice. Unlike data, which is usually carried over protocols such as TCP that are good at making sure they take the available bandwidth and nothing more, ensuring a continuous stream of data no matter what the network conditions, voice is picky. One packet every 20 milliseconds. No more, no less. The packets cannot be late, or the call becomes unusable as the callers are forced to wait for maddening periods before they hear the other side of their conversation come through. The packets cannot arrive unpredictably, or else the buffers on the phones overrun and the call becomes choppy and impossible to hear. And, of course, every lost packet is lost time and lost sounds or words.

On Ethernet, as we have seen, the notion of 802.1p or Diffserv can be used to give prioritization for voice traffic over data. When the routers or switches are congested, the voice packets get to move through priority queues, ahead of the data traffic, thus ensuring that their resources do not get starved, while still allowing the TCP-based data traffic to continue, albeit at a possibly lesser rate.

A similar principle applies to Wi-Fi. The Wi-Fi Multimedia (WMM) specification lays out a method for Wi-Fi networks to also prioritize traffic according to four common classes of service, each known as an access category (AC):

AC_VO: highest-priority voice traffic
AC_VI: medium-priority video traffic
AC_BE: standard-priority data traffic, also known as "best effort"
AC_BK: background traffic, that may be disposed of when the network is congested

The underscore between the AC and the two-letter abbreviation is a part of the correct designation, unfortunately. You may note that the term "best effort" applies to only one of the four categories. Please keep in mind that all four access categories of Wi-Fi are really best effort, but that the higher-priority categories get a better effort than the lower ones. We'll discuss the consequences of this shortly.

The access category for each packet is specified using either 802.1p tagging, when available and supported by the access point, or by the use of Diffserv Code Points (DSCP), which are carried in the IP header of each packet. DSCP is the more common protocol, because the per-packet tags do not require any complexity on the wired network, and are able to survive multiple router hops with ease. In other words, DSCP tags survive crossing through every network equipment that is not aware of DSCP tags, whereas 802.1p requires 802.1p-aware links throughout the network, all carried over 802.1Q VLAN links.

There are eight DSCP tags, which map to the four access categories. The application that generates the traffic is responsible for filling in the DSCP tag. The standard mapping is given in Table 1.

Table 1: DSCP tags and AC mappings
DSCP	TOS Field Value	Priority	Traffic Type	AC
0×38 (56)	0×E0 (224)	7	Voice	AC_VO
0×30 (48)	0×C0 (192)	6	Voice	AC_VO
0×28 (40)	0×A0 (160)	5	Video	AC_VI
0×20 (32)	0×80 (128)	4	Video	AC_VI
0×18 (24)	0×60 (96)	3	Best Effort	AC_BE
0×10 (16)	0×40 (64)	2	Background	AC_BK
0×08 (8)	0×20 (32)	1	Background	AC_BK
0×00 (0)	0×00 (0)	0	Best Effort	AC_BE

There are a few things to note here. First is that the eight "priorities"—again, the correct term, unfortunately—map to only four truly different classes. There is no difference in quality of service between Priority 7 and Priority 6 traffic. This was done to simplify the design of Wi-Fi, in which it was felt that four classes are enough. The next thing to note is that the many packet capture analyzers will still show the one-byte DSCP field in the IP header as the older TOS interpretation. Therefore, the values in the TOS column will be meaningless in the old TOS interpretation, but you can look for those specific values and map them back to the necessary ACs. Even the DSCP field itself has a lot of possibilities; nonetheless, you should count on only the previous eight values as having any meaning for Wi-Fi, unless the documentation in your equipment explicitly states otherwise. Finally, note that the default value of 0 maps to best effort data, as does the Priority 3 (DSCP 0×18) value. This strange inversion, where background traffic, with an actual lower over-the-air priority, has a higher Priority code value than the default best effort traffic, can cause some confusion when used; thankfully, most applications do not use Priority 3 and its use is not recommended here as well.

A word of warning about DSCP and WMM. The DSCP codes listed in Table 1 are neither Expedited Forwarding or Assured Forwarding codes, but rather use the backward-compatibility requirement in DSCP for TOS precedence. TOS precedence uses the top three bits of the DSCP to represent the priorities in Table 6.1, and assign other meanings to the lower bits. If a device is using the one-byte DSCP field as a TOS field, WMM devices may or may not ignore the lower bits, and so can sometimes give no quality-of-service for tagged packets. Further complicating the situation are endpoints that generate Expedited Forwarding DSCP tags (with code value of 46). Expedited Forwarding is the tag that devices use when they want to provide higher quality of service in general, and thus will usually mark all quality-of-service packets as EF, and all best effort packets with DSCP of 0. The EF code of 46 maps, however, to the Priority value of 5—a video, not voice, category. Thus, WMM devices may map all packets tagged with Expedited Forwarding as video. A wireless protocol analyzer shows exactly what the mapping is for by looking at the value of the TID/Access Category field in the WMM header.

This mapping can be configured on some devices. However, changing these values from the defaults can cause problems with the more advanced pieces of WMM, such as WMM Power Save and WMM Admission Control, so it is not recommended to make those changes. (The specific problem that would happen is that the mobile device is required to know what priority the other side of the call will be sending to it, and if the network changes it in between, then the protocols will get confused and not put the downstream traffic into the right buckets.)

Once the Wi-Fi device—the access point or the client—has the packet and knows its tag, it will assign the packet into one of four priority queues, based on the access categories. However, these queues are not like their wired Ethernet brethren. That is because it is not enough that voice be prioritized over data within the device; voice must also be prioritized over the air.

To achieve this, WMM changes the backoff procedure. Instead of each device waiting a random time less than some interval fixed in the standard, each device's access category gets to contend for the air individually. Furthermore, to get the over-the-air prioritization, higher quality-of-service access categories, such as voice, get more aggressive access parameters.

Each access category get four parameters that each determine how much priority the traffic in that category gets over the air, compared to the other categories. The first parameter is a unique per-packet minimum wait time called the Arbitration Interframe Spacing (AIFS). This parameter is the minimum amount of time that a packet in this category must wait before it can even start to back off. The longer the AIFS, the more a packet must wait, and the more it is likely that a higher-priority packet will have finished its backoff cycle and started transmitting. The key about the AIFS is that it is counted after every time the medium is busy. That means that a packet with a very high AIFS could wait a very long time, because the amount of time spent waiting for an AIFS does not count if the medium becomes busy in the meantime. The AIFS is measured in units of the number of slots, and thus is also called the AIFSn (AIFS number).

The second value is the minimum backoff CW, called the CWmin. This sets the minimum number of slots that the backoff counter for this particular AC must start with. As with pre-WMM Wi-Fi, the CW is not the exact number of slots that the client must wait, but the maximum number of slots that the packet must wait: the packet waits a random number of slots less than this value. The difference is that there is a different CW min for each access category. The CWmin is still measured in slots, but communicated to the client from the access point as the exponent of the power of two that it must equal. This exponent is called the ECWmin. Thus, if the ECWmin for video is 3, then the AC must pick a random number between 0 and 2³ − 1 = 7 slots. The CWmin is just as powerful as the AIFS in distinguishing traffic, by making access more aggressive by capping the number of slots the AC must wait to send its traffic.

The third parameter is similar to the minimum backoff CW, and is called the CWmax, or the maximum backoff CW. If you recall, the CW is required to double every time the sender fails to get an acknowledgement for a frame. However, that doubling is capped by the CWmax. This parameter is far mess powerful for controlling how much priority one AC gets over the other. As with the CWmin, there is a different CWmax for each AC.

The last parameter is how many microseconds the AC can burst out packets, before it has to yield the channel. This is known as the Transmit Opportunity Limit (TXOP Limit), and is measured in units of 32 microseconds (although user interfaces may show the microsecond equivalent). This notion of TXOPs is new with WMM, and is designed to allow for this bursting. For voice, bursting is usually not necessary or useful, because voice packets come on regular, well-spaced intervals, and rarely come back-to-back in properly functioning networks.

The access point has the ability to set these four AC parameters for every device in the network, by broadcasting the parameters to all of the clients. Every client, thus, has to share the same parameters. The access point may also have a different set for itself. Some access points set these values by themselves to optimize network access; others expose them to the user, who can manually override the defaults. The method that WMM uses to set these values to the clients is through the WMM Parameter Set information element, a structure that is present in every beacon, and can be seen clearly with a wireless packet capture system. Table 2 has the defaults for the WMM parameters.

Table 2: Common default values for the WMM parameters for 802.11
AC	Client		Access Point		CWmin	TXOP limit
	AIFS	CWmax	AIFS	CWmax		802.11b	802.11agn
Background (BK)	7	2¹⁰− 1 = 1023	7	2¹⁰ − 1 = 1023	2⁴− 1 = 15	0μs	0μs
Best Effort (BE)	3	2¹⁰− 1 = 102	3	2⁶− 1 = 63	2⁴− 1 = 15	0μs	0μs
Video (VI)	2	2⁴− 1 = 15	1	2⁴− 1 = 15	2³− 1 = 7	6016μs	3008μs
Voice (VO)	2	2³− 1 = 7	1	2³− 1 = 7	2²− 1 = 3	3264μs	1504μs

An Example of Security for 802.11

noreply@blogger.com (JohnJenin) — Sun, 08 Jan 2012 15:36:00 +0000

The client passes through a number of phases when associating to a Wi-Fi network that uses enterprise-grade security. To help understand how everything fits together, we will go through one example authentication, using WPA2 and the EAP method EAP-PEAP, which requires each mobile device to have a username and password. The password will be sent, securely tunneled through PEAP, to the RADIUS server, which is usually attached to a Microsoft Active Directory server.

Each message that is sent will be represented by a table, showing the relevant contents of the message. The aim is to allow the reader to follow along, when analyzing wireless packet capture traces, what the individual steps mean, when a client associates to the network. As a matter of presentation, when information that might be important is repeated in subsequent messages, it will be omitted for those messages.

Step 1: Associate with the Wi-Fi Network

The mobile device, having scanned for the SSID of the network desired—let's call it voice for this example—has found an access point that is advertising the voice SSID.

The client requests a connection with the access point by sending an 802.11 Authentication message, requesting open authentication, meaning that the client does not want to use WEP. See Table 1.

Table 1: 802.11 Authentication message from client to AP
Frame Control	Destination Address	Source Address	BSSID	Algorithm Number	Authentication Sequence
Authentication	AP Address	Client Address	AP Address	0 (Open System)	1

The access point accepts the open connection by responding with its own 802.11 Authentication message, to the client, simply stating that the request is a success. See Table 2.

Table 2: 802.11 Authentication message from AP to client
Frame Control	Destination Address	Source Address	BSSID	Algorithm Number	Authentication Sequence	Status Code
Authentication	Client Address	AP Address	Client Address	0 (Open System)	1	0 (Success)

The client then sends an 802.11 Association Request message to the access point, informing the access point of its Wi-Fi capabilities, supported extensions and 802.11 features (Table 3).

Table 3: 802.11 Association request message from client to AP
Frame Control	Destination Address	Source Address	BSSID	Capabilities	SSID	Information Elements
Association Request	AP Address	Client Address	AP Address	Capabilities	voice	Radio, Security, and QoS Capabilities

The access point accepts the association request and sends an 802.11 Association Response message to the client, announcing success, providing the client with the access point's capabilities and its network-wide configuration parameters.

At this point, the client cannot speak to any other access point without disconnecting or being disconnected, but it cannot send or receive any real data traffic. The client must first use EAPOL to authenticate.

Step 2: Authenticate with the AAA Server

The sends an EAPOL Start message (Table 4), encoded as a Wi-Fi Data frame with Ethernet protocol 0×888E, sent to the Ethernet address of the access point. This message is optional, but when sent is meant to request that the access point should start the EAP exchange.

Table 4: 802.11 EAPOL start message
Frame Control	Destination Address	Source Address	BSSID	Ether Type	EAPOL Type
Data	AP Address	Client Address	AP Address	0×888E	Start

At around the same time, the access point will usually voluntarily send an EAPOL message with an EAP Request Identity message inside (Table 5), triggering the start of the authentication process. The Request Identity message is the EAP way of asking the client to announce who he or she is.

Table 5: 802.11 EAP request identity
Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type	Identity
Client Address	AP Address	0×888E	0=EAP	1=Request	1=ldentity	hello

The client receives the request for the identity and responds with identity to use (Table 6). Let's call the user "user", in the domain "LOCATION". PEAP uses a separate protocol (MSCHAPv2) for the presentation of the real username and password. The identity given in the outer protocol may or may not matter, depending on the RADIUS server. In this example, the outer identity is the same one given as the real, inner identity: "LOCATION user".

Table 6: 802.11 EAP response identity
Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type	Identity
AP Address	Client Address	0×888E	EAP	2=Response	Identity	LOCATION user

This response triggers the start of the PEAP protocol, tunneled over EAP, tunneled over EAPOL, carried over 802.11. The first message is from the RADIUS server, through the access point, and informs the client that PEAP is beginning (Table 7).

Table 7: 802.11 EAP request PEAP
Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type	Flags
Client Address	AP Address	0×888E	EAP	Request	25=PEAP	Start

PEAP uses TLS as the outer tunnel, within which the encrypted username and password are passed. The first message in the TLS exchange is what is known as a TLS Client Hello (Table 8). The Client Hello passes the client's nonce, used as a part of the key derivation protocol. The client will specify a number of cipher suites, but must specify RSA public key encryption with RC4 stream encryption and either MD5 or SHA hashes.

Table 8: 802.11 PEAP client hello
Destination Address	Source Address	EAP Code	EAP Type	TLS Type	Handshake Type	Nonce	Cipher Suites
AP Address	Client Address	Response	PEAP	22=Handshake	1=Client Hello	random	Many

The server will respond with a Server Hello. The Server Hello message will specify the server's nonce, a session ID (which is usually not taken advantage of by wireless clients), one of the client's cipher suite to use for the rest of the process, and the beginning of a chain of certificates for the RADIUS server, which identifies itself as being valid. The client will usually verify that the server is signed by a valid certificate authority somewhere along the path and is allowed to serve the role it does, unless the client's administrator has explicitly disabled this check. Because certificates are much longer than the maximum EAPOL packet, the PEAP Server Hello and Certificate will be divided up over many consecutive EAPOL frames from the access point. After the certificate, the server may include a request for the client to send a certificate. This would be used by PEAP to short-circuit the inner tunnel and revert to plain TLS, if the client has a certificate. Usually, PEAP is not used with client certificates, so the client will ignore this request and trigger the password exchange. If requested, the types of certificates and distinguished names of acceptable certificate authorities, one of whom needed to have signed any client certificate given, will be provided. The message ends with a Server Hello Done. See Table 9.

Table9: 802.11 PEAP server hello and certificate, usually split across multiple EAPOL message

The client will respond to the intermediate server certificate messages with empty responses, to keep the request/response protocol going (Table 10).

Table 10: 802.11 EAP response PEAP
Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type
AP Address	Client Address	0×888E	EAP	Response	PEAP

When the Server Hello Done message arrives at the client, the client will kick off the second, inner phase of PEAP. First, the client responds with a Certificate handshake message. If the client were going to provide a certificate, it would do so here. However, with normal PEAP, the certificate message will be empty. Following this is the Client Key Exchange. Let's assume that the server and client agreed to RSA public key encryption. The client chooses a random 48-byte premaster key, which is encrypted by the server certificate's RSA public key, and then packaged in the key field. Following this comes the Change Cipher Spec message (Table 11), to inform the server that all future communications will take place using encryption based on the key. Finally, the first encrypted message is introduced, which is a marker, encrypted by the key, that states that the cipher change is done.

Table 11: 802.11 PEAP client change cipher spec

The server now responds with a Change Cipher Spec and Finished message (Table 12), to mark the switch over of the protocol completely to the inner TLS tunnel.

Table 12: 802.11 PEAP server change cipher spec
Destination Address	Source Address	EAP Code	TLS Type	Handshake Type	Handshake Type	Encrypted Handshake
Client	AP Address	Request	Handshake	Change Cipher Spec	Encrypted Handshake Message	Finished (encrypted with TLS PRF)

The client, once again, sends an empty response (Table 13).

Table 13: 802.11 EAP response PEAP
Destination Address	Source Address	Ether-type	EAPOL Type	EAP Code	EAP Type
AP Address	Client Address	0×888E	EAP	Response	PEAP

Now, the inner MSCHAPv2 protocol can take place. Table 14 will peel back the inner TLS tunnel and reveal the contents. The inner tunnel will also present an EAP exchange, but using MSCHAPv2, rather than TLS.

Table 14: 802.11 PEAP encrypted request identity
Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted with RC4)	EAP Type (encrypted)
Client Address	AP Address	Request	23=Application Data	Request	Identity

The first step of MSCHAPv2 is for the server to request the identity of the client.

The next step is for the client to respond, in an encrypted form, with the real identity of the user (Table 15). If the previous, outer response had been something arbitrary, the server will find out about the real username this way.

Table 15: 802.11 PEAP encrypted response identity
Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	EAP Type (encrypted)	Identity (encrypted)
Client Address	AP Address	Response	Application Data	Response	Identity	LOCATION\ user

The server then responds with a challenge (Table 16). The challenge is a 16-byte random string, which the client will use to prove its identity.

Table 16: 802.11 PEAP encrypted MSCHAPv2 challenge
Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	EAP Type (encrypted)	CHAP Code (encrypted)	Challenge (encrypted)
Client Address	AP Address	Response	Application Data	Request	MSCHAPv2	Challenge	random

The client responds to the challenge. First, it provides a 16-byte random challenge of its own. This is used, along with the server challenge, the username, and the password, to provide an NT response (Table 17).

Table 17: 802.11 PEAP encrypted MSCHAPv2 response
Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	CHAP Code (encrypted)	Peer Challenge (encrypted)	Response (encrypted)
AP Address	Client Address	Response	Application Data	Response	Response	random	NT response

Assuming the password matches, the server will respond with an MSCHAPv2 Success message (Table 18). The success message includes some text messages which are intended to be user printable, but really are not.

Table 18: 802.11 PEAP encrypted MSCHAPv2 server success
Destination Address	Source Address	EAP Code	TLS Type	EAP Code(encrypted)	CHAP Code(encrypted)	Authenticator Message(encrypted)	Success Message(encrypted)
Client Address	AP Address	Request	Application Data	Request	Success

The client now responds with a success message of its own (Table 19).

Table 19: 802.11 PEAP encrypted MSCHAPv2 client success
Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	CHAP Code (encrypted)
AP Address	Client Address	Response	Application Data	Response	Success

The server sends out an EAP TLV message now, still encrypted, indicating success (Table 20). The exchange exists to allow extensions to PEAP to be exchanged in the encrypted tunnel (such as a concept called cryptobinding, but we will not explore the concept further here).

Table 20: 802.11 PEAP encrypted MSCHAPv2 server TLV
Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	TLV Result (encrypted)
Client Address	AP Address	Request	Application Data	33=TLV	Success

The client sends out an EAP TLV message of its own, finishing up the operation within the tunnel (Table 21).

Table 21: 802.11 PEAP encrypted MSCHAPv2 server TLV
Destination Address	Source Address	EAP Code	TLS Type	EAP Code (encrypted)	TLV Result (encrypted)
AP Address	Client Address	Response	Application Data	TLV	Success

Now, the server sends the RADIUS Accept message to the authenticator. This message includes the RADIUS master key, derived from the premaster key that the client chose. This key is sent to the authenticator, where it becomes the PMK for WPA2 or the input to the PMK-R0 for 802. 11r. The authenticator then generates an EAP Success message (Table 22), which is sent over the air to the client.

Table 22: 802.11 EAP success
Destination Address	Source Address	EAP Code
Client Address	*AP Address*	3=Success

The sheer number of packets exchanged in this 802.1X step is what leads to the need for key caching for mobile clients in Wi-Fi, and also eliminates the need to perform the 802.1X negotiation except on the first login of the client.

Step 3: Perform the Four-Way Handshake

Both the authenticator and the client have the PMK. The four-way handshake derives the PTK. The first message (Table 23) sends the authenticator's nonce, and a copy of the access point's RSN information.

Table 23: 802.11 Four-way handshake message one
Destination Address	Source Address	EAPOL Type	Key Type	Flags	Nonce	RSN IE
Client Address	AP Address	Key	RSN (WPA2)	Ack	random	Same as in Beacon

The client generates the PTK, and sends the next message (Table 24), with its nonce and a copy of the client's RSN information, along with a MIC signature.

Table 24: Four-way handshake message two
Destination Address	Source Address	EAPOL Type	Flags	Nonce	MIC	RSN IE
AP Address	Client Address	Key	MIC	random	hash	Same as in Association

The third message, also with a MIC, delivers the GTK that the authenticator is currently using for the BSS, encrypted (Table 25).

Table 25: 802.11 Four-way handshake message three
Destination Address	Source Address	EAPOL Type	Flags	MIC	GTK
Client Address	AP Address	Key	Install, Ack, MIC	hash	encrypted

Finally, the client responds with the fourth message (Table 26), which confirms the key installation.

Table 26: 802.11 Four-way handshake message four
Destination Address	Source Address	EAPOL Type	Flags	MIC
AP Address	Client Address	Key	Ack, MIC	hash

Finally, the client is associated to the access point, and both sides are encrypting and decrypting traffic using the keys that came out of the 802.1X and WPA2 process.

Key Caching | 802.1X, EAP, and Centralized Authentication

noreply@blogger.com (JohnJenin) — Tue, 27 Dec 2011 21:44:00 +0000

Because the work required establishing a PMK when 802.1X and RADIUS are used is significant, WPA2 provides for a way for the PMK to be cached for the client to use, if it should leave the access point and return before the PMK expires.

This is done using key caching. Key caching works because each PMK is given a label, called a PMKID, that represents the name of the RADIUS association and the PMK that was derived from it. The PMKID is specifically a 128-bit string, produced by the function

where AA is the BSSID Ethernet address, SPA is the Ethernet address of the client, and HMAC-SHA1-128 is the first 128 bits of the well-known SHA1-based HMAC function for producing a cryptographic one-way signature with the PMK as the key. The double-pipes ("∥") represent bitwise concatenation. The "PMK Name" ASCII string is used to prevent implementers from putting the wrong function results in the wrong places and having it work by accident.

From this, it is pretty clear to see that a client and access point can share the same PMKID only if they have the same PMK and are referring to each other.

When the client associates, it places into its Reassociation message's RSN information element (Table 5.16) the PMKID it may have remembered from a previous association to the access point. If the access point also remembers the previous association, and still has the PMK, then the access point will skip starting 802. IX and will proceed to sending the first message in the four-way handshake, basing it on the remembered PMK.

This caching behavior is not mandatory, in the sense that either side can forget about the PMK and the connection will still proceed. If the client does not request a PMKID, or the access point does not recognize or remember the PMKID, the access point will still send an EAP Request Identity message, and the 802.1X protocol will continue as if no caching had taken place.

802.1X | Wi-Fi Radio Types

noreply@blogger.com (JohnJenin) — Fri, 23 Dec 2011 17:00:00 +0000

802.1X, also known as EAPOL, for EAP over LAN, is a basic protocol supported by enterprise-grade Wi-Fi networks, as well as modern wired Ethernet switches and other network technologies. The idea behind 802.1X is to allow the user's device to connect to the network as if the RADIUS server and advanced authentication systems did not exist, but to then block the network link for the device for all other protocols except 802. IX, until authentication is complete. The network's only requirements are twofold: prevent all data traffic from or to the client except for EAPOL (using Ethernet protocol 0×888E) from passing; and taking the EAPOL frames, removing the EAP messages embedded within, and tunneling those over the RADIUS protocol to the AAA server.

The job of the network, then, is rather simple. However, the sheer number of protocols can make the process seem complex. We'll go through the details slowly. The important thing to keep in mind is that 802.1X is purely a way of opening what acts like a direct link between the AAA server and the client device, to allow the user to be authenticated by whatever means the AAA server and client deem necessary. The protocols are all layered, allowing the highest-level security protocols to ride on increasingly more specific frames that each act as blank envelopes for its contents.

Once the AAA server and the client have successfully authenticated, the AAA server will use its RADIUS link to inform the network that the client can pass. The network will tear down its EAPOL-only firewall, allowing generic data traffic to pass. In the same message that the AAA server tells the network to allow the client (an EAP Success), it also passes the PMK—the master key that the client also has and will be used for encryption—to the network, which can then drop into the four-way handshake to derive the PTK and start the encrypted channel. This PMK exchange goes in an encrypted portion of the EAP response from the RADIUS server, and is removed when the EAP Success is forwarded over the air. The encryption is rather simple, and is based on the shared password that the RADIUS server and controller or access point have. Along with the PMK comes a session lifetime. The RADIUS server tells the controller or access point how long the authentication, and subsequent use of the keys derived from it, is valid. Once that time expires, both the access point and the client are required to erase any knowledge of the key, and the client must reauthenticate using EAP to get a new one and continue using the network.

For network administrators, it is important to keep in mind that the EAP traffic in EAPOL is not encrypted. Because the AAA server and the client have not agreed on the keys yet, all of the traffic between the client and the RADIUS server can be seen by passive observers. This necessarily limits the EAP methods—the specific types of authentication—that can be used. For example, in the early days of 802.1X, an EAP method known as EAP-MD5 was used, where the user typed a password (or the client used the user's computer account password), which was then hashed with the MD5 one-way cryptographic hash algorithm, and then sent across the network. Now, MD5 is flawed, but is still secure enough that an attacker would have a very hard time reverse-engineering the password from the hash of it. However, the attacker wouldn't need to do this, as he could just replay the same MD5 hashed version himself, as if he were the original user, and gain access to the network. For this reason, no modern wireless device supports EAP-MD5 for wireless authentication.

What is Authentication in 802.1X?

noreply@blogger.com (JohnJenin) — Tue, 20 Dec 2011 14:06:00 +0000

Let's first define exactly what authentication is, and what the technology expects out of the authentication process. We've mentioned credentials immediately preceding this section. An authentication credential is something that one party to communication has that the other parties can use to verify whether the user is really who he claims he is and is authorized to join the network.

In the preshared key case, the authentication credential is just the preshared key, a global password that every user shares. This is not very good, because every user appears identical, and there is no way for users to know that their networks are also authentic. Authentication should be a two-way street, and it is important for the clients to know that the network they are connecting to is not a fraud. With preshared keys, anyone with the key can set up a fraudulent rogue access point, install the key, and appear to be real to the users, just as they can arbitrarily decrypt over-the-air traffic.

Normal computer account security, such as what is provided by email servers, enterprise personal computers, and Active Directory (AD) networks, generally uses the notion that a user has a unique, secret password. When the user wants to access the network, or the machine, or the email account, she enters her password. If this password matches, then the user is allowed in. Otherwise, he or she is not.

(In fact, to prevent the system administrators from having access to the user's password, which the user might use in other systems and might not want to share, these systems will record a cryptographically hashed version of the password. This version, such as the MD5-hashed one mentioned in the next section, prevents anyone looking at it from knowing what the original password is, yet at the same time allows the user to type their password at any time, which leads to a new MD5-hashed string that will be identical to the one recorded by the system if and only if the passwords are identical.)

This identifies the user, but what about the network, which can't type a password to prove itself to the user? More advanced authentication methods use public key cryptography to provide more than a password. The background is quite simple, however. Public key cryptography is based on the notion of a certificate. A certificate is a very small electronic document, of an exact and precise format, containing some basic information about the user, network, or system that the certificate represents. I might have a certificate that states that it is written for jepstein@somecompany.com, pretending for a moment that that is the name of my user account at some company. The network might have a certificate that states it is written for network.somecompany.com, using the DNS name of the server running the network. To ensure that the contents of the certificate are not downright lies made up in the moment, each certificate is signed using another certificate, that of a certificate authority who both parties need to trust in advance. Finally, each certificate includes some cryptographic material: a public key, that is shouted out in the certificate, and a private key, which the owner of the certificate keeps hidden and tells no one. This private key is like a very big, randomly generated password. The difference is that the private key can be used to encrypt data that the public key can decrypt, and the public key can be used to encrypt data that the private key can decrypt. This allows the holder of the certificate to prove his or her identity by encrypting something using his or her private key. It also allows anyone else in the world to send the holder of the certificate a private message that only the holder can decrypt.

Certificates are necessary for network authentication. When the user tries to authenticate to the network, the network will prove its identity by using its private key and certificate, and the client will accept it only if the network gives the right information based on that certificate. Certificates are also useful for user authentication, because the same properties work in reverse. The EAP method known as EAP-TLS requires client certificates. Most of the other Wi-Fi-appropriate EAP methods use only server certificates, and require client passwords instead.

To recap, authentication over Wi-Fi means that the user enters a password or sends his certificate to the AAA server, which proves his identity, while the network sends its certificate to the client, whose supplicant automatically verifies the network's identity—just like how web browsers using HTTPS verify the server's identity.

It is the EAP method's job to specify whether passwords or certificates are required, how they are sent, and what other information may be required. The EAP method also is required to allow the AAA server and the client to securely agree to a master key—the PMK—which is used long after authentication to encrypt the user's data. The EAP method also must ensure that the authentication process is secure even though it is sent over an open, unencrypted network, as you will see in the following section on 802.1X.

The administrator is allowed to control quite a bit about what types of authentication methods are supported. The AAA administrator (not, you may note, the network administrator, unless this is the same person) determines the EAP methods, and thus the certificate and authentication requirements. The AAA administrator also chooses how long a user can keep network access until he or she has to reauthenticate using EAP. The network administrator controls the encryption algorithm—whether to use WPA or WPA2. Together, the two administrators can use extensions to RADIUS to also introduce network access policies based on the results of the AAA authentication.

802.1X, EAP, and Centralized Authentication | Security for 802.11

noreply@blogger.com (JohnJenin) — Fri, 16 Dec 2011 11:33:00 +0000

Wi-Fi's self contained security mechanisms. With WPA2, the encryption and integrity protection of the data messages can be considered strong. But we've only seen preshared keys, or global passwords, as the method the network authenticates the user, and preshared keys are not strong enough for many needs.

The solution is to rely on the infrastructure provided by centralized authentication using a dedicated Authentication, Authorization, and Accounting (AAA) server. These servers maintain a list of users, and for each user, the server holds the authentication credentials required by the user to access the network. When the user does attempt to access the network, the user is required to exercise a series of steps from the authentication protocol demanded by the AAA server. The server drives its end of the protocol, challenging the user, by way of a piece of software called a supplicant that exists on the user's device, to prove that the user has the necessary credentials. The network exists as a pipe, relaying the protocol from the AAA server to the client. Once the user has either proven that she has the right credentials—she apparently is who she says she is—the AAA server will then tell the network that the user can come in.

The entire design of RADIUS was originally centered around providing password prompts for dial-up users on old modem banks. However, with the addition of the Extensible Authentication Protocol (EAP) framework on top of RADIUS, and built into every modern RADIUS server, more advanced and secure authentication protocols have been constructed. See Figure 1.

Figure 1: The Components of RADIUS Authentication over Wi-Fi

The concept behind EAP is to provide a generic framework where the RADIUS server and the client device can communicate to negotiate the security credentials that the network administrator requires, without having to concern or modify the underlying network access technology. To accomplish this last feat, the local access network must support 802.1X.