Christopher R. Hertel wrote: ...
We just have to convince Cisco that multiple BSSIDs are absolutely required to provide true "virtual AP" functionality so we can support both a non-802.1x network (protected by wireless gateways and VPNs) and an 802.1x protected networks concurrently. Our secondary (802.1x protected) SSID/VLAN network can't be advertised which is a real problem with Windows. I agree that it's next to impossible to support a "802.1x only" network in a campus environment - you *have to* cater to the lowest common denominator to be a success.
That's an interesting approach toward moving into 802.1x. The Cisco's and Symbol's can map different wireless network names to different vLANs, which makes such an approach possible (assuming, of course, that you can enable 802.1x on some SSIDs and not others). That might be an interesting way to test 802.1x. It might also work with our plans to create separate vLANs for our field techs--if we can find workable 802.1x client software.
Question: with the 802.1x-capable network, what do you use to encrypt the data? As I understand it, 802.1x is used for access control only. Am I missing something?
Right, on top of 802.1x, you need an EAP (extensible authentication protocol) methods which are still in development for wireless.
We are planning to use WPA-TKIP (Wi-Fi Protected Access and Temporal Key Integrity Protocol which replaces WEP). Provides dynamic keys (on a per user basis) with encryption key rotation. Much like the proprietary Agere AS2000 and Cisco LEAP without the headaches of supporting an odd client with limited support.
There are still some issues in security with WPA which will get partially resolved with IEEE 802.11i (and better AES-based encryption). The IEEE working group dealing with this (TGi) is behind schedule in releasing this and it's pushed back, yet again, to 2004. IEEE 802.11i (and WPA which is based on draft 3 of 802.11i) rides on top of 802.1x to provide the encryption via key rotation.
Looking into my crystal ball, I would say that Cisco (as the leader in both enterprise and home wireless with the Linksys purchase) will be the one to watch. Even the much awaited 802.11i doesn't solve some fundamental problems like fast roaming and interoperability; but Cisco will because the customer base is asking. So expect a lot of vendors to certify with the "Cisco Compatible" program CCX2. CCX provides a great way to centrally manage a reliable network by having clients assist in rogue AP and inteference detection. I expect that CCX2 will become an "industry standard" with people like HP, Apple and Palm support it (but that is just a wild guess :)
Let's just say that I'm glad we have deployed the Cisco AP1200s ... I still don't see much competition in the enterprise space...
In the near to long term, the 802.1x SSID/VLAN is absolutely strategic for us in providing a safe and scalable wireless network and we will push people as soon as it's fully deployable (hint: as soon as we get multiple BSSID support to make the 802.1x SSID/VLAN "plug and play" with Windows).We are reay to deploy it if our primary network comes under attack but with all the WPA and IEEE 802.11i delays, I prefer to wait a little bit more.
See, I'm just not convinced that 802.1x is a complete and practical solution. You're only talking about Windows. I have a lot of other OSes out there. Honestly, if I were to block a set of OSes from joining my network, all of the recent attacks would make blocking Windows tempting. That won't fly, of course, and neither will blocking PalmOS. I have had people call me with AmigaOS support questions... (The scary thing was that I was able to answer.)
And you are right, large EDUs are in a difficult position because unlike an enterprise we can't mandate a client platform. We've seen everything on our network...
That is why we will always need two wireless networks: an open network with "wireless authenticaion gateway"/vpn authentication type authentication for the lowest common denominator and a much better/safer 802.1x network where the authentication/encryption is done at the edge.
I don't see any other way to service our users. If anyone does, let me know! ;-)
In most EDU environments, we will need to broadcast both networks (hence the need for multiple BSSID support).
We actually want to be able to broadcast more than two SSIDs in order to provide true support for "virtual departmental wireless networks". That allows us to meet individual departmental needs without having to enter into a nightmare RF channel and power management scenario.
802.1x is not Windows only, Macs and Linux are building 802.1x support. Those wanting to do mission critical work will use an OS with 802.1x support on the more secure, 802.1x network. Those who don't care but want wireless connectivity will use the "open" (WG/VPN protected) network.
On a passing note: those preparing RFPs, please include "APs should have multiple BSSID support" Universities need "Virtual AP" capabilities.
It's also hard to imagine operating a large wireless network without some level of filtering at the edge. We implemented DHCP anti-spoofing filters last year (to prevent all sorts of easy attacks) and quickly implemented RPC filters in July after the deadly vulnerability announcement. Wireless users, unlike ResNet users, were immune to the rash of worms that plagued most networks because of filtering at the edge.
If all of the data from the client came through our firewall box then doing what you suggest would be easy for us. As it is, we can't easily filter traffic that is local to the wLAN. Some APs offer such filtering capabilities, but then I'm right back to having to tweak every AP. We can, however, place filters at the VPN server and at the wireless LAN firewall. That helps.
Going back to the "wireless transceiver", I would really prefer it if APs would act as transceivers instead of hubs. If all AP traffic were sent up the wire then the back-end device could handle all authentication and authorization. It could also filter all flows, which would also be nifty. The end product would also be less expensive.
Adding some extra processing power and memory to a transceiver style AP would result in an AP like the ones we have today, so it would be a no-brainer for a willing vendor. I am hoping that someone will do this with the new Atheros chips.
With this architecture, I'm almost convinced that you would be vulnerable to ARP attacks. If you are open to ARP attacks, it doesn't sell for enterprises and you won't see vendors creating highly specialised products just for EDUs. It was a good idea though - but with the ARP insecurity issues on the LAN, you do have a problem.
We also feel that segmentation by "campus wide" VLANs is the way to provide seamless campus wide roaming and the required longer term scalability. That means APs that properly understand VLANs.
With a transceiver-type AP, the back-end device could handle the vLANs. :)
Okay, one feature that would be nice on a transceiver type AP would be GRE tunneling. That way, it doesn't matter where you deploy the AP. It would tunnel all packets to either an intermediate device or directly to a central controller.
Check the blackhat.com presentations on GRE attacks. The only way I see this working is if you uses highly specialised (and proprietary) switches. That stuff doesn't sell as well as far as I'm concerned.
....
Thanks for the interesting conversation. I really enjoy seeing these things with something other than my own eyes.
Chris -)-----
Ditto. UBC has been absorbed completing its large scale wireless deployment but we should be able to be a little more active on the list.
Some of the issues going forward are very EDU specific (like the multiple BSSID requirement).
............................................................. Jonn Martell, Wireless Network Project and Service Manager University of British Columbia - ITServices 420 - 6356 Agricultural Road, Vancouver, Canada, V6T 1Z2 (604)822-9449 [EMAIL PROTECTED] http://www.wireless.ubc.ca
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/cg/.
