 It's really loud in here with their fans and everything, so if you have problems here and it's just scream, throw things, whatever it takes, hear our attention, we'll put the mics back inside our mouth, it'll all be good. Alright, we're going to talk about wireless stuff, security stuff, some other kind of pontificating and unphilosophical type wireless things. Excuse me? My name is Bruce Paddock with the Shrew Group and Noble Wireless. This is Adam Shan, he's with the Shrew Group and with Personal Teleco. And this is Sam, he's with the Shrew Group and Mesh Madison out of Madison, Wisconsin. Normal type kind is always a good time to talk because you're kind of in between that sine wave where I was really drunk last night and I haven't had time to get loaded yet. So what we're going to do is we're just going to pummel you with a bunch of information about wireless. We're going to go from layer one all the way up to layer eight and talk about ramifications of different state of the art security. No, we're not. Alright, so we're going to kind of start at layer two, I apologize. Anyway, if you have questions, we're probably not going to have a lot of time afterwards, but we are going to have a breakout session in the bar because the breakout room is full. So if you want a time out afterwards, come to the bar and we'll have it out there. I'll turn it over to Sam. Good afternoon. Is it? No. Okay, so in working with wireless, one of the things that came to my attention initially when touching any devices that I had access to, they all sucked. Who's deployed commercial IPs and open source versions yet? I see Matt in the front row, thanks. Okay, so when you have an access point up in a network, the player being active in a network at some location, at some point you need to change configurations, get statistics from it, send data to it, otherwise it will actually interact with the device. So when you do this, a lot of methods are available, most of them are TCP unencrypted protocols on top of that, HTTP, maybe pushing a configuration through FTP or maybe even TFTP if they're back end. So the interfaces available for most APs at this point generally don't let you actually communicate to the device in any secure manner. What's that mean to you? So if you have a large public network or even a large corporate network, if you trust your users, that's good. But if you have users who are also in the network and are not trustable, this means that whenever you administer your AP, they can possibly see all your credentials flying back and forth. That's an issue. The biggest point here is that, to my knowledge, no commercial access points yet? Yes? Okay. To the best of my knowledge, commercial access points that are available right now have no secure authentication mechanisms beyond maybe back-ending radius to a machine to say, yes, you are allowed to enter the AP. But in any case, whatever data you pass to the AP at this point is unencrypted and essentially just clear text. So that's a big issue to keep in mind when you're trying to actually deploy, say, a large city-wide network or mesh network. The APs you choose are going to be more or less defining how you get to them and what kinds of things you just make assumptions of on the network. Another bad thing about, of course, commercial hardware is at some point the company that made it is going to not want to support it any longer. This has happened numerous times. I don't even have to start mentioning names. And at some point you're going to want to keep using this gear. You're not going to just die right away. But you're not going to get firmware updates that fix moving issues if there are any other out there. You're not going to be able to take advantage of, say, people's awareness of web vulnerabilities or maybe new ciphers that come out, et cetera. There's issues with using anything that's integrated that comes in a box that just works out of a box. One last thing. Whenever you want to actually get reasonable data about an access point, let's say you want to get a histogram of all the received frames that came in at 1 megabit, 5 megabits, 2 megabits, 11 megabits. That data is not available in a lot of cases, but it's useful to have. Also are CFOs, various things on the year 211 Mac. You want to know some of this data for various purposes. A lot of it might be pretty trivial and geeky, but the fact that you want to get to it is not going to be supplied by most commercial vendors. Cisco and recent are the only ones that have a reasonable nib. Antaresis, a couple other hardware vendors that basically require you to toss a radio into your controller. They also have interesting nibs and decent data, but nothing truly as low-level as some of the solutions you want to talk about in a few minutes. Okay, the contra-positive to closed source, as it were, APs. It comes in with a variety of tools that are basically existing on Unix platforms at this point in time. There's only a couple things that do access point mode on Windows that are not open source. They're basically created by one company, OEM, rebranded by people like Zoom. So the issues at hand with open source APs are actually to your benefit. You can take advantage of romantic code bases using drivers from dream on. Namely, host AP has opened the doors to using access point code, making a device that's a Unix SOS, an access point. Basically using Prism 2 cards, Prism 2.5 cards as an access point. This drivers an excellent implementation of the protocol, all of the management frames, etc. Basically, it's ideal. Kernels that they run on, namely Linux, the BSD crowd recently got host AP support. I'm not sure exactly who committed it. Didn't follow it too closely. Open BSD followed soon. I'm not aware of that BSD support yet. I'm expecting it to be out there eventually. In any case, open source LSs are, I feel I can tell, the only truly correct implementation, or the only truly, the only platform I see right now that will eventually end up in a correct implementation of the protocol. Lots of vendors make lots of assumptions and or don't do adequate product testing before they release something. This has been the trend over and over and over again. I don't see it changing. So there's a lot of good reasons, even in a corporate environment, maybe taking some extra time, creating an AP based on some old P100 hardware, maybe one URAC server that has a PCI slot, toss in a PCMCIA bridge, etc. These options are available to you. You can then at least have a device where you manage it securely using common tools to secure shell. Maybe SCP to push configs to 20 or 30 access points at one time. Maintain the configurations in my SQL, letting scripts to read from that to push the configs, etc. It's an open source platform. You do whatever the heck you want. Also, one thing that most vendors' APs lack is good support for multiple and esoteric and weird protocols. In my open source implementation of course AP mode, you can at least have a full list behind you to do things like, say, route on the same device, bridge other protocols on the same device, and there would be also some wacky tunneling on the same device. This is flexible. Let's say you had ATM25, you wanted to drag across some 8 or 2 of an A link. You could easily do this with cells and frames, and also have routing happening side by side, and maybe the problems would exist. This would be a very powerful thing for you to have. Not that it would necessarily get used a lot, but the fact that it's there is generally worth considering. Open source 2 is available. Namely, instant 8 or 2 started the whole bowl of rolling, at least from the press that I recall seeing. Obviously, the address is right there. What they've done is basically combined 2.4.17 kernel, compiling and micro-lip-sealibs, and essentially scaled down and stripped down to be small to fit on a 1 mega flash with busy box supplying some user-run binaries. It runs on end of life hardware. It's kind of cool. It's kind of geeky. But as a basis, it's a great start. I'm a sinky and one of them too. These are 2 pieces of hardware that I don't know if they're even available yet. They're available next week, and then... Oh, okay. I think they're where. I'm sorry. What they're about to, at this point, is power-PC, system-on-ship, small boards, integrated into whatever you have. If you're a RISP, this might be an ideal thing for you. Anyway, they can run, of course, Linux and use Hosepi mode on Prism 2 cards on a mini-PCI slot. They're essentially a computer on a very, very tiny board with a reasonable amount of horsepower behind it. So seeing air-turbine A pushing hundreds of megabits on the thing is realizable. The OpenAP from this NATO 2 platform is very embedded, 4633. It doesn't quite have the guts to do anything beyond NATO 2 to level 11B, so you kind of stuck with that hardware. The really available light now working very well solution is from... At this point, it's from SOPRUS. Basically, this board that I have on the table right here that I'll be talking and counseling into, amounts to an embedded 4630, 133 PCI card-bus controller? Yeah, card-bus, I thought it was 16-bit, but I'm not. So two slots for card-bus interfaces, two ethernet, serial console, mini-PCI slot for maybe a cryptography accelerator, et cetera. The possibility is pretty open, what you can do with this hardware. Maybe you want to do point-to-point site tumbling through the air at several tens of megabits, it's possible. But what you do, you buy the hardware and you can fit it yourself. You don't stick it out with a large number and deal with their policies and support issues and that sort of thing. Anyway, that part, one of the last ones I want to mention, it has a distribution of software and a specifically designed piece of hardware. This OpenBSD, you get it from them. They take care of all the back-end for you as far as deploying an AP guys, getting DSL and that sort of thing. And their hardware actually is securely managed by them. So when changes need to be made, it's coordinated. Anyway, that's an example of someone who's not using the truly lowly embedded systems that just cannot support higher-layer protocols like SSH or don't have the functionality to support that kind of subsystem for authentication. Okay, so we kind of based through what APs are out there, how you implement stuff. I'm not going to get into protocol specifics, but there's a lot of looming issues with various implementations are just basic things like how a station, their laptop, roaming about associates to an access point. So one of the issues that, I'll do some short background. Most APs have a finite amount of memory in them, obviously all of them do. And so when you have a device out in the open roaming about what generally happens is as the card finds APs, here's Beacons, emits probe requests, etc., it will then associate to an AP. So once that happens, the AP has to do a few things in terms of housekeeping. It has to add an entry to a bridging table usually to say, okay, if an ephemeral interface or the wireless interface, I should then bridge it to another interface in my device if there's more than one or two. You need to maintain this. So as an association occurs, that MAC address plus some extra overhead is added to a table or some sort of data structure in the access points code base. So once this is done, you keep on increasing the overhead as you add a number of nodes. Usually it's linearly. I've noticed that OpenAP at least as a driver for UNIX is does scale linearly. The complexity of the data structure does not grow above and beyond the non-associations you add. I missed a meeting. I'm sorry. So he missed a meeting. So as you associate stations, you basically gobble memory. A lot of APs clip you at a set number of associations. Let's say the manufacturer expects or says in their marketing documentation, we need to support 64 stations or 128 stations. Some don't specify it really and essentially don't test the conditions of what would happen if you had 3,000 associations present. So in a lot of cases, APs can do unpredictable things when you try to associate many stations to them. A way to not have to buy 3,000 cars and have a lot of machines to host them in is to just change your macros in the car. Basically, the process to just create multiple associations on AP is pretty basic. But anyway, this more or less exercises a problem with most APs. Can we go to the next slide? Okay, so what APs have issues with this stuff? Cisco AP340s after you associate 227 stations stop sending EDP syslog for some unknown reason. After that, we have no way, whenever I'm using these APs, to know how many associations are in the thing at that point in time. But we know that as you keep on associating after several maybe 8 to 10 minutes, the thing will stop bridging frames. New associations can't be formed. And even if you let all the associations time out to the point of EDP syslog returning to functionality, you will not have proper bridging functionality. That is, new stations can come on, but the frames that they generate will never make it across to the youth network. This is a leading issue. It's been since 11.7. There's four or five security incidents available from the school I'm at, we supplied, and they haven't done any activity on these issues yet. So if you are, say, operating a hotspot that has a web authentication pull behind the AP and someone doesn't enjoy your AP being there, or it has a defend data, and wants to essentially DOS something, why touch layer three? Just over associate the thing and let it sit. Other issues with other vendors at Mill and Will Suntech are two sources of basically real-time OSS plus some drivers for embedded hardware platforms. And they clip the association to 64, but they don't time them out properly. They'll stay there forever. So as you fill them, no new ones can form. So that's another way to stop someone from getting to the AP. Yes? I have not yet tested 1200s. He asked if I had experience with Cisco AP 1200s or the Enterosys R2. I haven't touched either of those in person. I only read docs and from what I can tell, they use the same VxWorks code base. So I would suspect the same issues may still be there. Maybe it has more memory and doesn't cause as much of an issue. I'm not exactly sure. So, next slide, please. Another issue with just open 802.11 associations allowed to an AP for whatever purpose comes to mind in a situation where if you say wanted to fix the over-association issue by having only a certain set of MAC addresses that you will permit to associate, if someone still wants to get in, they can still figure out easy ways to do this. One of the posed ways would be to send a frame to the destination MAC of a broadcast from the source of the AP. You need to be associated. All you need to do is generate this frame, this management frame. To all the nodes, de-authenticate, which would mean that they would then de-authenticate and revoke the association that they currently have with the AP. This means that anybody who's able to receive your frame that you surreptitiously transmit will then de-authenticate and remain disassociated. XP tosses a little pop-up. Maybe this would be annoying to see every couple seconds. I'm not sure if people would notice this in a coffee shop. But in any case, if you had, say, an MAC access list, you could at least subvert that being there by knocking someone off and quickly taking over their parent source MAC address by simply changing your card to MAC address to become theirs, thereby getting access at least to the association when you're being able to pass frames through the AP to some router or portal behind it. Next slide. And one last thing. To keep in mind, we have basically, essentially, a go, what's the word, awful, whatever. When you have a router to develop there, anybody can toss an AP up at any time and use the spectrum without permission. Your potential for someone impersonating your access points is very high. So a lot of solutions to try to get rid of this have keys per AP that clients expect, et cetera, et cetera. But when you come down to deploying a wide network and managing that infrastructure, again, insecurely on most corporate APs doesn't seem too appealing to me. So if you were in a situation where you had, say, at DEFCON, lots of APs at the SSID at DEFCON and obviously the MAC address is visible, what would happen if someone put up an AP at the same SID and the same MAC and had more power than you? Would they tend to see clients associate to them? I would reason that that would be the case. What could they do then? They could more easily man the middle connection attempts. They could more transparently do all sorts of interesting things with three and above. It's just a point to keep in mind if you want to have an AP or if you want to, say, start a WISP and toss up APs, do bridging, do meshing around your town, and then have a portal behind that. There's no way for anybody to know that the AP they see is your AP, but that in mind. And the next slide of the week breaks over to Bruce and questions we would prefer after all three of us. So here he is. All right. So we're kind of moving away from the protocol stack here. Sam covered the low end to layer two LLC type stuff. So in general, when thinking about wireless or thinking about any kind of security, it's risk management, right? It's not black and white. It's not like it's secure or it's not. So you got to go out and design a system that tries to protect everybody given your threat model. The one thing about wireless is about the worst case threat model. There's no physical security to the data transport. Maybe you can do some encryption to try to protect yourself, but by and large, everybody's just out there hung out to dry. So what ends up happening is people spend a lot of time trying to secure the infrastructure and secure your access point and your network. And also the crap. And you leave your clients out there to dry. You all have a vice president of marketing out of a wireless LAN running some old version of Windows and open shares and all kinds of nonsense sending his traffic around. It's a great vector to come into a corporate network. Screw the access point. Go after the laptop's connected to it. You'll have a lot better luck. So if you're on the side of dark, go after the clients. And if you're on the side of light, secure them. Another thing is there's a lot of money in this. There's an awful lot of money in wireless. There are companies running to make gear. There are companies running to try and provide service. And what that ends up happening is you get a product that's rushed to market. It's kind of like the .com thing all over again with all these harebrained ideas. People just trying to get something out to sell it. And a lot of times what ends up happening is reliability and security are compromised. For instance, I've got an SMC 802.11A access point bought from Cop USA, took it home. SNMP walked it with, of course, public as a default string. And it crashes. It reloads the box. If you can hit SNMP on that box, it'll just reload it. There are many such instances where there are obvious reliability problems with the hardware. And the only excuse that I can even think of is that they were trying to get to market too fast. So be aware of what you're buying. If you're buying for an enterprise, make sure you buy stuff that's time-tested. And if you're looking to have some fun, go after the new stuff, because the new stuff is going to be where the problem is. I guess I'm getting a little feedback, so sorry about that. So what's the real risk? It's kind of interesting. Everyone's kind of a doomsayer about wireless and wireless security and what really is wrong with it. It's not that bad. Attacks are localized. From Las Vegas, I cannot attack the way or two infrastructure of a network in San Francisco. There's just no way. I have to be with a near shot. I have to be able to see the network, and they have to be able to see me. So you're not going to just go on to a global attack against all Wi-Fi networks. You're going to have to attack somebody local. And there are a ton of wireless networks. There's a wardrobe contest starting in half an hour. The meeting starts now, so if you want to be in it, you got to go. But they're going to find hundreds, if not thousands of access points in Vegas. And some of them are going to be protected. Some of them are going to be wide open, and there'll be a whole range in between. People aren't going to go after the ones that are protected unless you're a target. If you try and secure yourself, and you take due diligence to do something useful to keep people off your network, and you've got a casual war driver looking to go surf some porn or go hack someplace in Norway, they're going to go 100 yards down the street and use somebody else. All right, so everybody talks about Web, so we're going to have a slide on the Web. Web is cryptographically flawed. There's papers on it. There was none of that this time last year. I'm not going to go into it. It's cryptographically flawed. It doesn't mean it's pointless. Okay? Cryptographers love to talk in black and white. I have an algorithm that is yet to be determined weak in some way, and suddenly there's a weakness that means, oh, we got to throw out the window, stop working now, and go work on something else. Web is flawed, but it's not useless. Not only does it prevent a moderate technical barrier to get it out of the network. If it's web-encrypted, it's not like, oh, it's just web-encrypted, and you wave your hand and you're on the network. You still have to collect gigabytes of packets and grind them to find the key. And on a home network, it's going to take a long time. And even on a lot of corporate networks, it's going to take a long time. And what's the real value? No one's going to come hack your house to get your one credit card and maybe find out who you're having to fare with. People are going to go find a real target. So at your house, at small office, it's not that big of a deal. Also, this is kind of important. I think it was touched on by the folks who were in this hilarious presentation before this. It is a do not disturb sign. It's a no trespassing sign that you're hanging on your door. You're all familiar with it. You really need to have banners on your telnet sessions and banners on SSH and all these things that unauthorize access. Please, blah, blah, blah. Personal property. I'll come after you and so will Guido. Web is the equivalent at layer two. You're hanging a sign in your network that says, hey, I don't want you here. Someone comes up to an unsecured, unwet protected network and they associate, they get a DHCP address and they're surfing the net. They can claim ignorance. There's a lot of things they can claim. They claim, I didn't know I wasn't supposed to be here. If someone comes up and spends, you know, two days collecting packets, cracks, weapon gets on your network. That's a whole different deal. XP doesn't do that by default. You know, you actually have to do something. So you may not be able to find the person on your network but on the off chance he's dumb enough to be sitting in the parking lot and he's in his VW Beetle with a satellite dish on the roof aimed at your building. Call the cops and then you actually have legal recourse. All right, so there's a lot of things you can do to secure the network. This is in the wrong order. So let's start here. 802.1X. How many people here know what 802.1X is? That's actually not bad. Again, it was more than a black hat. 802.1X is a port based authentication mechanism. Originally designed for campus networks. Effectively what happens is, campus has had, you know, I'm a campus network administrator. I got cap five all over the place. I got 5,000 ports, waiting for someone to plug in the cable to it just so I can give them the DHCP address and then go on the internet. That's kind of a bad situation. You can do things of course like maintain MAC address lists and things that people allow them in the network but everybody can change their MAC address and who wants to maintain 5,000 MAC addresses anyway. So 802.1X protocol is developed to allow you to come in and connect to a port and all the traffic that you send is authentication traffic. It goes to an authentication server. The authentication server verifies who you are and then responds back to the switch and says, all right, let this person go do whatever it is they want to do and open up the gates. So it's effectively a layer two portal that you can't do anything into you authenticate. So it's kind of a novel system. EAP is what they use to provide the authentication. EAP is like XML for authentication. It's very extensible. You can plug lots of crap into it. You can do MD5. You can do TLS. You can do all kinds of one-time password authentication or whatever. The switch or in the wireless world, the access point becomes a pass-through for the EAP traffic. So I can use any EAP method I want and I don't have to upgrade my access point. My client needs to know and my authentication server needs to know what kind of authentication I'm running. But the access point just says, oh, it's EAP traffic. I'll keep pumping it through. So there's a protocol on the wireless side for EAP over LAN, EAP over wireless. And then what's usually happened, then it's encapsulated in Radius on the wired side going to the authentication server. And Radius gets you authentication, authorization, and auditing, right, AAA services. That's something that doesn't really exist right now in wireless. So what's really nice is after you authenticate, you can also send back arbitrary material back to the client, including, hey, Webkeys. So what ends up happening is every hour you have to re-authenticate with 802.1x and you can end up shipping a new Webkey to the client every hour in a TLS encrypted session. So, well, Web may not be perfect. If you have a fast enough key rotation, not together enough data to be of interest, suddenly your network is actually moderately secure. This is something that's being standardized by the 802.11i security task force. So in another year or so, they'll have all this and a couple other things kind of bundled together. But what's really important here, 802.1x and EAP were not designed for wireless. 802.1x was designed for a wired network. EAP was designed for PPP. They put them together and there are a couple of issues regarding basically how it works in the wireless threat model. It's a lot different than the campus threat model, right? Campus is you kind of assume this physical security. There's nothing in wireless. So what ends up happening, when you leave the client out to dry, you still don't have authenticated management frames. You can still cause them to disassociate. You can still mess with them. There are man-in-the-mill attacks. There's session hijacking attacks that you can perform. I'm not going to get into it here, but effectively, if you're using Web with 802.1x, you can actually overcome a lot of the problems with 802.1x. It's very important. The art ball paper that was released by the guys at the University of Maryland made one assumption. Nobody really caught on to it at the time. At least the press didn't catch on to it because it wasn't really sexy. If you're using Web, a lot of the problems with 802.1x are mitigated. The problem is you have to have a Web key there before the 802.1x session starts. So you've got a chicken and egg problem. When I want to use 802.1x, and I've got my XP laptop, which has 1x support on it natively, I plug into a network, I associate first, and then I perform the 1x authentication. So then once the 1x authentication is performed, then I can get out onto the network as a whole. So what that ends up mean is during that time, if you're not doing Web authentication and encryption after that point, then all the 1x stuff is passing to clear. The EAP traffic may be encrypted and great and wonderful, but the 1x protocol is still in the clear. So if you use Web for that initial association, you can't see the 1x traffic. It's great, but you still have the key management problem. I still need to get the key to the client. I still need a default key to give to everyone. So it's still a broken trust model in some senses that, hey, I'm going to trust you for 25 packets and then I'll make you change your key. I'm going to trust everybody with the same key for the same 25 packets. It's a little dicey, but again, if you're doing this crap, just someone else is going to aim the antenna over here and just go over to valleys and start using their network. All right. There's other things you can do. You can do end-to-end encryption. You can do SSL. You can do SSH. Try to teach your mom to do SSH channeling. It'll work out very well. It's not a real feasible solution. It's great for geeks, but it doesn't really work out for the populace as a whole. SSL is pretty handy, but not all services can be secured using SSL, at least not easily. You can do iMap, Pop, SMGP, Web, and some other nonsense over SSL. But anything beyond that gets kind of difficult. So the ultimate solution, use IPsec. If you can't use certificate-based IPsec, it's robust. It's very proven. It's something just like vendors, when their gear is new, you've got a good chance of finding a problem with it because nobody's poked and potted at it yet. IPsec is a fairly long-standing protocol without really any major problems at all if you set it up correctly. Key. And if you are able to set it up, period. Another key issue. In DC, we ran a tutorial, kind of a day-long workshop on setting up VPNs. We have a group there called Security Geeks. We were trying to start ones all over the nation. So if you're interested in being a Security Geeks chapter, come see me afterwards. Sorry, trying to pin me. We had a VPN workshop and got everybody together. We used really smart guys. And we had 20 or 30 different machines. We had Linux-free BSD. We had firmware devices, or net screens and checkpoint boxes and whatever and tried to make them all play nice together. I think it was a good four hours before we had our first tunnel up on any of the boxes. These are people who do this kind of stuff professionally for a living. Once we got into the heterogeneous network, it took us about four hours to get stuff going. IPsec, it's great if you can get it to work, but good luck. There's a lot of resources on the net. There's also a good website, Bob, run by Tina Bird. It's got very good VPN information, and I believe there's some actually VPN or wireless stuff like from there. So what's the deal? I actually heard someone the other day tell someone in all seriousness, don't bother turning on web. It's totally useless. That was the most asinine thing I'd heard in a while. There's just no point in that. We're smart people here generally, or else we just really like drinking, but if you're here in this room, that you're smartly smart, do some due diligence. Raise the bar a little bit and make someone just go down the road. It's not that hard. There are a lot of protocols coming down the pipe that will be more secure and will make it more bulletproof and will make the cryptographers give a warm and fuzzy feeling that, yeah, this is all good and you can poke at it all day and it's fine, but that's not the way it is today. So just do what you can and keep people off your network. Use your time on someone who knows what they're doing. Go find someone who's plugged into Cox Cable and they're just advertising everything all over the place and just go use them. Anyway, that's the end of my slide. I'm going to hand it over to Adam now and he's going to rant a lot. Can everybody hear me in the back? All right. So just to wrap up the security part of it, there are some things you can do to secure wireless networks from an application point of view. You can run open or active portals. These aren't so much security systems as they're splash systems. There's ways of announcing that there is a wireless access point there. You can run captive portals, sometimes called forced portals. These generally authenticate off an LDAP or a radius server of some sort and again, they allow you to brand and access points. People are forced to a web page. You can see your logo and all that stuff and they allow firewall rules to be dynamically updated. You can do authenticated DHCP. This is a problem because basically nobody implements it. You can do application proxies if you want. Again, it's a big hassle and a cool idea that I talked about last year was extrusion detection or reverse intrusion detection which is basically the idea of taking an IDS, flipping it around and watching for traffic, leaving your network rather than coming into your network and then setting up triggers to take action based on that. So if somebody connects to your access point and they're doing something that doesn't look right, you can dynamically block them. All right. So all the people sitting up here are part of what's being called community wireless networking movement. So we've talked about all the security stuff. Now what are we actually doing with it? Community wireless is basically a grassroots effort to build city-wide wireless networks. The idea being that you can sit down in cafe one and get access across a wireless network to cafe two on the other side of town, to your house, to your own internet connection, whatever you want. It's currently being done on an entirely volunteer basis. There's some nonprofits in the process being set up that people hope will encourage growth. It's basically people just screwing around and seeing what they can do with wireless. So all these groups started up a couple years ago and they're slowly diverging in what their political and technical goals are doing. The first group you have is the philanthropists, all right? They're basically the groups that are setting up hot spots. They're doing what the commercial providers are doing, only they're doing it for free. They're going into coffee shops saying, hey, if you buy an access point, we'll show you how to secure it, we'll maintain it for you, and you give bandwidth away for free. The groups like that are PersonalTeleco and NYC Wireless, okay? We then have the isolationists. These are groups that don't so much believe or care about internet. They're just building a wireless network. Seattle Wireless, Madison Mesh, these are all groups that are trying to do that. They're basically trying to build a parallel internet without the internet, right? So you can get access to the wireless net. You can cross the wireless net, you can get internet access. You need to make your own arrangements for that somehow. Maybe you can VPN into a home server that's also on the wireless network or whatever. There's the anarchists. These are people who are starting community groups. Their main motivation seems to be to fuck the telcos, to piss people off, to make trouble. Consume in London is one of the big groups proposing that. There's a lot of the no-borders stuff involved, and I think most of the groups have a little bit of this in them, okay? There's a new type of group coming up called the aggregator. And basically what they're trying to do is they're in rural, sort of highly populated, mostly rural areas that don't have broadband access now. And what they're doing is they're setting up local, community-owned, wireless ISPs and providing the non-profit infrastructure to link, provide peering agreements, and all that stuff. Then we have user groups, which are Beowah. They aren't actually building networks. They're mostly just helping other people do what they want to do and providing information and resources. So the good news is that most of these groups have similar end goals, right? The big dream for everybody is to build a wireless cloud, right? You want to be able to sit somewhere. You want to be able to get from point A to point B across the wireless network without paying a telco a monthly fee, all right? You want to do no-cost peering. The idea is you put up an access point. You allow people through your access point without cost. Some people are talking about doing free internet as well. Some people think that's a bad idea. Now that falls out. The bottom line with internet access is that it costs money somewhere. So how do you provide that for free? So this leads to the idea of a digital commons. This is something that Lawrence Lessig, he's a constitutional lawyer at Stanford, has been talking about a lot. The idea that if you have a free low barrier to entry digital network, right, that it's a great platform for innovation. The internet was a digital common. But what's happened is that as more important for commerce to happen over the internet, the freedom and the anarchy that allowed the network to grow and allowed people to innovate on the network is slowly being taken away because what's most important is that bits can get from point A to point B reliably and that they can know who did it and catch fraud and all that sort of stuff. It's not so much that commerce is bad, just as that it doesn't work terribly well with anarchy. So as far as the digital commons, there's a lot of debate about what exactly should be free, how does it become sustainable, how do you make it work. The basic idea is the network itself should be free. You can run all the services you want over the network. You can do location-based services, you can sell web services, you can do mail services, you can do God knows what if you can think of it. That's the whole point is that people can innovate and find cool things to do with the wireless networks. But you should not be able to charge for the network itself. You now have the problem that you're building something for free. What do you do with the tragedy of the commons? You're deliberately building a commons. How do you make sure that it stays sustainable and it sticks around? So the first thing is that it has to be decentralized and distributed. You have to make sure that no one organization or no one person owns the whole thing. Everybody has to own their own little bit and look after their own little bit. The community groups should primarily just be coordinators helping everybody manage and interoperate with all the other groups. This is crucial, right? Not only does it allow a volunteer group to manage this because everybody's managing their own little bit but it also makes it really hard for a commercial organization or a government or whatever else to co-opt, right? So long as there's no one person that can be taken over or no one company that can be bought or bribed or whatever else, it means that there's no centralized way to take the network down. So the network is free. Again, there's a lot of debate over exactly what should be free. The network is open. Peering should be free. Again, some definition of free across the wireless network. Transit to the Internet may be free and may just be maybe philanthropists that do that for fun and there may be other places where it's just not practical. Right? And then the other part is the actual network growth. There's a lot of research, there's a lot of interest in mesh networks. How do you make networks grow organically? How do you make computers talk to each other automatically and figure out that they're there around people whose access points were in a crucial part of the network and they moved houses? How do you deal with that? And there's a lot of layer 2, layer 3 and even higher layer of smart stuff. Problem is it's all being developed in universities right now. Most of it barely works in a lab and it's really, really crappy in the real world. So now we build this digital commons, right? This is the end goal. How do we secure it? We don't have any physical security. We can't even control who has a cable and who can plug in. We have no control of the hardware. The hardware is commodity. As we grow, all of this only becomes harder. Not only do we have more and more and more stuff to manage, but there's more and more likely to be people trying to fuck it up. Right? How do we control the growth, restrict ban, restrict abuse, allow it to grow and be useful without actually restricting the point of the network which is allowing free exchange of information? That's the problem and nobody really has the answers right now. The kicker though is that if we don't solve it, right? If we don't figure out a way to do this, then the network itself will never reach critical mass. People will never start using it and the services that we all want will never show up on the network, right? This is the final big kicker. We have to figure out a way to solve this problem or all this wireless stuff is pointless, right? We're just going to end up with commercial hot spot providers where you can open up your laptop and check your mail and really who gives a shit. Okay? So this is what we need. This is like a call for help, a call for smart people. This is really, really hard problems. We need everybody out there that cares to try and figure out how to solve it, to play with the software, to work on it, figure out how we do this. So that's pretty much the end of my talk. The slides will be up at www.shmood.com. There's URLs for the people involved. Okay. We're also going to be in the bar afterwards if anybody wants to come talk to us. You want some time? And then finally, we've got an announcement here. The next talk is at 1 p.m. it looks like. It's Nicholas Fishback and he's doing router security. This is the wireless and routing room so there's the tops all day. It should be about that. Thanks for coming. I think Matt from Baywug wants to have a second to say something. First off, folks, let's give these guys a round of applause. This is great. Okay, so you guys heard a rumor that there's 200 milliwatt cards in the house. They are here. We're going to have it in the vendor area. Next to the Apache booth. We're going to be there in about 10 minutes. There's only 100 cards. Got to be there quick. They're 135. They're Prism 2.5 cards. 200 milliwatt straight from Taiwan. So if you're building access points later. These cards kick ass.