Search the Catalog
Building Wireless Community Networks

Building Wireless Community Networks

Implementing the Wireless Web

By Rob Flickenger
November 2001
0-596-00204-1, Order Number: 2041
138 pages, $24.95

Chapter 3
Network Layout

In many ways, 802.11b networking is very much like Ethernet networking. Assuming you want to connect your wireless clients to the Internet, you'll want to provide all of the usual TCP/IP services, such as Domain Name Service (DNS) and Dynamic Host Configuration Protocol (DHCP), that make networking so much fun. To the rest of your network, wireless clients look just like any other Ethernet interface and are treated no differently than the wired printer down the hall. You can route, rewrite, tunnel, fold, spindle, and/or mutilate packets from your wireless clients just as you can with any other network device.

Presumably, no matter how many wireless clients you intend to support, you will eventually need to "hit the wire" in order to access other networks (such as the Internet). How do packets find their way from the unbridled freedom of the airwaves to the established, hyper-interconnected labyrinth of the Internet? This chapter describes what you need to know to do that.

Wireless Infrastructure: Cathedral Versus Bazaar

As with any network supporting different physical mediums, network bridges must exist that are capable of exchanging data between the various network types. A wireless gateway consists of a radio card and a network card (usually Ethernet). In the case of 802.11b, radios participating in the wireless network must operate in one of two modes: BSS or IBSS.

BSS stands for Basic Service Set. In this operating mode, a piece of hardware called an access point (AP) provides wireless-to-Ethernet bridging. Before gaining access to the wired network, wireless clients must first establish communications with an access point within range. Once the AP has authenticated the wireless client, it allows packets to flow between the client and the attached wired network, effectively acting as a true Layer 2 bridge, as shown in Figure 3-1. A related term, ESS (or Extended Service Set), refers to a physical subnet that contains more than one AP. In this sort of arrangement, the APs can communicate with each other to allow authenticated clients to "roam" between them, handing off IP information as the clients move about. Note that (as of this writing) there are no APs that allow roaming across networks separated by a router.

Figure 3-1. In BSS (or ESS) mode, clients must authenticate to a hardware access point before being able to access the wired network
Figure 1

IBSS stands for Independent Basic Service Set and is frequently referred to as ad-hoc or peer-to-peer mode. In this mode, no hardware access point is required. Any network node that is within range of any other can commence communications if they agree on a few basic parameters. If one of those peers also has a wired connection to another network, it can provide access to that network. Figure 3-2 shows a model of an IBSS network.

Figure 3-2. In IBSS mode, nodes can talk to any other node in range. A node with another network connection can provide gateway services
Figure 2

Note that an 802.11b radio must be set to work in either of these modes but cannot work in both simultaneously. Both modes support shared-key WEP encryption (more on that later).

Access Point Hardware

Access points are widely considered ideal for campus coverage. They provide a single point of entry that can be configured by a central authority. They typically allow for one or two radios per AP, theoretically supporting hundreds of simultaneous wireless users at a time. They must be configured with an ESSID (Extended Service Set ID, also known as the Network Name or WLAN Service Area ID, depending on who you talk to); it's a simple string that identifies the wireless network. Many use a client program for configuration and a simple password to protect their network settings.

Most APs also provide enhanced features, such as the following:

Other enhanced modes include dynamic WEP key management, public encryption key exchange, channel bonding, and other fun toys. Unfortunately, these extended modes are entirely manufacturer- (and model-) specific, are not covered by any established standard, and do not interoperate with other manufacturer's equipment. It should also be noted that, once a client has associated itself with an AP, there are no further restrictions imposed by the AP on what services the client can access.

APs are an ideal choice for private networks with many wireless clients that exist in a confined physical space, especially on the same physical subnet (like a business or college campus). They provide a high degree of control over who can access the wire, but they are not cheap (the average AP at this writing costs between $800 and $1000).

Another class of access point is occasionally referred to as a residential gateway. The Apple AirPort, Orinoco RG-1000, and Linksys WAP11 are popular examples of low-end APs. They are typically much less expensive than their commercial counterparts, costing between $200 and $500. Many have built-in modems, allowing for wireless-to-dialup access (which can be very handy, if Ethernet access isn't available wherever you happen to be). Most even provide Network Address Translation (NAT), DHCP, and bridging services for wireless clients. While they may not support as many simultaneous clients as a high-end AP, they can provide cheap, simple access for many applications. By configuring an inexpensive AP for bridged Ethernet mode, you can have a high degree of control over what individual clients can access on the wired network (see the section "Captive "Catch and Release" Portal" in Chapter 7).

Despite their high cost, APs have their place in building community wireless networks. They are especially well suited to remote repeater locations, due to their ease of configuration, low power consumption (compared to a desktop or laptop PC), and lack of moving parts. We'll go into detail on how to set up an AP in Chapter 4.

Peer-to-Peer Networking

If the goal of your wireless project is to provide public access to network services, the functionality high-end APs provide will almost certainly be overkill, particularly in light of their high cost. Luckily, with IBSS mode, AP hardware is entirely optional.

Radios that are operating in IBSS mode can communicate with each other if they have the same ESSID and WEP settings. As stated earlier, a computer with an 802.11b card and another network connection (usually Ethernet or dialup) can serve as a gateway between the two networks. Add in DHCP and NAT services, and you effectively have a full-blown Internet gateway. As various free operating systems can provide these services and will run well on hardware that many people already have lying around in closets (e.g., 486 laptops and low-end Pentium systems), this mode of operation is an increasingly popular alternative to expensive APs. If you have host hardware available already, the low cost of making a gateway is very attractive (the cost of the average client radio card is $120, or about half that of a low-end AP).

What is missing from a do-it-yourself gateway? Instead of the myriad access control methods that actual APs provide, the only out-of-the-box access control you have available is WEP. As we saw earlier, a shared key does little on its own for security, and it isn't appropriate in a public network setting anyway. So how can we provide network access and still discourage abuse by anonymous wireless clients? See Chapters and .

In Chapter 5, we'll build a Linux-based wireless gateway from scratch. In Chapter 7, we'll examine one method of extending the gateway to provide different classes of service, depending on who connects to it.

Vital Services

A network can be as simple as a PPP dialup to an ISP, or as grandiose and baroque as a multinational corporate MegaNet. But every node on a multimillion dollar network in Silicon Valley needs to address the same fundamental questions that a dialup computer must answer: who am I, where am I going, and how do I get there from here? In order for wireless clients to easily access a network, the following basic services must be provided.

DHCP

The days of static IP addresses and user-specified network parameters are thankfully far behind us. Using DHCP (Dynamic Host Configuration Protocol), it is possible (and even trivial) to set up a server that responds to client requests for network information. Typically, a DHCP server provides all the information that a client needs to begin routing packets on the network, including the client's own IP address, the default Internet gateway, and the IP addresses of the local DNS servers. The client configuration is ridiculously easy and is, in fact, configured out of the box for DHCP in all modern operating systems.

While a thorough dissection of DHCP is beyond the scope of this book, a brief overview is useful. A typical DHCP session begins when a client boots up, knowing nothing about the network it is attached to except its own hardware MAC address. It broadcasts a packet saying, effectively, "I am here, and this is my MAC address. What is my IP address?" A DHCP server on the same network segment listens for these requests and responds: "Hello MAC address. Here is your IP address, and by the way, here is the IP address to route outgoing packets to, and some DNS servers are over there. Come back in a little while and I'll give you more information." And the client, now armed with a little bit of knowledge, goes about its merry way. This model is shown in Figure 3-3.

Figure 3-3. DHCP lets a node get its network settings dynamically and easily
Figure 3

In a wireless environment, DHCP is an absolute necessity. There isn't much point in being able to wander around without a cable if you need to manually set the network parameters for whatever network you happen to be in range of. It's much more convenient to let the computers work it out on their own (and let you get back to more important things, like IRC or "Quake III Arena"). Since DHCP lets a node discover information about its network, one can get "online" without any prior knowledge about that particular network's layout. This service demonstrates a condition that network administrators have known for years: users just want to get online without knowing (or even caring) about the underlying network. From their perspective, it should just work. DHCP makes this kind of magic possible.

From a network admin's perspective, the magic isn't even terribly difficult to bring about. As long as you have exactly one DHCP server running on your network segment, your clients can all pull from a pool of available IP addresses. The DHCP server manages the pool on its own, reclaiming addresses that are no longer in use and reassigning them to new clients.

In many cases, a wired network's existing DHCP server serves wireless users with no trouble. It sees the wireless node's DHCP request just as it would any other and responds accordingly. If your wired network isn't already providing DHCP, or if your wireless gateway isn't capable of L2 bridging, don't worry. We'll cover setting up the ISC's dhcpd server in Linux in Chapter 5.

DNS

My, how different the online world would be if we talked about sending mail to rob@208.201.239.36 or got excited about having just been 64.28.67.150'd. DNS is the dynamic telephone directory of the Internet, mapping human friendly names (like oreillynet.com or i>slashdot.org) to computer friendly numbers (like the dotted quads above). The Internet without DNS is about as much fun and convenient as referring to people by their Social Security numbers.

Much like DHCP, your network's existing DNS servers should be more than adequate to provide name resolution services to your wireless clients. However, depending on your particular wireless application, you may want to get creative with providing additional DNS services. A caching DNS server might be appropriate, to reduce the load on your primary DNS servers (especially if you have a large number of wireless clients). You might even want to run separate DNS for your wireless hosts, so that wireless nodes can easily provide services for each other.

NAT

In order for any machine to be reachable via the Internet, it must be possible to route traffic to it. A central authority, the IANA (Internet Assigned Numbers Authority, http://www.iana.org), holds the keys to the Internet. This international body controls how IP addresses are parceled out to the various parts of the world, in an effort to keep every part of the Internet (theoretically) reachable from every other and to prevent the accidental reuse of IP addresses in different parts of the world. Unfortunately, due to the unexpectedly tremendous popularity of the Net, what was thought to be plenty of address space at design time has proven to be woefully inadequate in the real world. With thousands of new users coming online for the first time every day, the general consensus is that there simply aren't enough IP addresses to go around anymore. Most ISPs are increasingly paranoid about the shortage of homesteading space, and they are loath to give out more than one per customer (and, in many cases, they won't even do that anymore, thanks to the wonders of DHCP).

Now we see the inevitable problem: suppose you have a single IP address allocated to you by your ISP, but you want to allow Internet access to a bunch of machines, including your wireless nodes. You certainly don't want to pay exorbitant fees for more address space just to let your nephew get online when he brings his wireless laptop over once a month.

This is where NAT can help you. Truly a mixed blessing, NAT (referred to in some circles as "masquerading") provides a two-way forwarding service between the Internet and another network of computers. A computer providing NAT typically has two network interfaces. One interface is connected to the Internet (where it uses a real live IP address), and the other is attached to an internal network. Machines on the internal network use any of IANA's thoughtfully assigned, reserved IP addresses and route all of their outgoing traffic through the NAT box. When the NAT box receives a packet bound for the Internet, it makes a note of where the packet came from. It then rewrites the packet using its "real" IP address and sends the modified packet out to your ISP (where it winds its way through the rest of the Internet, hopefully arriving at the requested destination). When the response (if any) comes back, the NAT box looks up who made the original request, rewrites the inbound packet, and returns it to the original sender. As far as the rest of the Net is concerned, only the NAT machine is visible. And as far as the internal clients can tell, they're directly connected to the Internet. Figure 3-4 shows a model of a NAT configuration.

Figure 3-4. Using NAT, several computers can share a single "real" IP address
Figure 4

The IANA has reserved the following sets of IP addresses for private use (as outlined in RFC 1918, http://rfc.net/rfc1918.html):

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

These are addresses that are guaranteed never to be used on the Internet. As long as your internal machines use IP addresses in any of these three ranges, your traffic will not interfere with any other host on the Net. As an added bonus, since the reserved IP address traffic isn't even routed over the Internet, you effectively get a free firewall for all of your NAT'd hosts.

NAT is handy but isn't without its drawbacks. For example, some services may not work properly with some implementations of NAT. Most notably, active FTP sessions fail on some NAT boxes. Another big disadvantage to NAT is that it effectively makes the Internet a read-only medium, much like television. If you can have only outbound traffic (to web servers, for example) and traffic from the Internet can't reach your machine directly, then you have no way of serving data and contributing back to the Net! This doesn't prevent you from using two-way services like IRC and email, but it does preclude you from easily running services where Internet users connect to you directly (for example, running your own web server from behind a NAT isn't trivial).

Despite these drawbacks, NAT is an invaluable tool for allowing throngs of people to access Internet resources. In Chapter 5, we'll build a Linux gateway that will do NAT for you and handle almost every popular form of Internet traffic you care to throw at it (including active FTP).

Of course, if you're lucky enough to have a ton of live IP address space, feel free to flaunt it and assign live IPs to your wireless clients! Naturally, most people (and, indeed, their laptops) are unprepared for the unbridled adrenaline rush of using a live IP address without a firewall. But if you have that many real IPs to throw around, you must be used to living large. Just don't worry when you find your clients spontaneously rebooting or suddenly serving 0-dAy W@r3z. It's all part of the beautiful online experience.

Security Considerations

Although the differences between tethered and untethered are few, they are significant. For example, everyone has heard of the archetypal "black-hat packet sniffer," a giggling sociopath sitting on your physical Ethernet segment, surreptitiously logging packets for his own nefarious ends. This could be a disgruntled worker, a consultant with a bad attitude, or even (in one legendary case) a competitor with a laptop, time on his hands, and a lot of nerve.[1] Although switched networks, a reasonable working environment, and conscientious reception staff can go a long way to minimize exposure to the physical wiretapper, the stakes are raised with wireless. Suddenly, one no longer needs physical presence to log data: why bother trying to smuggle equipment onsite when you can crack from your own home or office two blocks away with a high-gain antenna?

Visions of cigarette smoking, pale skinned über-crackers in darkened rooms aside, there is a point that many admins tend to overlook when designing networks: the whole reason that the network exists is to connect people to each other! Services that are difficult for people to use will simply go unused. You may very well have the most cryptographically sound method on the planet for authenticating a user to the system. You may even have the latest in biometric identification, full winnow and chaff capability, and independently verified and digitally signed content assurance for every individual packet. But if the average user can't simply check her email, it's all for naught. If the road to hell is paved with good intentions, the customs checkpoint must certainly be run by the Overzealous Security Consultant.

The two primary concerns when dealing with wireless clients are these:

As it turns out, with a little planning, these problems can be addressed (or neatly sidestepped) in most real-world cases. In this section, we'll look at ways of designing a network that keeps your data flowing to where it belongs, as quickly and efficiently as possible.

Let's take a look at the tools we have available to put controls on who can access what.

WEP

The 802.11b specification outlines a form of encryption called wired equivalency privacy, or WEP. By encrypting packets at the MAC layer, only clients who know the "secret key" can associate with an access point or peer-to- peer group. Anyone without the key may be able to see network traffic, but every packet is encrypted.

The specification employs a 40-bit, shared-key RC4 PRNG[2] algorithm from RSA Data Security. Most cards that talk 802.11b (Agere Orinoco, Cisco Aironet, and Linksys WPC11, to name a few) support this encryption standard.

Although hardware encryption sounds like a good idea, the implementation in 802.11b is far from perfect. First of all, the encryption happens at the link layer, not at the application layer. This means your communications are protected up to the gateway, but no further. Once it hits the wire, your packets are sent in the clear. Worse than that, every other legitimate wireless client who has the key can read your packets with impunity, since the key is shared across all clients. You can try it yourself; simply run tcpdump on your laptop and watch your neighbor's packets just fly by, even with WEP enabled.

Some manufacturers (e.g., Agere and Cisco) have implemented their own proprietary extensions to WEP, including 128-bit keys and dynamic key management. Unfortunately, because they are not defined by the 802.11b standard, there is no guarantee that cards from different manufacturers that use these extensions will interoperate (and, generally speaking, they don't).

To throw more kerosene on the burning WEP tire mound, a team of cryptographers at the University of California at Berkeley have identified weaknesses in the way WEP is implemented, effectively making the strength of encryption irrelevant. With all of these problems, why is WEP still supported by manufacturers? And what good is it for building public access networks?

WEP was not designed to be the ultimate "killer" security tool (nor can anything seriously claim to be). Its acronym makes the intention clear: wired equivalency privacy. In other words, the aim behind WEP was to provide no greater protection than you would have when you physically plug into your Ethernet network. (Keep in mind that in a wired Ethernet setting, there is no encryption provided by the protocol at all. That is what application layer security is for; see the tunneling discussion later in this chapter.)

What WEP does provide is an easy, generally effective, interoperable deterrent to unauthorized access. While it is technically feasible for a determined intruder to gain access, it is not only beyond the ability of most users, but usually not worth the time and effort, particularly if you are already giving away public network access!

As we'll see in Chapter 7, one area where WEP is particularly useful is at either end of a long point-to-point backbone link. In this application, unwanted clients could potentially degrade network performance for a large group of people, and WEP can help not only discourage would-be link thieves, but also encourage them to set up more public access gateways.

Routing and Firewalling

The primary security consideration for wireless network access is where to fit it into your existing network. Regardless of your gateway method (AP or DIY) you need to consider what services you want your wireless users to be able to access. Since the primary goal of this book is to describe methods for providing public access to network services (including access to the Internet), I strongly recommend setting up your wireless gateways in the same place you would any public resource: in your network's DMZ or outside your firewall altogether. That way, even in a complete breakdown of security precautions, the worst that any social deviant will end up with is Internet access, and not unrestricted access to your private internal network.

This configuration, as shown in Figure 3-5, leaves virtually no incentive for anyone to try to compromise your gateway, as the only thing to be gained would be greater Internet access. Attacks coming from the wireless interface can easily log MAC address and signal strength information. In IBSS mode, this is an even greater deterrent. As the would-be attacker needs to transmit to carry out an attack, they give away not only a unique identifier (their MAC address), but also their physical location!

Figure 3-5. Place your wireless gateways outside of your private network!
Figure 5

Assuming that all wireless connectivity takes place outside of your private network, what happens when you or your friends want to connect from the wireless back to the inside network? Won't other wireless users be able to just monitor your traffic and grab passwords and other sensitive information? The next section, "Encrypted Tunnels," addresses this potential problem.

Encrypted Tunnels

Application layer encryption is a critical technology when dealing with untrusted networks (like public-access wireless links, for example). When using an encrypting tunnel, you can secure your communications from eavesdroppers all the way to the other end of the tunnel.

If you're using a tunnel from your laptop to another server, would-be black hats listening to your conversation will have the insurmountable task of cracking strong cryptography. Until someone finds a cheap way to build a quantum computer (and perhaps a cold fusion cell to power it), this activity is generally considered a waste of time. In Figure 3-6, a web server providing 128-bit SSL connections provides plenty of protection, all the way to your wireless laptop. SSL provides application layer encryption.

Figure 3-6. WEP only encrypts to the gateway, exposing your traffic to other wireless users and anything after the wire. Tunnels protect your traffic from end to end
Figure 6

SSL is great for securing web traffic, but what about other network services? Take this typical scenario: You're at work or at home, merrily typing away on your wireless laptop. You want to retrieve your email from a mail server with a POP client (Netscape Mail, Eudora, fetchmail, etc.). If you connect to the machine directly, your email client sends your login and password "in the clear." This means that a nefarious individual somewhere between you and your mail server (either elsewhere on your wireless network, or even "on the wire" if you are separated by another network) could be listening and could grab a copy of your information en route. This login could then not only be used to gain unauthorized access to your email, but in many cases also to grant a shell account on your mail server!

To prevent this, you can use the tunneling capabilities of SSH. An SSH tunnel works like this: rather than connecting to the mail server directly, we first establish an SSH connection to the internal network that the mail server lives in (in this case, the wireless gateway). Your SSH client software sets up a port-forwarding mechanism, so that traffic that goes to your laptop's POP port magically gets forwarded over the encrypted tunnel and ends up at the mail server's POP port. You then point your email client to your local POP port, and it thinks it is talking to the remote end (only this time, the entire session is encrypted). Figure 3-7 shows a model of an SSH tunnel in a wireless network.

Figure 3-7. With an SSH tunnel in place, your otherwise insecure conversation stays private
Figure 7

With the tunnel in place, anyone who tries to monitor the conversation between your laptop and the mail server gets something resembling line noise. It's a good idea to get in the habit of tunneling anything that you want to keep private, even over wired networks. SSH tunneling doesn't have to stop at POP connections either. Any TCP port (SMTP, for example) can easily be set up to tunnel to another machine running SSH, almost anywhere on the Internet. We'll see an example of how to do that in Chapter 7. For a full discussion of the ins and outs of this very flexible (and freely available) tool, I highly recommend O'Reilly's SSH: The Definitive Guide, by Daniel J. Barrett and Richard E. Silverman.

Summary

In order to maintain maximum compatibility with available 802.11b client hardware and yet still provide responsible access to the Internet, we can apply a combination of inexpensive hardware and freely available software to strike an acceptable balance between access and security.

In the following chapters, we'll see how to set up basic wireless access to your existing wired network. We will then build a workable method for providing wireless services to your local community, for minimal cost, while promoting community participation and individual responsibility.


Footnotes

1. As the story goes, a major computer hardware manufacturer once found a new "employee" sitting in a previously unoccupied cube. He had evidently been there for three weeks, plugged into the corporate network and happily logging data before HR got around to asking who he was.

2. Pseudo-Random Number Generator. It could be worse, but entropy takes time.

Back to: Building Wireless Community Networks


oreilly.com Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies | Privacy Policy

© 2001, O'Reilly & Associates, Inc.
webmaster@oreilly.com