That's an interesting concept: one of centrally managing a ton of different APs, firmware, etc. Gives me a headache just *thinking* about it! How many "managed" APs do you now have? How many FTEs do you expect to need to manage all these different types of APs?
We almost went down that route and peppered the campus with cheap $100 AP but when we looked at cost of ownership and reliability; it was a clear case of "pay now or pay later". And that was using a single vendor's cheap AP solution!
We now have over 1400 devices on our wireless network and I don't know how one would begin to manage these if they weren't nearly identical.
The way that we dealt with the rogue AP issue was by centrally funding the network and deploying very quickly. And we are done! The last remaining areas are student residences (wish me luck - I need it! :)
We are positioned for today's requirements and can scale up with campus wide VLANs with APs that support multiple VLANs/SSIDs. I have a CD from Silicon Chalk on my desk for example where the application uses broadcast/multicast - that's a perfect application for a special "learning" VLAN/SSID (we limit/manage broadcasts/multicast on our large campus-wide primary SSID/VLAN).
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.
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.
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.
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.
One last note: I do agree that a policy manager is a neat concept but one that is very hard (or impossible) to implement in a full coverage environment where airwaves don't stay in a particular room (or building!). Doing it on a per-user level might work but that doesn't prevent users from borrowing someone else's ID. I just see support issues with this.
PS We use the cheaper Colubris CN3500: Bluesocket didn't support Public CA SSL support when we evaluated it.
............................................................. 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
Christopher R. Hertel wrote:
On Fri, Oct 10, 2003 at 11:10:54AM -0400, Sean Che wrote: :
802.1x traffic should NOT pass through AP. What I said is that 802.1x can pass through Bluesocket. In this case, the link between authenticator(AP) and authentication server ( Radius Server) is transparent, even thought bluesocket box sits between them.
FYI, here's the authentication process of 802.1x:
* The client may send an EAP-start message. * The access point sends an EAP-request identity message. * The client's EAP-response packet with the client's identity is "proxied" to the authentication server by the authenticator. * The authentication server challenges the client to prove themselves and may send its credentials to prove itself to the client (if using mutual authentication). * The client checks the server's credentials (if using mutual authentication) and then sends its credentials to the server to prove itself. * The authentication server accepts or rejects the client's request for connection. * If the end user was accepted, the authenticator changes the virtual port with the end user to an authorized state allowing full network access to that end user. * At log-off, the client virtual port is changed back to the unauthorized state.
Think about that.
In order for that to work all of the APs must support the system completely. Consider:
* The APs that do support 802.1x are more expensive, which makes a difference when you multiply by 1000 APs. (...and that's just for starters. We have a big campus.)
* There are hundreds if not thousands of APs on my campus already that don't support 802.1x. Folks just pop out on their lunch hour and buy a new AP at the discount store for $70 or less. They get back and plug it in. It's hard enough convincing them to use the standard SSID and hook up the auth server. Many of these APs won't be upgradable to run 802.1x.
* The more APs I have the more APs I have to manage. The more features the AP has the more of a pain it is to manage it. I want my APs dumb and simple. If I could get APs that were little more than a transceiver that would be very, very nifty.
* On the client side, all of the clients would have to support 802.1x in order to make it a viable solution. We have a diverse client population that includes MacOS, *BSD, Linux, PalmOS, Symbian, even MS-Windows... I'm sure there are more. Until all of these (and those I've missed) support 802.1x I cannot deploy it. I would be blocking access based on the user's client platform choice and that just wouldn't fly. (We tried recently to block all Windows filesharing ports to prevent virus/worm spread, but there was this small, vocal minority...)
In short, 802.1x is currently impractical on my campus.
Instead, we have tried to move complexity in the wireless network toward the center. Our goal is to make it easier to manage the network, easier to accomodate a wider variety of clients and APs, easier to make changes, troubleshoot, etc.
Our architecture is quite simple. The APs are placed onto a vLAN that is also connected to a firewall system. The firewall (FreeBSD with IPFilter and a custom Divert daemon) blocks access to the campus network. Users must bring up a browser and try to connect to a web page (on or off campus). The connection is redirected to an HTTPS web page that requests authentication. If the authentication is successfull, the custom Divert daemon allows packets through.
The firewall also has a hole poked in it to allow connections to our campus VPN server, so that users can choose to use a VPN connection instead. The VPN server also requires authentication.
This works well enough (though it's not perfect). If the APs would send all packets (even local traffic) to the back-end firewall then we could prevent un-authenticated local wLAN access as well. Again, a simple wireless to wired LAN transceiver would be really nice here.
Curious... I've heard people talk about this (we've taked with the Reefedge folks about their product, which we liked) but I don't know of any practical applications. How would you use this? (Probably obvious but I haven't thought it through.)
Here's an example: if we would like faculty to have access to the wireless network 24 X 7 but we don't want student to use wireless laptop surfing unrelated webpage during class hours in classrooms , we can use those fine-grained control feature of bluesocket to implement that. All we have to do is to define different objects ( roles, users, locations, destinations, schedules etc) and apply rule/policy with them.
I can see that this feature would be useful in implementing such policies. The problem, then, is how to establish those policies and how to ensure that the enforcement of the policies is properly contained.
It would be hard for us to implement the example policy you describe because we have many APs that serve two classrooms and/or hallways etc. Some APs leak signal through several floors in some buildings (it all depends on construction) so we would have to be fine-grained enough to know which students are in which classes at which hours. That's way too much fussing for a campus our size.
Chris -)-----
-- Christopher R. Hertel -)----- University of Minnesota [EMAIL PROTECTED] Networking and Telecommunications Services "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/cg/.
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/cg/.
