Chris, that's an interesting concept, that BYOW (Bring Your Own WIFI)
#Did it create itself over time because the campus never decided on a centralized deployment? #How do you learn about popping APs? ARP discoveries, Driving around with WIFI-Sniffers, A policy about WIFI on campus? # How do you accomplish roaming, channel management (or interferences management) ? # Do you charge a special fee for Wireless VLAN or you leave it free as an incentive for people to report their APs? Philippe Hanset University of Tennessee On Fri, 10 Oct 2003, 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/.
