On Fri, Oct 10, 2003 at 01:25:24PM -0400, Predrag Radulovic wrote: > On 802.1x... > > The idea of 802.1x traffic NOT passing through the AP - it seems to me a > bit vague. I mean, as a part of protocol the traffic is being > exchanged/proxied (via AP) between the supplicant and the Radius server, > therefore it does "pass" through the AP. There is simply no other way. I > believe there is no difference in that sense between 802.1x on ethernet > versus wireless (switch vs. AP).
Well, not quite. The client's traffic is not passing through the AP. The AP is generating it's own traffic to request authentication from some other source (RADIUS, whatever). I suppose there could also be a user database on the AP itself, in which case there would be no upstream traffic at all until the user authenticated. > It would be possible to have gateway be > 802.1x authenticator, but that would defeat the purpose of denying access > to a user with failed authentication as far on the edge as possible (i.e. > AP). That is if you (really) care about where you block it that much! > (The effectiveness would be not so much different than let's say a VPN.) Well, not quite. If all traffic (even local wLAN traffic) had to go through the authentication gateway (whether the AP or some central, back-end device) then you'd still get the result you want, which is that the client cannot pass traffic except to the authenticator until authenticated. > On the issue of roles... > > Phillipe has talked (sometime ago) about what we do here at U of TN. (We're > still evaluatin Bluseocket, Vernier, ReefEdge, 802.1x and such.). As far > as roles go, one thing we're sure of is that with 1200 or so AP we're not > going to go in a bussines of doing these kind of "favors" to faculty. > If they are worried of students being bored in class, they should make > classes more interesting. No kidding! We had some requests about shutting > down wireless during exams, but there is this thing called peer-to-peer > wireless and also those AP can serve other areas, not just the classroom. Bingo. The Ad-Hoc problem. Yeah... These are the problems I see too. > Managment of those requests is a nightmare. In addition one cannot assume > that just because a student enrolls in a class, that he/she cannot opt to > study in the library instead, but based on role couldn't access resources > due to "being expected to be in classroom". So, assigning roles based on > that might bite you back. Similar situation if you make your LDAP "too > fancy". > > Roles should be more generic like: general user (students, faculty, staff), > visitors (perhaps rate limit, perhaps no access to mail server, etc.), > users who are required to encrypt (people accessing student records and > such), devices authenticated based on MAC only (we have some robots on > campus), etc. You can put bandwidth abusers in a group and rate > limit them, nachi infected users cannot ping, etc. One should not get too > excited about this functionality though! It is a management nightmare! > Keeping things relatively simple made our wireless network very successfull. There are so many possibilities with this stuff. I really appreciate being able to talk about them all. Thanks, folks! 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/.
