Telecom Made Simple

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.

Wi-Fi Link Security

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

To summarize, 802.11 security is provided by three different grades of technology: the outdated and broken WEP, the transition-providing WPA, and the secure and modern WPA2.

WPA and WPA2 are both built on the same framework of 802. Hi, which provides a rich protocol for 802.11 clients and access points to communicate and negotiate which over-the-air encryption and integrity algorithms should be used.

Networks start off with a master key—either a preshared key, entered as text by the user into the access point and mobile device, or generated in real time by enterprise-grade authentication systems. This master key is then used to derive a per-connection key, called the PTK. The PTK is then used to encrypt and provide integrity protection for each frame, using either TKIP for WPA or AES for WPA2.

It bears repeating that preshared keys, for all grades of 802.11 security, have problems that cause both security and management headaches. The biggest security headache is that the privacy of the entire network is based on that PSK being kept private for eternity. If a PSK is ever found out by an attacker—even if that key has been retired or changed a long time ago—then the attacker can use that key to decrypt any recordings of traffic that were taken when the PSK had been in use. Furthermore, because preshared keys are text and are common for all devices, they are easy to share and impossible to revoke. Good users can be fooled into giving the PSK away, or bad users—such as employees who have left the organization—can continue to use the preshared keys as often as they desire.

These problems are solved, however, by moving away from preshared keys to using 802.1X and EAP. Recently, some vendors have been introducing the ability to create per-user preshared keys. The advantage of having per-user keys is that one user's access can be revoked without allowing that user to compromise the rest of the network. The problem with this scheme, however, is the continued lack of forward secrecy, meaning that a user who has his password stolen can still have decrypted every packet ever sent or will send using that key. For this reason, 802.1X is still recommended, using strong EAP methods that provide forward secrecy.

WPA2 and AES | Security for Wi-fi Radio

noreply@blogger.com (JohnJenin) — Fri, 09 Dec 2011 10:22:00 +0000

WPA2 introduces a new encryption algorithm, using the Advanced Encryption Standard (AES). This cipher was produced to be used as a standard algorithm wherever encryption is needed.

AES is a block cipher, unlike RC4. A block cipher takes blocks of messages—fixed chunks of bytes—and encrypts each block, producing a new block of the same size. These are nonlinear ciphers, and so the bit-flip attacks are significantly harder. AES was specifically designed and is believed to be practically impervious to those styles of attacks. With block ciphers, each block starts off independently, a bit of a downside compared to stream ciphers. To remove that independence, WPA2 also uses what is called Counter mode, a simple concept where later blocks are made to depend on previous blocks.

The MIC used is also based on AES, but is used as a cryptographic hash. This use is called cipher block chaining (CBC), and essentially uses the same concept of making later blocks depend on earlier ones, but only outputting the last block as the result. This small block (128 bits) is dependent on every bit of the input, and so works as a signature, or hash.

The overall algorithm used is known as Counter Mode with Cipher Block Chaining-Message Authentication Code (CCMP).

Table 1 shows the frame body used with WPA2. As with WPA, WPA2 has essentially the same expanded IV. Because WPA2 isn't using TKIP, the name has been changed to the packet number (PN), but serves the same purpose, starting at 0 and counting up. The PN is used for replay detection, as well as ensuring per-frame keying. The MIC is also eight bytes, but uses CBC-MAC rather than Michael. With new hardware, the last vestige of WEP can be dropped, and the old ICV is removed.

Table 1: 8.02.11 Fram Body with WPA2
PN = IV	Data	MIC
8 bytes	n—8 bytes	8 bytes

Because the WPA2 MIC is considered to be cryptographically strong, the designers of WPA2 eliminated the countermeasures that WPA has. It is still true that no frame should come in with an invalid MIC; however, the administrator can be alerted to deal with it in his own time, as there are not any known exploits that can be successfully mounted against WPA2 using an invalid MIC to date.

WPA and TKIP | Security for 802.11

noreply@blogger.com (JohnJenin) — Mon, 05 Dec 2011 09:11:00 +0000

TKIP was designed to run on WEP hardware without slowing the hardware down significantly. To do this, TKIP is a preprocessing step before WEP encryption. RC4 is still the encryption algorithm, and the WEP CRC-32 could not be eliminated. However, TKIP adds features into the selection of the per-frame key, and introduces a new MIC to sit beside the CRC-32 and provide better integrity.

The first change is to expand the IV and key ID fields to eight bytes total (see Table 1). The expanded fields gives a six-byte IV, now called the TKIP sequence counter(TSC). The goal is to give plenty of room so that the TSC nearly never needs to wrap. Furthermore, if it does get close to wrapping, the client is required to renegotiate a new PTK. This prevents key reuse. Finally, the TSC is used to provide the replay protection missing in WEP. The TSC is required to go up by one for each message. Each side keeps the current TSC that it is sending with, and the one it last received successfully from the other side. If a frame comes in out of order—that is, if it is received with an old TSC—the receiver drops it. An attacker can no longer replay valid but old frames. And, of course, although it can try to invent new frames, even with higher TSCs, the receiver won't update the last good TSC unless the frame is decryptable, and it will not be because the attacker does not know the key.

Table 1: 8.02.11 Fram Body with WPA
Expanded IV	Data	MIC	ICV
8 bytes	n - 8 bytes	8 bytes	4 bytes

The second change is to come up with a better way of producing the per-frame key. The per-frame key for TKIP uses a new algorithm that takes into account not only the now larger IV and the PTK, but the transmitter's address as well. This algorithm uses a cryptographic device known as an S-box to spread out the per-frame key in a more even, random-looking pattern. This helps avoid the problems with weak RC4 per-frame keys, which were specific WEP per-frame keys that caused RC4 to leak information. The result of this algorithm is a brand new per-frame key for each frame, which avoids many of the problems with WEP.

Unfortunately, the underlying encryption is still WEP, using a linear cipher vulnerable to bit flipping. To catch more of the bit flips, a new, cryptographically "better" MIC was needed. WPA uses Michael, a special MIC designed to help with TKIP without requiring excessive computation. It is not considered to be cryptographically secure in the same sense as is WPA2, but is considered to be significantly better than CRC-32, and thus can be used to build secure networks with some caveats. In this case, the designers were aware of this limitation up front, and designed Michael to be good enough to provide that transition from WEP to something more secure down the road (which became AES).

The Michael MIC is not just a function of the data of the packet. It also depends on the sender's address, the receiver's address, and the priority of the packet, as well as the PTK. Michael is designed to avoid the iterative guessing and bit flipping that WEP is vulnerable to. Furthermore, it is based on the entire frame, and not just individual fragments, and so avoids some fragmentation attacks that can be used against WEP. The result of Michael is the eight-byte MIC, which is placed at the end of the frame before it is sent for WEP encryption.

Because the designers know that Michael isn't enough, they also built in a provision for detecting when an attack is under way. Attackers try to modify frames and submit them, and see if the modified frames get mistaken as being authentic. Most of the time, they fail, and these modified frames are not decryptable. With WEP, a nondecryptable frame is silently dropped, with no harm. However, a frame with a bad MIC should never happen in a properly functioning system, and is a sign that the network is under attack. To help prevent these attacks from being successful, WPA adds the concept of countermeasures. If two frames with bad MICs (but good FCSs, so that we know they are not corrupted by radio effects) are received in a 60-second interval, the access point kicks all of the clients off and requires them to renegotiate new keys. This drastic step introduces a painful denial-of-service vulnerability into TKIP, but is necessary to prevent attackers from getting information easily. Of course, having countermeasures doesn't increase the robustness of the underlying algorithms, but kicking off all of the clients ensures that the attacker has to start from scratch with a new PTK.

Overall, TKIP was an acceptable bridge from WEP to WPA2. The designers rightfully recognize that TKIP is itself flawed, and is subject to a few vulnerabilities of its own. Besides the obvious denial-of-service attacks, TKIP also still allows for attacks that attempt to guess at certain parts of the particular messages and make some minor, but arbitrary, alterations to the packets successfully. Although workarounds exist for these types of attacks, TKIP will never be entirely hassle-free.

Therefore, I recommend that you migrate to WPA2 for every device on the network.

RSNA with 802.11i | Wi-Fi Security Technologies

noreply@blogger.com (JohnJenin) — Sun, 27 Nov 2011 08:21:00 +0000

802.11i addresses the major problems with WEP. The first problem, the inability to establish per-connection keys, and the inability to use different encryption algorithms, was fixed by a better protocol.

On top ofthat, 802.11i introduced two new encryption and integrity algorithms. Wi-Fi Protected Access (WPA), version one, was created to quickly work around the problems of WEP without requiring significant changes to the hardware that devices were built out of. WPA introduced the Temporal Key Integrity Protocol (TKIP), which sits on top of WEP and fixes many of the problems of WEP without requiring new hardware. TKIP was designed intentionally as a transition, or stopgap, protocol, with the hopes that devices would be quickly retired and replaced with those that supported the permanent solution, the second of the two algorithms.

Wi-Fi Protected Access version 2 (WPA2), as that permanent solution, required completely new hardware by not worrying about backwards compatibility. WPA2 uses AES to provide better security and eliminate the problems of using a linear stream cipher. A better integrity algorithm ensures that the packet has not been altered, and eliminates some of the denial-of-service weaknesses that needed to be introduced into TKIP to let it ward off some of the attacks that can't be directly stopped.

A word, first, on nomenclature. For those of you in the know, you might know that WPA has both TKIP and AES modes, 802.11i has slightly different TKIP and AES modes, and that both were harmonized in WPA2. However, practically, there really is no need to know that. For the remainder of this chapter, I will use WPA to mean TKIP as defined in WPA, WPA2 to mean AES as defined in the standard, and 802.11i to mean the framework under which WPA and WPA2 operate. This is actually industry convention—WPA and TKIP go hand in hand, and WPA2 and AES go hand in hand—so product documentation will most likely match with this use of the terms, but when there is doubt, ask your vendors whether they mean TKIP or AES.

802.11i first introduced the idea of a per-connection key negotiation. Each client that comes into the network must first associate. For WEP, which has no per-connection key, the client always used the user-entered WEP key, which is the same for every connection. But 802.11i introduces an additional step, to allow for a fresh set of per-connection keys every time, yet still based on the same master key.

Networks may still used preshared keys. These are now bumped up to be 128 bits long. For WPA or WPA2, this mode of security is known as Personal, because the preshared key method was intended for home use. Enterprises can also use 802.1X and a RADIUS server to negotiate a unique key per device. This mode of security is known as Enterprise. For example, "WPA2 Enterprise" refers to using WPA2 with 802.1X. Either way, the overall key is called the pairwise master key (PMK). This is the analog to the original WEP key.

Now, when the client associates, it has to run a four-message protocol, known as the four-way handshake, to determine what should be used as the key for the connection, known as the PTK (the pairwise temporal key or pairwise transient key). This whole concept of derived keys is known as a key hierarchy.

The four way handshake is made of unencrypted data frames, with Ethernet type of EAPOL (0×888E), and show up as the specific type of Extensible Authentication Protocol over LAN (EAPOL) message known as an EAPOL Key message. These four messages can be seen by wireless capture programs, and mark the opening of the data link between the client and the access point. Before the four-way handshake, clients and access points cannot exchange any data besides EAPOL frames. After the handshake, both sides can use the agreed-upon key to send data.

Message 1 of the four-way handshake is sent by the access point to the client, and signals the security settings of the access point (as contained in something called theRSN IE, shown in Table 1). The RSN IE contains the selection of encryption and integrity algorithms. The message also contains something called a nonce, which is a random number that the access point constructs (more on this shortly) and which will be mixed in with the PMK to produce the PTK.

Table 1: The security settings in the RSN IE
Element ID	Length	Version	Group Cipher Suite	Pairwise Cipher Suite Count	Pairwise Cipher Suite List	AKM Suite Count	AKM Suite List	RSN Capabilities	PMKID Count	PMKID List
1 bytes	1 byte	2 bytes	4 bytes	2 bytes	n bytes	2 bytes	m bytes	2 bytes	2 bytes	pbytes

Message 2 is sent in response, from the client to the access point, and includes the same information, but from the client: a client RSN IE, and a client nonce. Once the client has chosen its nonce, it has enough information to produce the PTK on its end. The PTK is derived from the two nonces, the addresses of the access point and client, and the PMK. At this point, it might seem like the protocol is done: the client knows enough to construct a PTK before sending Message 2, and the access point, once it gets the message, can use the same information to construct its own PTK. If the two devices share the same PMK—the master key—then they will pick the same PTK, and packets will flow. This is true, but the protocol needs to do a little bit more work to handle the case where the PMKs do not agree. To do this, the client "signs" Message 2 with a message integrity code (MIC). The MIC used is a cryptographic hash based on both the contents of the message and the key (PTK). Thus, the access point, once it derives its own PTK from its PMK and the nonces, can check to see whether the client's sent MIC matches what it would generate using its own PTK. If they match, then the access point knows that message 2 is not a forgery and the client has the right key. If they do not match, then the access point drops the message.

If Message 2 is correct, then Message 3 is sent by the access point, and is similar to Message 1 except that it too is now "signed" by the MIC. This lets the client know that the access point has the right key: at Message 2, only the access point could detect an attacker, but not the client. Also, the client can now verify that the access point is using the same security algorithms as the client—a mismatch would only occur if an attacker is injecting false RSN IEs into the network to try to get one side or both to negotiate to a weaker algorithm (say, TKIP) if a stronger algorithm (say, AES) is available. Finally, for WPA2, the client learns of the multicast key, the group temporal key(GTK), this way, as it is encrypted with the PTK and sent as the last part of the message.

Message 4 is a response from the client to the access point, and validates that the client got Message 3 and installed all of the correct keys.

The nonces exist to prove to each side that the other side is not replaying these messages— that is, that the other side is alive and is not an attacker. Imagine that the access point sends its nonce. An attacker trying to replay a previous, valid handshake for the same client could send an old Message 2, but the MIC on that Message 2 can never be correct, because it would always be based on the access point nonce recorded previously and was used in that previous handshake, and not the new one that the access point just created. Thus, the access point always can tell the difference between a client that is really there, and one that is just replayed from the past. The client can use its nonce to do the same thing. Also, if either side has the wrong PMK—which would happen with preshared keys if someone typed one of the keys wrong—the devices can catch it in the four-way handshake and not pretend to have a working connection.

Overall, the four-way handshake lets the two sides come together on a fresh connection key every time. The four way handshake is the same, except for some minor details such as choice of algorithm, for WPA and WPA2.

By the way, keep in mind that the four-way handshake is only designed to provide a new PTK every time based on the same PMK, to provide a fresh PTK and eliminate the problem of old or stale keys that WEP has. The four-way handshake is not designed to hide the PTK from attackers who have the PMK. This is an important point: if an attacker happens to know the PMK already—such as a preshared key that he or she stole or remembered—then every PTK ever generated from that PMK, in the past and in the future, can be broken with minimal effort. This is known as a lack of forward secrecy and is a major security flaw in preshared key networks.

In other words, you must keep the PMK secret. Do not share preshared keys, ever—even if you have stopped using that preshared key and moved to a new one long ago. If an attacker had been recording your past conversations, when the old preshared key was in use, and someone leaks the preshared key to this attacker, your old conversations are in jeopardy.

WEP (Wired Equivalent Privacy) | Wi-Fi Security Technologies

noreply@blogger.com (JohnJenin) — Wed, 23 Nov 2011 11:30:00 +0000

WEP

WEP (Wired Equivalent Privacy) was the first attempt to secure 802.11. Unfortunately, the privacy it provided was neither equivalent to wired nor very good. Its very design does not protect against replays, meaning that an attacker can record prior valid traffic and replay it later, getting the network to repeat actions (such as charging credit cards) without detecting it. Furthermore, WEP uses for encryption RC4, an algorithm that was not designed to be used in the way WEP uses it, leading to ways of reverse-engineering and cracking the encryption without the key. Finally, WEP uses a very poor message integrity code.

All of that said, WEP is a good place to look to learn the mechanics of security in 802.11, as the later and better security additions replaced the broken pieces but did not destroy the framework.

Note

It is the author's recommendation to not use WEP in existing or new networks, under any circumstances, because of the known flaws. Please consider the studying of WEP to be an academic exercise at this point, and do not allow vendors to talk you into using it.

1) Keying

WEP starts off with an encryption key, or a piece of knowledge that is known by the access point and the client but is sufficiently complicated that outsiders—attackers, that is— shouldn't be able to guess it.

There is one and may be two or more WEP keys. These keys are each either 40 bits (WEP-40) or 104-bits (WEP-104) long, and are usually created usually from text passwords, although they can be entered directly as hexadecimal numbers. Manually entered keys are called pre-shared keys (PSK). WEP provides very little signaling to designate that encryption is in use, and there is no way to denote whether the short or long keys are being used. If any security, at all, is used in the network, the "Privacy" flag in the network's beacons are set. Clients that want to use WEP had to associate to the network and start sending encrypted traffic. If the keys matched, the network made forward progress and the user was happy. If the keys did not match, the user would not be able to do much, but would otherwise not know what the error was. As you can see, this is not an ideal situation, and is avoided in the modern, post-WEP protocols.

There are some more complicated possibilities, which are not worth going over, except to note that the origin of the confusing 802.11 term "authentication" for the first phase of a client's connection to the network came from an old method of using WEP to verify the key before association. This security method is completely ignored by post-WEP protocols, which use a different concept to ensure that clients have the right key. Therefore, the two Authentication frames are now considered vestigial, and carry no particularly useful information in them.

2) Encryption

The encryption key is not used directly to encrypt each packet. Instead, it is concatenated with a per-packet number, called the initialization vector (IV), to create the key that RC4 uses to encrypt the data. The initialization vector can be any number. Transmitters would start at zero, and add one for each frame sent, until it hit the end of the three-byte sequence, where it would start over at zero again. Why have a per-packet key, when the original key was supposedly secret? To answer this, let's look at the encryption algorithm for WEP, which is based on RC4.

RC4 is a stream cipher, meaning that it is designed to protect a large quantity of flowing, uninterrupted data, with minimal overhead. It is used, for example, to protect secure web traffic (HTTPS), because web traffic goes across in a stream of HTML. RC4 is really a pseudorandom number generator, with cryptographic properties to ensure that the stream of bits that comes out is hard to reverse-engineer. When given a key, RC4 generates an infinite number of bits, all appearing to be random. These bits are then matched up, bit-by-bit, to the incoming plaintext, or not yet encrypted, data. Each bit of the plaintext is added to each matching bit of the RC4 stream, without carry. This is also known as taking the exclusive or of two bits, and the logic goes that the resulting "sum" bit is 1 if either of the incoming bits are 0, and 0 otherwise. The mathematical operation is represented by the ⊕ symbol, and so the four possibilities for the exclusive or are as follows: 0 ⊕ 0 = 0, 0 ⊕ 1 = 1, 1 ⊕ 0 = 1, and 1 ⊕ 1 = 0. When applied to the plaintext and RC4 together, the resulting stream looks as random as the original RC4 stream, but has the real data in it. Only a receiver with the right key can recreate the RC4 stream, do the same bitwise exclusive or to the encrypted data, and recover the original data. (The exclusive or operation has the property that any number that has any other number added twice provides the same number back: n ⊕ d ⊕ d = n. Therefore, applying the exclusive or of the RC4 stream twice to the original data, once by the encryption algorithm and once by the decryption algorithm, gets the plaintext data back.)

So far, so good. However, an attacker can use the properties of the exclusive or to recover the plaintext in certain cases, as well. If two frames come using the same per-frame key— meaning the same IV and WEP key—an eavesdropper can just add the two encrypted frames together. Both frames have the same per-frame key, so they both have the same RC4 stream, causing the exclusive or of the two encrypted frames to cancel out the identical RC4 stream and leave just the exclusive or of the two original, plaintext frames. The exclusive or of two plaintext frames isn't terribly different from having the original plaintext: the attacker can usually guess at the contents of one of the frames and make quick work discovering the contents of the other.

This isn't a flaw with RC4 itself, as it is with using any exclusive or cipher—a type of linear cipher, because ⊕ is really addition modulo 2—as they are vulnerable to bit-by-bit attacks unless other algorithms are brought in as well.

Okay, so that explains the per-frame keying and the IV, and why it is not a good solution for security. In summary, replays are allowed, and the IV wraps and key reuse reveals the original plaintext. Finally, the per-frame key doesn't include any information about the sender or receiver. Thus, an attacker can take the encrypted content from one device and inject it as if it were from another. With that, three of the problems of WEP are exposed. But the per-frame keying concept in general is sound.

3) Integrity

To attempt to provide integrity, WEP also introduces the integrity check value (ICV). This is a checksum of the decrypted data—CRC-32, specifically—that is appended to the end of the data and encrypted with it. The idea is that an attacker might want to capture an encrypted frame, make possibly trivial modifications to it (flipping bits or setting specific bits to 0 or 1), and then send it on. Why would the attacker want to do this? Most active attacks, or those that involve an attacker sending its own frames, require some sort of iterative process. The attacker takes a legitimate frame that someone else sends, makes a slight modification, and sees if that too produces a valid frame. It discovers if the frame was valid by looking for some sort of feedback—an encrypted frame in the other direction—from the receiver. As mentioned earlier, RC4 is especially vulnerable to bit flipping, because a flipped bit in the encrypted data results in the flipping of the same bit in the decrypted data. The ICV is charged with detecting when the encrypted data has been modified, because the checksum should hopefully be different for a modified frame, and the frame could be dropped for not matching its ICV.

As mentioned before, however, WEP did not get this right, either. CRC-32 is not cryptographically secure. The effect of a bit flip on the data for a CRC is known. An attacker can flip the appropriate bits in the encrypted data, and know which bits also need to be flipped in the CRC-32 ICV to arrive at another, valid CRC-32, without knowing what the original CRC-32 was. Therefore, attackers can make modifications pretty much at will and get away with it, without needing the key. But again, the concept of a per-framemessage integrity code in general is sound.

4) Overall

WEP alters the data packet, then, by appending the ICV, then encrypting the data field, then prepending the unencrypted IV. Thus, the frame body is replaced with what is in Table 1.

Table 1: 8.02.11 Frame Body with WeP
IV	Key ID	Data	ICV
3 bytes	1 byte	n—8 bytes	4 bytes

The issues described are not unique to RC4, and really applies to how WEP would use any linear cipher. There are also some problems with RC4 itself that come out with the way RC4 is used in WEP, which do not come out in RC4's other applications. All in all, WEP used some of the right concepts, but a perfect storm of execution errors undermined WEP's effectiveness. Researchers and attackers started publishing what became an avalanche of writings on the vulnerability of WEP. Wi-Fi was at risk of becoming known as hopelessly broken, and drastic action was needed. Thus, the industry came together and designed 802. Hi.

Security for 802.11

noreply@blogger.com (JohnJenin) — Sat, 19 Nov 2011 12:14:00 +0000

Security is a broad subject, and there is an entire chapter dedicated to the unique challenges with security for voice mobility later. But any component of voice mobility over Wi-Fi will require some use of 802.11's built-in encryption. Keep in mind that securing the wireless link is not only critical, but may be the only encryption used to prevent eavesdroppers from listening in on sensitive voice calls for many networks.

802.11 security has both a rich and somewhat checkered past. Because of the initial application of 802.11 to the home, and some critical mistakes by some of the original designers, 802.11 started out with inadequate protection for traffic. But thankfully, all Wi-Fi-certified devices today are required to support strong security mechanisms.

Nevertheless, administrators today do still need to keep in mind some of the older, less secure technologies—often because the mobile handset might not correctly support the latest security, and it may fall to you to figure out how to make an old handset work without compromising the security of the rest of the network.

A secure wireless network provides at least the following (borrowed from Chapter 8):

Confidentiality: No wireless device other than the intended recipient can decrypt the message.
Outsider Rejection: No wireless device other than a trusted sender can send a message correctly encrypted.
Authenticity and Forgery Protection: The recipient can prove who the original composer of the message is.
Integrity: The message cannot be modified by a third party without the message being detected as having been tampered with.
Replay Protection: A older but valid message cannot be resent by an attacker later, thus preventing attackers from replaying old transactions.

Some of these properties are contained in how the encryption keys get established or sent from device to device, and the rest are contained in how the actual encryption or decryption operates.

Collisions, Backoffs, and Retries

noreply@blogger.com (JohnJenin) — Wed, 16 Nov 2011 16:15:00 +0000

Multiple radios that are in range of each other and have data to transmit need to take turns. However, the particular flavor of 802.11 that is used in Wi-Fi devices does not provide for any collaboration between devices to ensure that two devices do take turns. Rather, a probabilistic scheme is used, to allow for radios to know nothing about each other at the most primitive level and yet be able to transmit.

This process is known as backing off, as is the basis of Carrier Sense Multiple Access with Collision Avoidance, or CSMA-CA. The process is somewhat involved, and is the subject of quite a bit of research, but the fundamentals are simple. Each radio that has something to send waits until the channel is free. If they then transmitted immediately, then if any two radios had data to transmit, they would transmit simultaneously, causing a collision, and a receiver would only pick up interference. Carrier sense before transmission helps avoid a radio transmitting only when another radio has been transmitting for a while. If two radios do decide to transmit at roughly the same time—within a few microseconds—then it would be impossible for the two to detect each other.

To partially avoid the collisions, each radio plays a particular well-scripted game. They each pick a random nonnegative integer less than a value known as the contention window (CW), a small power of 2. This value will tell the radio the number of slots, or fixed microsecond delays, that the radio must wait before they can transmit. The goal of the random selection is that, hopefully, each transmitter will pick a different value, and thus avoid collisions. When a radio is in the process of backing off, and another radio begins to transmit during a slot, the backing-off radio will stop counting slots, wait until the channel becomes free again, and then resume where it left off. That lets each radio take turns (see Figure 1).

Figure 1: The backoff procedure for two radios

However, nothing stops two radios from picking the same value, and thus colliding. When a collision occurs, the two transmitters find out not by being able to detect a collision as Ethernet does, but by not receiving the appropriate acknowledgments. This causes the unsuccessful transmitters to double their contention window, thus reducing the likelihood that the two colliders will pick the same backoff again. Backoffs do not grow unbounded: there is a maximum contention window. Furthermore, when a transmitter with an inflated contention window does successfully transmit a frame, or gives up trying to retransmit a frame, it resets its contention window back to the initial, minimum value. The key is to remember that the backoff mechanism applies to the retransmissions only for any one given frame. Once that frame either succeeds or exceeds its retransmission limit, the backoff state is forgotten and refreshed with the most aggressive minimums.

The slotted backoff scheme had its origin in the educational Hawaiian research network scheme known as Slotted ALOHA, an early network that addressed the problem of figuring out which of multiple devices should talk without using coordination such as that which token-based networks use. This scheme became the foundation of all contention-based network schemes, including Ethernet and Wi-Fi.

However, the way contention is implemented in 802.11 has a number of negative consequences. The denser and busier the network, the more likely that two radios will collide. For example, with a contention window of four, if five stations each have data, then a collision is assured. The idea of doubling contention windows is to exponentially grow the window, reducing the chance of collisions accordingly by making it large enough to handle the density. This would allow for the backoffs to adapt to the density and business of the network. However, once a radio either succeeds or fails miserably, it resets its contention window, forgetting all adaptation effects and increasing the chance of collisions dramatically.

Furthermore, there is a direct interplay between rate adaptation—where radios drop their data rates when there is loss, assuming that the loss is because the receiver is out of range and the transmitter's choice of data rate is too aggressive—and contention avoidance. Normally, most devices do not want to transmit data at the same time. However, the busier the channel is, the more likely that devices that get data to send at different times are forced to wait for the same opening, increasing the contention. As contention goes up, collisions go up, and rate adaptation falsely assumes that the loss is because of range issues and drops the data rate. Dropping the data rate increases the amount of time each frame stays on air—a 1Mbps data frame takes 300 times the amount of time a 300Mbps data frame of the same number of bytes takes—thus increasing the business of the channel. This becomes a vicious cycle, in a process known as congestion collapse that causes the network to spend an inordinate amount of time retransmitting old data and very little time transmitting new data. This is a major issue for voice mobility networks, because the rate of traffic does not change, no matter what the air is doing, and so a network that was provisioned with plenty of room left over can become extremely congested by passing over a very short tipping point.

Hidden Nodes | Wi-Fi's Approach to Wireless

noreply@blogger.com (JohnJenin) — Sat, 12 Nov 2011 09:13:00 +0000

Carrier sense lets the transmitter know if the channel near itself is clear. However, for one transmitter's wireless signal to be successfully received, the channel around the receiver must be clear—the transmitter's channel doesn't matter. The receiver's channel must be clear to prevent interference from multiple signals at the same time. However, the transmitter can successfully transmit with another signal in the air, because the two signals will pass through each other without harming the transmitter's signal.

So why does 802.11 require the transmitter to listen before sending? There is no way for the receiver to inform the transmitter of its channel conditions without itself transmitting. In networks that are physically very small—well under the range of Wi-Fi transmissions—the transmitter's own carrier sensing can be a good proxy for the receiver's state. Clearly, if the transmitter and receiver are immediately next to each other, the transmitter and receiver pretty much see the same channel. But as they separate, they experience different channel conditions. Far enough away, and the transmitter has no ability to sense if a third device is transmitting to or by the receiver at the same time. This is called the hidden node problem.

Figure 1 shows two transmitters and a receiver in between the two. The receiver can hear each transmitter equally, and if both transmitters are sending at the same time, the receiver will not be able to make out the two different signals and will receive interference only. Each transmitter will perform carrier sense to ensure that the channel around it is clear, but it won't matter, because the other transmitter is out of range. Hidden node problems generally appear this way, where the interfering transmitters are on the other side of the receiver, away from the transmitter in question.

Figure 1: Hidden Nodes: The receiver can hear both transmitters equally, but neither transmitter can hear the other

802.11 uses RTS/CTS as a partial solution. As mentioned when discussing the 802.11 protocol itself, a transmitter will first send an RTS, requesting from the receiver a clear channel for the entire length of the transmission. By itself, the RTS does not do anything for the transmitter or receiver, because the data frame that should have been sent would have the same effect, of silencing all other devices around the sender. However, what matters is what the receiver does. The CTS it sends will silence the devices on the far side from the sender, using the duration value and virtual carrier sense to cause those devices to not send, even though they cannot detect the following real data frame (seeFigure 2).

Figure 2: RTS/CTS for Hidden Nodes: The CTS silences the interfering devices

This is only a partial solution, as the RTSs themselves can get lost because of hidden nodes. The advantage of the RTS, however, is that it is usually somewhat shorter than the data frame or frames following. For the RTS/CTS protocol to be the most effective against hidden nodes, the RTS and CTS must go out at the lowest data rate. However, many devices send the RTSs at far higher rates. This is done mostly to just take advantage of RTSs determining whether the receiver is in range, and not to avoid hidden nodes.

Furthermore, the RTS/CTS protocol has a very high overhead, as many data packets could be sent in the time it takes for an RTS/CTS transmission to complete.

Clear Channel Assessment and Details on Carrier Sense

noreply@blogger.com (JohnJenin) — Sun, 06 Nov 2011 18:00:00 +0000

Now that we've covered the preamble, you can begin to understand what the term carrier sense would mean in wireless.

The term clear channel assessment (CCA) represents how a radio determines if the air is clear or occupied. Informally, this is referred to as carrier sense. As mentioned previously, transmitters are required to listen before they transmit, to determine whether someone else is also speaking, and thus to help avoid collisions.

When listening, the receiver has a number of tools to help discover if a transmission is under way. The most basic concept is that of energy detection. A radio can figure out whether there is energy in the channel by using a power meter. This power meter is usually the one responsible for determining the power level, often stated as the Receive Signal Strength Indication (RSSI) of a real signal. When applied to an unoccupied channel, the power meter will detect the noise floor, often around −95dBm, depending on the environment. However, when a transmission is starting, the power meter will detect the signal being sent, and the power level measured will jump—let's say, to −70dBm for this example. That difference of 25dB can be used by the radio to clue in that it should attempt to turn on its modem and seek out the preamble. This allows the radio to have its modem off until real signals come by.

Energy detection can be used as a form of carrier sense to trigger the CCA. When done that way, non-802.11 noise that crosses a certain threshold, determined by the radio, will show up as an occupied channel for as long as the noise is present. This allows the radio to avoid transmitting into a channel at the same time as interference is present. In the 2.4GHz band, microwave ovens can often trigger the energy detection thresholds on radios, causing the radios to stop transmitting at that time.

On the other hand, energy detection for CCA has its limitations. If the noise coming in is something that would not interfere with the transmission, but does trip the energy detection threshold, then airtime is being wasted. Therefore, the carrier acquisition portion of CCA comes into play. Radios know to look for specific bit patterns in a transmission, such as the preamble. When they detect these bit patterns, they can assert CCA as well. Or, more importantly, when they detect some energy in the channel but cannot detect these bit patterns, they can conclude that there is no legitimate 802.11 signal and suppress CCA.

Preambles | Wi-Fi's Approach to Wireless

noreply@blogger.com (JohnJenin) — Thu, 03 Nov 2011 07:30:00 +0000

Because 802.11 allows transmitters to choose from among multiple data rates, a receiver has to have a way of knowing what the data rate a given frame is being transmitted at. This information is conveyed within the preamble (see Figure 1).

Figure 1: 802.11 Preambles Illustrated

The preamble is sent in the first few microseconds of transmission for 802.11, and announces to all receivers that a valid 802.11 transmission is under way. The preamble depends on the radio type, but generally follows the principle of having a fixed, well-known pattern, followed by frame-specific information, then followed by the actual frame. The fixed pattern at the beginning lets the receiver train its radio to the incoming transmission. Without it, the radio might not be able to be trained to the signal until it is too late, thus missing the beginning of the frame. The training is required to allow the receiver to know where the divisions between bits are, as well as to adjust its filters to get the best version of the signal, with minimum distortion. The frame-specific information that is included with the preamble (or literally, the Physical Layer Convergence Procedure (PLCP) following the preamble, although the distinction is unnecessary for our purposes) names two very important properties of the frame: the data rate the frame will be sent at, and how long the frame will be.

All preambles are sent at the lowest rate the radio type supports. This ensures that no matter what the data rate of the packet, every radio that would be interfered with by the transmission will know a transmission is coming and how long the transmission will last. It also tells the receiver what data rate it should be looking for when the actual frame begins. All devices within range of the transmitter will hear the preamble, the length field, and the data rate. This range is fixed—because the preamble is sent at the lowest data rate in every case, the range is fixed to be that of the lowest data rate. Note that there is no way to change the data rate at which the preamble is sent. The standard intentionally defines it to be a fixed value—1Mbps for 802.11b, and 6Mbps for everything else.

When a radio hears a preamble with a given data rate mentioned, it will attempt to enable its modem to listen for that data rate only, until the length of the frame, as mentioned in the preamble, has concluded. If the receiver is in range of the transmitter, the modem will be able to properly detect the frame. If, however, the receiver is out of range, the receiver will hear garbage. The garbage will not pass the checksum (also garbage), and so will be discarded.

To prevent radios from interpreting noise as a preamble, and locking to the wrong data rate for a possibly very long length, the frame-specific information has its own checksum bit or bits, depending on the radio type. Only on rare occasions will the checksum bit fail and cause a false reception; thus, there is no concern for real deployments.

In summary, a receiver then works by first setting its radio to the lowest common denominator: the lowest data rate for the radio. If the fixed sequence of a preamble comes in, followed by the data rate and length, then the radio moves its modem up to the data rate of the frame and tries to gather the number of bits it calculates will be sent, from the length given. Once the amount of time necessary for the length of the frame has concluded, the radio then resets back to the lowest data rate and starts attempting to receive again.

Data Rates | Wi-Fi's Approach to Wireless

noreply@blogger.com (JohnJenin) — Sat, 29 Oct 2011 16:57:00 +0000

A data rate, in 802.11, is the rate of transmission, in megabits per second (Mbps) of the 802.11 header and body. The 802.11 MAC header, the body, and the checksum (but not the physical layer header) are transmitted at the same data rate within each frame.

A data rate represents a particular encoding scheme, or way of sending bits over the air. Each data rate can be thought of as coming from its own modem, designed just for that data rate. An 802.11 radio, then, can be thought of has having a number of different modems to chose from, one for each data rate. (In practice, modern radios use digital signal processing to do the modulation and demodulation, and therefore the choice of a modem is just the choice of an algorithm in microcode on the radio or software used to design the radio itself.)

Each data rate has its own tradeoff. The lowest data rates are very slow, but are designed with the highest robustness in mind, thus allowing the signal to be correctly received even if the channel is noisy or if the signal is weak or distorted. These data rates are very inefficient, in both time and spectrum. Packets sent at the lowest data rates can cause network disruption, as they occupy the air for many milliseconds at a time. Although one millisecond sounds like a short amount of time, if each packet were, say, ten milliseconds long, then the highest throughput an access point could get would be less than 1.2Mbps for 1500-byte packets.

The higher data rates trade robustness for speed, allowing them to achieve hundreds of megabits per second. The description of the 802.11 radio types will walk through the principles involved in packing more data in. Occasionally, someone may mention that this effect is related to Shannon's Law. Shannon's Law states that the maximum amount of information that can be transmitted in a channel increases logarithmically with the signal-to-noise ratio. The stronger the signal is than the noise floor, the faster the radio can transmit bits. Lower data rates do not take advantage of high SNRs as well as higher data rates do. As data rates go higher, the radios become increasingly optimistic about the channel conditions, trying to pack more bits by making use of the higher fidelity that is possible. That higher fidelity is held to a smaller distance from the radio, and so higher data rates travel less far. (But note that 802.11 uses a concept to ensure that every device within the longest range knows of a transmission, no matter what the data rate is.) Think of it as saying that the amount of available "space" in a channel is determined by the SNR. More SNR means that more bits can be packed, by reducing the "space" between bits. Of course, the smaller the "space" between bits, the harder it becomes to tell the bits apart.

Data rates in 802.11 refer to how fast the bits of the frame are transmitted over the air. Numbers as high as 300Mbps exist for the latest 11n devices. However, there is a significant gap between the data rate and the highest possible throughput that an application can see.

The main reason for this are that there is a tremendous amount of overhead in 802.11. Because each frame is preceded by a low-data rate header (the preamble), as well as mandatory random waiting times (the backoff), much of the airtime is spent in negotiating which device can transmit. This limits one-way traffic—such as UDP streams—to a significantly lower throughput than the data rate the frames are going at. The peak throughput varies significantly, depending on the vendors and products involved, but good rules of thumb are:

802.11b: 11 Mbps data rate → around 8Mbps UDP throughput
802.11a/g: 54Mbps data rate → around 35Mbps UDP throughput
802.11n: 300Mbps data rate → around 250Mbps UDP throughput

Furthermore, 802.11 is a half-duplex network, meaning that upstream and downstream traffic compete for the same airtime. Thus, TCP traffic, which must have one upstream packet (also called acknowledgments) for every two downstream data packets, has an even lower throughput, such as:

802.11b: 11Mbps data rate → around 6Mbps TCP throughput
802.11a/g: 54Mbps data rate → around 28Mbps TCP throughput
802.11n: 300Mbps data rate → around 190Mbps TCP throughput

RF Planning | RF Primer

noreply@blogger.com (JohnJenin) — Wed, 26 Oct 2011 13:52:00 +0000

RF planning is designed to address the two problems of multicellular networks. The first problem is to ensure that the coverage levels within the network are high enough that the expected data rates, based on the minimum required signal to noise ration, can be achieved at every useful square foot of the building or campus environment. The second problem is to avoid the intercell interference which results from multiple devices transmitting on the air without mitigation.

Proper RF planning is an expensive, time-consuming process. The basics of RF planning are for the installers to predict what the signal propagation properties will be in the expected environment. This sort of activity always requires using sophisticated RF prediction tools. RF prediction tools operate by requiring the operator to designate the locations and RF properties—attenuation, mostly—of each physical element in the building, the furniture, the walls, the floors, and the heavy machinery. Clearly a laborious process, the operator must copy in the location of these elements one at a time. Some tools are intelligent enough to take CAD drawings or floor-plan maps and estimate where the walls are, but an operator is required to verify that the guesses are not far from reality. RF planning tools then use RF calculations, based on electromagnetic principles, to determine how much the signal is diminished or attenuated by the environment. The planning tools need to know the transmit power capabilities and antenna gains of all of the access points that will be deployed in the network.

RF planning can be used this way to assist in determining where access points ought to be located, to maximize coverage given the particular SNR requirements. Because RF planning uses exact equations to predict the effects of the environment, it can be only as good as the information it is given. Operators must enter the exact RF and physical properties of the building to have a high likelihood of getting an accurate answer. For this reason, RF planning suffers from the garbage-in-garbage-out problem. If the operator has uncertainty about the makeup of the materials in the building, then the results of the RF plan share the same uncertainty.

Furthermore, RF planning cannot predict the effects of multipath. Multipath is more crucial than ever in wireless networking, because the latest Wi-Fi radios take advantage of that multipath to provide services and increase the data rate. Not being able to predict multipath places a burden on RF planning exercises, and requires RF planners to look for the worst-case scenarios.

Using RF planning tools to determine what power levels or channel settings each access point takes, then, is not likely to be a successful proposition as the network usage increases. Unfortunately, Wi-Fi self noise is a problem that does not show itself until the network is being heavily used, at which point it shows with vigor. Until then, as the network is just getting going, self noise will not be present at high levels and will not occupy 100% of the airtime. Thus, network administrators will see early successes with almost any positioning of Wi-Fi equipment, and can gain a false sense of security. (It is important to note that this is a property of trying to predict how RF propagates. Tools or infrastructure that constantly monitor and self-tune suffer the same problems, but with the added wrinkle that the self-tuning is disruptive, and yet will be triggered when the noise increases and the network needs to be disrupted the least.)

The one place where RF planning shows strength is in determining a rough approximation of the number and position of access points that are needed to cover a building. This does not require the sort of accuracy as complete RF plan, and tends to work well because of the fact that Wi-Fi networks are planned for a much higher minimum SNR than is necessary to cover the building. That higher SNR is required, however, to establish a solid data rate, and so what appears to be padding or overprovisioning from a coverage point of view can be lost capacity from a data rate point of view. Nonetheless, determining the rough number of access points needed for large deployments is a task that can do with some automation, and RF planning tools used only to plan for coverage (and not for interference), can be reasonably effective—even more so if the infrastructure that is deployed is able to tolerate the co-channel interference that is generated.