This chapter provides an overview of how the IEEE 802.11 protocol operates. You may feel that understanding the way in which low-level messages are exchanged is not relevant to understanding security. If you are concerned only with setting up a secure network following the configuration instructions in the manual, you are probably right. But one purpose of this book is to explain the new security system of IEEE 802.11 in sufficient detail that you become convinced that it really has been well thought out and is thoroughly secure. Accepting that systems are secure on face value is less work but sometimes leads to disappointment. To understand the later sections of this book, you need a grounding in the basic standard. Hopefully just enough of that grounding is provided here, but not too much.
The connection between the user and the LAN is a sequence of hardware and software components, each connected through a clearly defined interface. It's useful to think of this like a very efficient government organization that goes into operation when you, the user, fill out a form for some service and hand it in. Unlike a real government organization where your application form gets used as a coffee mat for a few weeks before falling behind the photocopier, in this super efficient service, the form passes from department to department and is rapidly processed by each before being handing on to the next. Within milliseconds, your service request is satisfied or rejected.
In a computer network layers implement this department concept. Each layer performs a particular function and is responsible for certain activities. The layers close to the user are called upper layers and the layers down by the LAN are called lower layers. Most engineering students are taught about the ISO seven-layer model in which the layers are defined with particular names and meanings. We don't propose to reiterate the complete model here, partly because it is boring and partly because few practical implementations really follow it in its entirety. However, we will look at the layers of a typical real system (Davie et al., 1999).
At the top is the user—the person sitting at a terminal and hoping to get service (such as read a document from a server or copy a file). To do this, the user interacts with an application program such as Microsoft Internet Explorer. Let's look at the sequence of events required to access a remote file, as shown in Figure 5.1:
When the application is asked to open a file, it requests the service of a file subsystem that understands directory structures and server names.
If the requested file is on a network server, the file subsystem needs to talk to that server and requests the services of the network operating system to determine what type of network protocol is needed.
The network operating system forwards a message to the remote server and asks the appropriate protocol layer, such as TCP/IP, to deliver it.
The network protocol layer packages the message in the appropriate format and generates multiple packets of data, each usually about 100–1,500 bytes in length. Then the protocol layer asks the link layer to deliver the packets.
The link layer uses the services of low-level hardware and software to transport a single packet of data across a single link, which could be an Ethernet link or a wireless LAN link.
The physical layer is the actual electrical signals or radio waves that transfer the data in the appropriate form for the medium being used.
Message replies that arrive follow a similar path (but of course in reverse).
The notable thing about this sequence is the way in which each layer does its job: no more and no less. The link layer just delivers packets. It doesn't care what they contain or where they are eventually headed. It has to get it from here to there and if there is a dead end—well, that's someone else's problem. It's like the truck driver who delivers the elephant to the nunnery at 23 Main St. “That's the address on my form so that's where Jumbo gets off.” The fact that there is a zoo at 32 Main St. is not in any way relevant to the truck driver.
When we talk about “wireless LAN,” we are generally referring to the link and physical layers of the network. The IEEE 802 standards deal with these layers for a range of different LAN technologies, including IEEE 802.3, which is commonly (but incorrectly) called “Ethernet” [IEEE 802.3]. IEEE 802.11, of course, is the very widely deployed standard for Wi-Fi wireless LAN. In most LAN technologies, the same type of LAN must exist at both ends of a link. In other words, an Ethernet cable connects an Ethernet port on a computer to an Ethernet port on a hub. The equivalent to the LAN hub in IEEE 802.11 is the access point, which acts like the center of a wheel in distributing data for most Wi-Fi LANs. When IEEE 802.11 systems work through an access point, they are said to be operating in infrastructure mode because the access point is coordinating the Wi-Fi LAN from a fixed point and often providing a connection to a wired Ethernet network.
In the early days of Ethernet, you could use a hub (like all systems today) or you could connect all the computers together using a single coaxial cable. In the latter case, you didn't need a hub because the single cable joined all the computers together in series. When any computer sent a message, all the others could potentially receive it, but only the recipient to whom it was addressed would actually listen. IEEE 802.11 has a similar mode called ad-hoc mode. In this case no access point is needed and each wireless device can transmit directly to any other. It was intended to be useful for groups of people who wanted to set up a network anywhere and share information—hence, “ad-hoc.”
To summarize, IEEE 802.11 has two modes, infrastructure and ad-hoc, sometimes referred to by the technical acronyms ESS and IBSS, respectively. From a security standpoint, ad-hoc networks present quite a challenge and we will deal with them separately in a later chapter. Most people operate in infrastructure mode because they want to be able to connect to a wired infrastructure such as a local Ethernet or an Internet connection. Infrastructure mode also offers a much better platform for building security. Most of what is described in the following chapters refers to operation in infrastructure mode.
In the following discussion AP is the acronym for a fixed access point and STA (short for “station”) refers to the wireless device, such as a laptop computer, that wants to connect to the network. The AP and STA talk to each other using wireless messages. We will assume that the AP is connected to a wired network that the STA wants to access.
To help understand the process by which the STA connects to the AP and starts to send data, we'll run through a simplified overview first. This describes the sequence of events that occur in systems that are not using security. Let's assume that the AP is already turned on and operating. The AP advertises its presence by transmitting short wireless messages at a regular interval, usually about 10 times a second. These short messages are called beacons and allow wireless devices to discover the identity of the AP.
Now suppose that someone powers up a laptop with a Wi-Fi network adapter installed (the STA). After the initialization phase, the STA will start to search for an AP. It may have been configured to look for a particular AP, or it may be prepared to connect to any AP, regardless of identity. There are a number of different radio frequencies (called channels) that could be used so the STA must tune into each channel in turn and listen for beacon messages. This process is called scanning. The process can be accelerated by probing, as explained later in this chapter.
The STA may discover several APs in a large network and must decide to which it intends to connect; often this decision is made based on signal strength. When the STA is ready to connect to the AP, it first sends an authenticate request message to the AP. The original IEEE 802.11 standard defined the authenticate messages as part of the security solution, but they are not used for this purpose in Wi-Fi (for reasons why, see Chapter 6). Because, in our scenario, we are not using security, the AP immediately responds to the authenticate request by sending an authenticate response indicating acceptance.
Now that the STA has permission to connect to the AP, it must take one more step before the connection is complete. In IEEE 802.11 the concept of “connection” is called association. When an STA is associated with an AP, it is eligible to send data to and receive data from the network.[1] The STA sends an association request message and the AP replies with an association response indicating successful connection. After this point, data sent from the STA to the AP is forwarded onto the wired LAN to which the AP is connected. Similarly, data from the wired LAN intended for delivery to the STA is forwarded by the AP.
This overview scenario describes the sequence of events by which an STA joins a network. Many details have been left out in the interests of simplicity. Some of the details are brought out in the rest of this chapter.
In IEEE 802.11 there are three types of messages:
Control: These are short messages that tell devices when to start and stop transmitting and whether there has been a communication failure.
Management: These are messages that the STA and AP use to negotiate and control their relationship. For example an STA uses a management message to request access to the AP.
Data: Once the STA and AP have agreed to connect, data is sent using this type of message.
We won't discuss control messages in detail here, but management messages are important for you to understand the process of connecting to a Wi-Fi LAN. The rest of this section describes the management messages and the processes they support.
Beaconing is the method by which the access point tells the world it is ready for action and maintains timing in the network. Beacons are management frames that are regularly sent out by the AP, typically about ten times a second. The beacon contains useful information such as the network name and the capabilities of the AP. For example, the beacon can tell the STA whether the AP supports the new security provisions of the IEEE 802.11 standard.
When a station turns on, it can listen for beacons, hoping to find an access point with which to connect. You might think that ten beacons a second would be plenty for the STA to find the right access point quickly. However, remember that there are multiple frequency channels and that if the STA has to go to each frequency and wait for 0.1 seconds, it could take a while to complete the scan (in other words, the search all the channels). Furthermore, if you are already connected and want to find a new access point because your signal strength is getting weak, you must find the new access point very rapidly to avoid disruption. For this reason, the STA has the option to send a probe request message. This is basically the equivalent of shouting “hello, anyone there?” when entering a dark cave. If any access points receive the probe request, they immediately reply with a probe response that looks essentially like a beacon message. In this way, an STA can rapidly learn about the access points in its area.
Remember that the process of connecting to an AP is called association. When you want to connect, you send an association request; the access point may reply with an association response. If that response is positive, you are now associated with the access point.
If there are multiple access points on the same network, your STA might choose to move its association from the current AP to a new one. First it should disconnect from the old AP using a disassociation message. Then it connects to the new AP using a reassociation message. The reassociation message has some information about the old AP that can be useful to make the handover smoother. The information allows the new AP to talk to the old AP to confirm that the roam has taken place.
Once you are associated and after authentication has been performed, you can start sending data. In most cases data is exchanged between the STA and the AP. In fact, this is the normal method even if you are sending data to another STA. First, you send to the AP and then you allow the AP to forward to the STA. Often data will go to the AP and then be forwarded on to an Ethernet LAN or to an Internet gateway. To facilitate this, each IEEE 802.11 data frame going to or from the AP has three addresses. Two may be considered the “final” source and destination, and the third is the “intermediate” address—that of the access point through which the message passes.
When you are sending from the STA to the AP, there is one source address—that of the STA that sent the message—and two destination addresses. One destination address specifies the AP and the other specifies the eventual destination for the message. Similarly data from the access point to the STA has one destination address (the STA) and two source addresses—the AP and also the originator of the message.
It is not our intent in this book to present the details of how IEEE 802.11 MAC[2] protocol works. The basic operating concept is simple, as described in the previous paragraphs. However, the numerous control mechanisms for dealing with different speeds, power saving, priority of service, and retransmission run into hundreds of pages. If you are really interested in those details, there are books[3] specializing on the MAC protocol and the physical layer interfaces (in other words, the radio and modem). Much of the cleverness of the standard is in how it coordinates multiple wireless devices so they can share the available radio bandwidth and not spend all their time colliding and transmitting over the top of each other.
This book naturally focuses on the security protocols that have been built into IEEE 802.11. These security protocols have been added in two stages. The first stage was incorporated in 1997 with the introduction of the first standard. The second stage, the so-called robust security network (RSN), was developed during 2001–2003. In fact, the two approaches are quite different and require separate descriptions. However, they both depend on some features of the main IEEE 802.11 protocol that we describe here. Let's look at these details now so the explanation of the security protocol makes sense later.
Every transmission over the wireless medium has a similar form, as shown in Figure 5.2. First a special pattern is sent out called the preamble, which the receivers on other Wi-Fi LAN devices can identify as IEEE 802.11. By the end of the preamble, which only lasts a few microseconds, all the receivers in range should have locked on and adjusted themselves to interpret the data that is to follow. The next part of the transmission is called the PLCP header. PLCP stands for Physical Layer Convergence Protocol, a fact that we invite you to forget immediately because it is of no importance to security. Suffice it to say that this header contains information relevant to the receiver logic, such as the data rate of the remaining part of the frame and the packet length. Following the PLCP header is the MAC header, followed by the user data and a cyclic redundancy check (CRC) to detect errors. It is the portion starting with the MAC header in which we are most interested.
The MAC header comes in three basic flavors, depending on whether the information is a control frame, a management frame, or a data frame. The most important part of the MAC header is the addressing information. The MAC header contains the source and destination addresses to allow delivery of the frame to the correct device. As is standard for IEEE LANs, these addresses are 6 bytes (48 bits) long, and each device has a unique address assigned during manufacture. The destination address can be unicast, which means it must be delivered to a single device (with the matching address); or it can be multicast, which means that it may be delivered to several devices or possibly all devices in range. It is important to remember this concept because it has a profound impact on security. So let's restate:
Unicast address: Deliver to one device
Multicast address: Deliver to several devices
Broadcast address: Deliver to all devices (special case of multicast)
Other IEEE 802 LANs also use MAC headers, although each has its own format. For example, IEEE 802.3 (Ethernet) MAC headers are quite simple and have just two addresses and a field to indicate the length of the data. IEEE 802.11 MAC headers are much more complicated and have many fields used in coordinating the Wi-Fi LAN. The MAC header of an IEEE 802.11 frame can have from two addresses to four addresses, depending on the situation. Conceptually the four addresses are:
Transmitter address (TA): The transmitting device
Receiver address (RA): The receiving device
Source address (SA): The device that created the original message
Destination address (DA): The device that eventually receives the message
A moment's thought shows why you might need different combinations. In an ad-hoc network (no AP), the devices send messages directly from one to another. In this case the device that creates the message is also the device that sends it. Similarly, the device that receives the message is also the one that processes it. So in ad-hoc frames, only two addresses are contained in the MAC header.
In an infrastructure network where an access point is operating, all the mobile devices send their frames to the AP, which then forwards them to the correct destination. In this case the mobile device creates and sends the messages; the access point receives them but is not the final destination. Therefore, three addresses are needed:
Mobile device address (source and transmitter: SA = TA)
Access point address (receiver: RA)
Eventual destination (DA)
When messages are going the other way (from the AP to the mobile device), the three addresses are:
Originating device address (source: SA)
Access point address (transmitter: TA)
Mobile device address (receiver: RA and DA)
In principle, all four addresses are used when one access point talks wirelessly to another access point.[4] However, this mode of operation is not fully specified in the standard and the few implementations that exist are usually proprietary to each manufacturer.
MAC addresses are relevant to security because, although the rules say that every device has a unique address, it is easy for enemies to break the rules and pretend to be someone else by copying their address. This is a classic hijack attack in which the enemy allows a legitimate device to establish a connection and then takes over the connection by masquerading as that station. Another problem with MAC addresses from a security standpoint is that they have to be visible to the outside world in order to have any meaning. Think of posting a secret letter. You can use whatever code you like in the letter; but if you also use a secret code for the address on the front of the envelope, the postal service isn't going to be impressed and isn't going to deliver it. The problem with public disclosure of your MAC address is that, in principle, someone can track where you go and where you log on even if he can't see what you are saying.
Apart from the addresses, the MAC header contains quite a lot of information related to efficient operation of the Wi-Fi LAN. Most of this is not relevant to security except that it may need to be protected from malicious modification. In the future, for a wireless LAN operating to the proposed IEEE 802.11e approach, the MAC header may also contain information to identify the type of data and the priority with which it should be handled.
Remember that there are three categories of MAC frame: control, management, and data. The control frames are very short and perform functions like acknowledgment and polling. The data frames have a simple format, as shown in Figure 5.2. The user data section carries data that came from a higher layer. The management frames deserve a little more scrutiny because these are involved in the security protocol.
The original 1997 standard listed the following management frames for use in infrastructure mode:
Beacon (notify)
Probe (request and response)
Authenticate (request and response)
Associate (request and response)
Reassociate (request and response)
Dissassociate (notify)
Deauthenticate (notify)
In this list, notify means “sent out but no response is expected.”
The body of a management frame comprises two parts. The first part is a set of fixed fields appropriate to the type of management frame. The second part contains elements. An element is a self-contained packet of information that may (or may not) be relevant to the receiving device. There may be a number of elements added to the fixed portion of the management message, as shown in Figure 5.3.
The fixed field contains various items of information specific to particular types of management frames. This includes, for example, flag bits that indicate whether optional features are active. Including in the fixed field area information for options that are not selected would be inefficient; instead, the fixed field just indicates whether the option is used and an appropriate element is added. The use of elements is a powerful and flexible idea with several benefits:
The use of elements has allowed the standard to be updated more easily. For example, information required for operating the new security methods can be put into elements. The advantage is that old systems that do not understand the new elements can simply ignore them. If the format of the fixed fields had been changed, the old system would be quite incompatible.
Individual manufacturers sometimes take advantage of the extendibility to add elements specific to some special feature that they provide (although this is not really allowed by the standard). For example, many systems add a proprietary element in beacons that indicates, to their own brand of mobile device, how busy the access point is. This allows a feature called load balancing in which the mobile stations distribute themselves evenly across all the access points. Of course, this arrangement doesn't help mobile stations that are made by a different company than the access point because they will not understand the proprietary element and just throw it away. However, the inability to understand proprietary elements does not prevent standard operation.
Each element has a similar structure. The first byte identifies the type of element. The second byte indicates the length: how many bytes are in the element and the information in the bytes that follow. Because the type and length come first, the receiver can skip over the element if it doesn't recognize or understand the type number.
We'll get into more detail on management frames later when we look at the way the security protocols operate; but for now, let's take a quick look at beacon frames. Actually there are several variants depending on the type of wireless LAN you use, but we'll look at the most common one: IEEE 802.11b (Wi-Fi) in infrastructure mode. This beacon has three fixed fields followed by several elements, generally at least four.
The sequence of fields in a normal beacon is shown in Table 5.1. Remember that beacons are sent out by access points to advertise themselves. The information is used in two ways. First, beacons are used to locate access points with the right network name (SSID) and suitable capabilities. Then, after association, the beacons are used to let the attached devices know that the access point is still operating and in range and also to coordinate certain operations such as power save mode. Let's review each field individually:
This field is initialized when the AP first starts and keeps going up in microseconds. The field is 64 bits long, which means, amazingly, that even counting up once per microsecond, it would take over half a million years to overflow! The value is used by all the attached devices to synchronize their operation.
This field tells everybody when the next beacon is expected to follow. The usual default for beacon interval is around 0.1 second.
This field identifies whether the AP supports various optional features. The original standard only had five bits defined; but as more and more features have been added to the standard, the number has increased dramatically. This field is important to security because it allows the access point to advertise that it supports the new RSN operation.
The SSID (or network name) gives the identity of the network to prospective wireless devices. There is no security in this—any rogue access point can advertise your SSID and most wireless devices have an option to allow use of any and all SSIDs they find in an area. When there are several Wi-Fi LANs operating in the same space, SSID helps you to choose which one to join. Do not labor under the misconception that choosing an unusual SSID provides some sort of security. This is absolutely not the case.
This element indicates what speeds the access point can support. For example, an old access point might only support rates of 1 or 2Mbps. An IEEE 802.11b access point supports 1, 2, 5.5, or 11Mbps; and an IEEE 802.11g access point rates up to 54Mbps. An IEEE 802.11g device will prefer to associate to an AP that could support its highest data rate so this information is needed in advance. Note that because this is an element and not a fixed field, it can be extended in the future.
This element indicates the radio frequency that is being used by the access point. You might think that if you were able to receive the message in the first place, you must know which frequency you have selected. However, in some cases it is possible to be on a nearby frequency and still receive a message from an adjacent channel (although poorly). The effect is similar to hearing a noisy distorted version of a nearby FM radio station when you are not quite tuned in.
These flags are used to tell sleepy wireless devices that there is data waiting for them. Power-saving devices turn off between beacons and then wake up to check these flags. If there is no flag set for them, and they have nothing they want to send, they can go back to sleep until the next beacon.
It is really important to remember that many new elements have been added over the years as the standard has developed. The ones shown in Table 5.1 are just those in the original standard. When we look in detail at the security protocol, you will see that security-related information is added using elements
This section has been left until last because it is really not relevant to security at all. In fact, if your only interest is security, skip to the next section. However, a brief overview of the radio side seems relevant to a book focused on wireless LANs. We have seen that the MAC layer produces a frame of data that it desires to be transmitted over the radio waves. From the point of view of the radio, this is just a long stream of bits. It is the job of the radio to take the bits and generate a few electromagnetic waves that can be picked up somewhere else and converted back to the same bits. Simple, huh? Well, actually, no.
Currently (in other words, as of 2003), there are two frequency bands that are available for sending IEEE 802.11 data; these are referred to as the 2.4GHz band and the 5GHz band. Band allocation is a very complicated area because governments jealously guard and control the use of radio spectrum, especially after they discovered the value of spectrum auctions in the late 1990s. Different countries and regions of the world have different rules, and we could easily fill a book on this topic alone. Here we will limit ourselves to observing that these two bands exist and, at any point in time, your radio operates in one or the other.
Having determined the radio spectrum that is available, the designer needs to figure out how to convert the digital bits into a high-frequency analog signal that can be amplified into an antenna to generate electromagnetic waves. Converting from bits to analog is the same task that a regular telephone modem performs—and, in fact, the portion of the radio that converts bits into analog is called the modem. The radio can be considered as two bits. The first part contains the modem, sometimes called the baseband section, and the second part contains all the very high frequency electronics to drive the antenna, usually called the radio frequency (RF) section. RF design is very specialized, and we salute the designers and discuss no further. The MODEM deserves more of a look.
Remember that the object is to convert digital bits into analog signals. One of the simplest modem techniques is called frequency shift keying (FSK): Send one frequency for a 0 bit and another for a 1 bit. You could use such a scheme to send Morse code for example—if you only needed a few bits a second! Having invented our first simple scheme, now apply 50 years of research and stir in a large consignment of top-quality gray matter and you might arrive at the very sophisticated techniques used in today's wireless LANs, such as orthogonal frequency division multiplexing (OFDM) and convolutional coding.
According to natural laws, there is a limit to how much information can be sent in a given amount of radio bandwidth. Furthermore, as you increase the information rate toward the theoretical limit, you become more susceptible to corruption by random noise. The sophisticated mathematical techniques that have been applied to wireless LAN are designed to get the optimum balance between high data rate and range. Put the data rate too high and you are susceptible to noise—hence the range becomes too short. But use the right mathematical technique, and you can increase the data rate without sacrificing range.
Improvements in modem techniques (and some changes to the regulations) have resulted in successive versions of IEEE 802.11 offering higher speed. The original 1997 standard only provided 2Mbps in the 2.4GHz band. IEEE 802.11a allowed an immediate leap to 54Mps in the 5GHz band, partly due to better modem technology and partly due to more available spectrum. However, 802.11a implementation was not practical at the time the standard was completed and product didn't appear until 2002. In 1999, IEEE 802.11b increased the speed to 11Mbps in the 2.4GHz band and set the stage for rapid growth of the wireless LAN market. Recently IEEE 802.11g has increased speeds again in 2.4GHz by introducing more sophisticated modem techniques. Soon we can anticipate new versions in the 5GHz band that might push data rates up to 100 or 200Mbps.
Well, interesting as all this is, none of it is relevant to security. The same security techniques can apply whether you are using 100Mbps or going back to your Morse code transmitter.
A broad understanding of how Wi-Fi networks operate is important for you to understand how the security mechanisms work. This chapter has reviewed IEEE 802.11 from the basic topology down to an outline of the protocol messages. We have seen how the Wi-Fi LAN fits into a stack of layers between the operating system and the wireless medium. Wi-Fi provides the lower layers of communication, while higher layers such as TCP/IP ensure delivery of data from end to end.
We looked at the way Wi-Fi LAN are organized, showing how there are two modes of operation—ad-hoc (IBSS) and infrastructure (ESS). The most common mode is ESS, which uses an access point.
Operation of the Wi-Fi LAN is coordinated by a stream of management and control messages in addition to data messages. This chapter has reviewed the main message types and how the management messages enable wireless devices to find each other and form connections. The security mechanisms are tied up with the process of making connections and passing data. The next chapter looks in detail at the original security method WEP, whose operation was closely tied to the Wi-Fi management messages.
[1] In the original Wi-Fi products, being associated gave you network access right away. However, as we show in Chapter 8, in the new security approach, association only allows the STA to begin the full authentication process needed for secure network access.
[2] Medium access control.
[3] For example, the IEEE 802.11 Handbook: A Designer's Companion by Al Petrick and Bob O'Hara, published by IEEE Press.
[4] Sometimes called wireless bridging.