The Wi-Fi Break-Before-Make Handoff

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

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

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

1. Once a client has decided to hand off, it need not break the connection to the original access point, but it must not use it any longer.
2. The client has the option of sending a Disassociation message to the old access point, a good practice that lets the old access point free up network resources.
3. At this point, if the new access point is on a different channel, the client will change the channel of its receiver.
4. If the new channel is a DFS channel, the client is required to wait until it receives a beacon frame from the access point, unless it has recently heard one as a part of a passive scanning procedure.
5. The client will send an Authentication message to the new access point, establishing the beginnings of a relationship with this new access point, but not yet enabling data services.
6. The access point will respond with its own Authentication message, accepting the client. A rejection can occur if load balancing is enabled, and the access point decides that it is oversubscribed, or if key state tables in the access point are full.
7. The client will send a Reassociation Request message to the access point, requesting data services.
8. The access point will send a Reassociation Response message to the access point. If the message has a status code for success, the client is now associated with and connected to this access point, and only this access point. Controller-based wireless architectures will usually ensure this by immediately destroying any connection that may have been left over if step 2 has not been performed. The access point may reject the association if it is oversubscribed, or if the additional services the client requests (mostly security or quality-of-service) in the Reassociation Request will not be supported.
   At this point, the client is associated and data services are available. Usually, the access point or controller behind it will send a broadcast frame, spoofed to appear as if it were sent by the client, to the connected Ethernet switch, informing it of the client's presence on that particular link and not on any one that may have been used previously.
   If no security is employed, skip ahead to the admission control mechanisms, towards the end of the list. If PSK security is employed, skip ahead to the four-way handshake. Otherwise, if 802.1X and RADIUS authentication is employed (WPA/WPA2 Enterprise), we'll continue immediately next.
9. The access point and client can only exchange EAP messages at this point. The client may solicit the EAP exchange with an optional EAP Start message.
10. The access point will request the client to log in with an EAP Request Identity message.
11. Depending on the EAP method required by the RADIUS server on the network, the client and access point will continue to exchange a number of data frames, all EAPOL.
12. The access point relays the RADIUS server's EAP Success or EAP Failure message. If this is a failure, the access point will also likely send a Deauthentication or Disassociation message to the client, to kick it off of the access point.
    At this point, the client and access point have agreed on the pairwise master key (PMK), based on the key material generated during the RADIUS exchange and sent to the access point when the authentication process concluded. But, the access point and client still need to generate a per-connection, pairwise transient key (PTK), which will be used to do the actual encryption. Pre-shared key (PSK) networks skipped the listed EAP exchanges, and use the PSK as the master key.
13. The access point send the first message in the RSN (802. Hi) four-way handshake. This is an EAPOL Key frame.
14. The client sends the second message in the four-way handshake.
15. The access point sends the third message in the four-way handshake.
16. The client sends the fourth message in the four-way handshake.
    At this point, all data services are enabled, and the client and access point can exchange data frames. However, if a call is in progress, and WMM Admission Control is enabled, the client is required to request the voice resources before it can send or receive a single voice packet with priority. Until this point, both sides may either buffer the packets or send the voice packets as best-effort. 
17. The client sends the access point an ADDTS Request Action frame, with a TSPEC that specifies the over-the-air resources that both the upstream and downstream part of the voice call will occupy.
18. The access point weighs whether it has enough resources to accept or deny the request. It sends an ADDTS Response Action frame with the results.
19. If the request was successful, the client and access point will be sending voice traffic and the call successfully handed off. On the other hand, if the request fails, the client will disconnect from the access point with a Disassociation message, because, although it is allowed to remain on the access point, it can't send or receive any voice traffic.

Hopefully, everything went well and the handoff completed. On the other hand, if any of the processes failed, the connection is broken. The old connection was abandoned early on—in step 8 for sure and step 2 for more charitable clients. In order to not drop the phone call, the phone will need to restart the process from the beginning with another access point—perhaps the original access point it just left, if none is available.

You will notice that the client has a lot of work to do to make the handoff successful, and there are many places where the procedure can go wrong. Even if every request were to be accepted, any loss of some of the messages can cause long timeouts, often up to a second, as each side waits to make sure that no messages are passing each other by.

If nothing at all is done to optimize this transition, the handoff mechanics can take an additional second or two, on top of the second or so taken by the scanning process before the handoff decision was made. In the worst case, the 802.1X communication can take a number of seconds.

Part of the issue is that the mechanisms are nearly the same for a handoff as they are for when the client initially connects. This lack of memory within the network within basic Wi-Fi prevents any optimizations and requires a fresh start each time.

802.1X | Wi-Fi Radio Types

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.

Wi-Fi Link Security

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

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.

RSNA with 802.11i | Wi-Fi Security Technologies

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

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.

Clear Channel Assessment and Details on Carrier Sense

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

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.

Clients | Basics of Wi-Fi

A client is the typical end-user device. Unlike access points, which are strategically placed for coverage, clients are almost always mobile (or potentially so).

Wi-Fi clients can be general networking interface devices, such as those in laptops, or can be part of a purpose-built mobile voice handset. Either way, these clients appear to the network as endpoints, just as Ethernet devices do.

From the user's perspective, however, Wi-Fi clients add an extra complication. Unlike with wireline connections, where the user is assigned a port or cable and has the expectation that everything will work once the cable is plugged in and the process has settled down (which, for administrators, generally means that Dynamic Host Configuration Protocol (DHCP) automatic IP address discovery has completed), wireless connections have no one cable to solve all problems. The user must be involved in the connection process, even when the reason for connection or disconnection is not readily apparent. As mentioned previously, the user must learn about SSIDs. When a wireless interface is enabled, the user is normally interrupted with a list of the available networks to connect to. Knowing the right answer to this question requires an unfortunate amount of sophistication from the user, not because the user does not understand the technology, but because they usually do understand the power of mobility, and have learned to strategically hunt out wireless networks for casual email access. This is clearly evidenced by the pervasive nature of the "Free Public WiFi" ad hoc (Independent Basic Service Set, or IBSS) SSID that tends to be on so many laptops.

Ultimately, the user is responsible for knowing what the appropriate network is to connect to at any given location. Most devices do remember previous connections—including authentication credentials, in many cases—and can make the connection appear to be automatic. However, because of that caching, installations that run multiple SSIDs are often forced to deal with users not knowing exactly which network they are connected to.

Once the connection is established, the interface comes up much as a plugged-in Ethernet link does. Any automatic services, such as DHCP or Universal Plug and Play (UPnP), that run on interface startup will get kicked off, and the users will be able to communicate as if they had plugged directly into the network.

The last wrinkle comes, however, with mobility. Once the user leaves the coverage range of the one access point that it is on, the client will perform its list gathering activity (scanning) again. If it can find an SSID that it already has in its list—especially if the SSID is the same as the one the client was already associated to—the client will try to hand over to the new access point without user intervention. However, if the handoff does not succeed, or there are no more known networks in range, the client will disconnect and either warn the user with a popup or just break the connection without warning. This can come as quite a shock to the user, and can lend negative impressions about the network.

Access Points | Basics of Wi-Fi

The access point (abbreviated as "AP"; see Figure 1) serves as the base station. The concept is common, from cordless phones to the large wireless carriers: the access point is what provides the "network," and the clients connect to it to gain access. Each Wi-Fi radio, whether it be in the access point or the client, is designed to send its wireless signals across a limited range, far enough to be useful but not so far as to violate the limits set by the regulations and to grossly exceed the bounds of the building the network is deployed within. This range is in the order of 100 feet, though. To set apart which device connects to the network, the access point must take on a role as some sort of master.

 

Figure 1: A typical Access Point

An access point often looks like a small brick, but with antennas and an Ethernet cable. The Ethernet cable provides the connection to the wired network, and, if power over Ethernet (PoE) is in use, the access point receives its power over the same cable. Access points are normally independent physical devices. Commonly, they are placed along walls, or above or below a false ceiling, to provide the maximal amount of wireless coverage with the least amount of physical impediments to the signals (see Figure 2). 

 Figure 2: Typical Access Point mounting locations

Access points make their networks known by sending frequent wireless transmissions, known as beacons. These beacons describe to the client devices what capabilities the access point has, and most importantly, what network the access point is providing access to. The way the network is designated is by an arbitrary text string provided by the administrator, known as a service set identifier (SSID). This text string is sent in the beacons, and other transmissions, to the clients, which then provide a list of SSIDs seen to the user. Thus, when the user brings up a list of the networks that his or her laptop sees and can connect to, the list contains the SSIDs of the access points.

Because the SSID is the only way users can select which network they wants to connect to, we need to look into it a bit deeper. There are very few technical restrictions on the SSIDs except for the length, which must be less than 32 characters. However, the SSID needs to be meaningful to the user, or else he or she will not connect to it. Because SSIDs are supposed to name the network that the user is connecting to, rather than the individual access point, multiple access points can and do share the same SSID. That being said, there is nothing stopping someone else from giving an access point the SSID that belongs to your network. There is no security in the SSID itself. Eavesdroppers can trivially discover what the SSID is that your network is using (even if you use a feature known as SSID hiding or SSID broadcast suppression) and use it to either gain entry into your network or spoof your network and try to fraudulently get your clients to connect to them instead. In fact, there is nothing that prevents SSIDs from being used for nearly any purpose at all. Most of what applies to SSIDs are in the form of best practices, of which the important ones are:

• The SSID should be meaningful to the user: "employees" and "guest" are good examples of meaningful names. They may be based on the role of the user, the device the user has (such as "voice" for phones), or any other words that help the user find the network.
• When the installation shares the air with neighboring networks from other organizations, the SSID should also include text to highlight to the user what the right network is; "xyz-employees" is an example of an SSID for an organization named XYZ.
• The SSID should be able to be easily typed by the user. Although most devices show SSIDs in a list from what already are being broadcasted, allowing the user to select the SSID with minimal effort, there are many occasions on which when the user may need to type the SSID. This is especially true for mobile devices, with small keyboards or limited keys.
• Again, do not rely on obscurity of the SSID to restrict access to your network. Use real security mechanisms, as described later, instead.

Devices | Advantages of Wi-Fi

Wi-Fi was initially thought of as a data network only. Partially, this was because of an attempt to avoid the bad image that cordless phones also projected, as users were far too used to static and interference on cordless phones. But mostly, the original iterations of Wi-Fi occurred when Wi-Fi itself was struggling to find a place, and allowing users to check email or surf the Web while moving from room to room seemed to be enough of an application to motivate the fledgling industry.

But when mobile data networking took off, and people became addicted to remote email over the cellular network, the seeds were sown for device vendors to want to integrate Wi-Fi into their mobile devices. And because those devices are primarily phones, the connection of mobility to voice over Wi-Fi was natural.

Broadly, there are two categories of voice mobility devices that use Wi-Fi as a connection method. The first are Wi-Fi-only devices. These devices are often dedicated for a specific application in mind. For example, Vocera Communications makes a Wi-Fi-based communicator that is often used in hospitals to allow doctors and nurses to communicate with each other using voice recognition, rather than a keypad, to determine whom to call.

This device looks and acts more like a Star Trek communicator than a phone, but is an excellent example of voice mobility within a campus. Polycom, through its SpectraLink division, Cisco, and Ascom all make handsets that look more like a traditional mobile phone. In all of these cases, single-mode networking—using just Wi-Fi, in these examples, as the only means of connectivity—makes sense for the environment and the application.

The second type is made of mixed-mode, or integrated devices. These devices are mobile phones, made to be used with the cellular network as well as Wi-Fi. Nearly every mobile handset manufacturer is selling or is planning on selling such a device, including Research in Motion, Nokia, Samsung, and Apple with its iPhone. These devices can be made to place voice calls directly over the Wi-Fi network, rather than the cellular network, thus unlocking the entire fixed-mobile convergence (FMC) industry.

In both cases, the push from Wi-Fi networks originally designed for data allows for voice to become a leading, if not the dominating, purpose for many networks, as the maturity and variety of Wi-Fi-enabled voice devices make voice mobility over Wi-Fi possible.

Universal Presence | Advantages of Wi-Fi

Even though the focus—and of so many people—is with enterprise and large-scale deployments, in explaining what makes Wi-Fi compelling, we must not lose track of the consumer, and how consumer demands have pushed the entire Wi-Fi industry forward, inevitably benefiting the enterprise.

The major contribution the consumer space has given Wi-Fi is that is has driven people to demand wireless. Three historic events changed the landscape of mobility and connectivity: the Internet moved into the home; laptops replaced desktops and were being issued by corporate IT for usage everywhere; and darkly roasted coffee came onto the scene. Or rather, for the last one, people began to find reasons to want to work and live outside of the home and office. All three demanded a simpler solution than having to drag oversized telephone cables around with each user. And that gap was filled with Wi-Fi.

Wi-Fi is now in many places that mobile users are expected to show up in. In the home, it is difficult now to find a consumer-level gateway that does not include wireless. Just as television once was the centerpiece of the living room, but contention over control of the remote and the drop in prices lead televisions to spring up in nearly every room of the house, the Internet has migrated from being connected to one prized home computer in the living room to being spread throughout the house by Wi-Fi. In the enterprise, the advantages of unwiring the network edge has lead to IT organizations peppering the office with access points. And on the road, hotels, airports, cafes, and even sporting arenas have outfitted with Wi-Fi, to try to encourage their customers to get back with their online selves as often as possible, and maybe make each one be a little more "sticky" in the meanwhile.

What this means for voice mobility is that the cycle of demand drives the technology to get ever better. Consumers' demand and expectations "pull" advanced wireless into the home, just as enterprises "push" laptops onto their employees, encouraging them to be used outside the office, therefore increasing the number of hours employees think and do their work far beyond the amount of time each employee spends in the office.

And with this cycle of demand also comes maturity of the underlying technology. Wi-Fi has gone through a number of iterations, getting faster, more powerful, and less prone to mistakes. Now, it is nearly impossible to find laptops without wireless built in. It is even an option on many desktop systems, not considered to be traditionally mobile, yet eager to be joined in on the wireless bandwagon to help company's save on cabling costs.

Unlicensed Spectrum | Advantages of Wi-Fi

Generally, the ability to transmit radio signals over the air is tightly regulated. Government bodies, such as the U.S. Federal Communications Commission (FCC), determine what technologies can be used to transmit over the air and who is allowed to operate those technologies (see Figure 1). They do this latter part by issuing licenses, usually for money, to organizations interested in transmitting wirelessly. These licenses, which are often hard to obtain, are required in part to prevent multiple network operators from interfering with each other.

 

Figure 1: The United States Spectrum Allocation. Wi-Fi operates in the circled bands

The advantage of Wi-Fi, over other wireless technologies such as WiMAX (which we will cover in Chapter 7), is that no licenses are needed to set up and operate a Wi-Fi network. All that it takes to become a network operator is to buy the equipment and plug it in.

Clearly, the array of allocations within the spectrum is bewildering. And network operators for licensed wireless technologies must be aware of the rules for at least the part of the spectrum that their technology works in, to avoid violating the terms of the license. But, thankfully, all of this is taken care of automatically when 802.11 technology is used. Wi-Fi operates in two separate stretches (or "bands") of the radio spectrum, known in the United States as the Industrial, Scientific, and Medical (ISM) bands, and the Unlicensed National Information Infrastructure (U-NII) bands. These bands have a long history, and it is no coincidence that voice lead the way. Many people first became familiar with the concept of unlicensed radio transmissions when 900MHz cordless telephones were introduced. These phones require no licenses, but have a limited range and do only one thing—connect the call back to the one and only one base station. However, the power from using wireless to avoid having to snake cables throughout the house and allowing callers to walk from room to room revealed the real promise of wireless and mobility.

For enterprises, the benefits of the freedom from using unlicensed spectrum are clear. Removing the regulatory hurdles from wireless brings the requirements for setting up wireless networks down to the same level as for wireline networks. Expanding the network, or changing how it is configured, requires no permission from outside authorities (ignoring the physical requirements such as building codes necessary to pull cables). There is no concern that a regulatory agency might reject a Wi-Fi network because of too many neighboring allocations. Enterprises gain complete control of their air, to deploy it how they see fit.

Because being unlicensed gave the potential for every user to be her own network operator, wireless networking settled into the hands of the consumer, and that is where we will continue the story.