Our current registration process is still pretty crude. When a Student registers for access to our "Wireless Gaming Network" (registration is done via a secure web page using their campus network account credentials) they provide their Name, Email, Room #, Game Console Type (We currently only allow for Nintendo Wii, DSi, DS; Sony PSP, PS3; Xbox, Xbox 360) and finally the MAC address of their console.
For now, since the number of Students requesting access to the Gaming Network is fairly small, we manually verify that the Student hasn't already registered a console of the same type and also check to see that the MAC address matches a known range for the vendor. I generally use http://www.coffer.com/mac_find/ to verify MAC addresses. I suppose it wouldn't be too difficult to automate the process by parsing the output in a script, but with the number of requests we currently process it isn't worth the work. If you're using MAC filters within NAC it should be possible to utilize the Clean Access API to automate the process of adding the MAC addresses to the NAC filter as well. This would have to be combined with some kind of logic to prevent registration of multiple instances of the same device type by the same user (i.e. one person registering Xbox 360s for 50 of their friends who aren't themselves registered Students). We have a Cisco WLAN infrastructure along with NAC. Here's how I have set things up for Student Gaming: § A separate SSID is used for the Gaming Network § MAC address filtering is done via our WISM. Only MAC addresses in the filter list are able to connect to the Gaming SSID. o One of the reasons we did this was that we were finding Students with PCs constantly connecting to the Gaming Network not knowing what it was and then complaining when they couldn't access anything (Initially we implemented MAC filters via NAC). This way they can't even connect to the SSID. § The Gaming Network is assigned to a separate VLAN/IP Subnet. § A NAC role was created for the Gaming Network. § A NAC Subnet Filter assigns any device on the Gaming Network Subnet to the NAC Gaming Role. § Access to College resources from the Gaming Role are blocked via NAC (Running in Real IP Gateway Mode). § Access to the Internet is not restricted (aside from Packet Shaping via a PacketShaper), it was too cumbersome to keep up with different layer-4 access requirements of various games. o I suppose we could block popular non-gaming sites (youtube, facebook etc) as a means of discouraging spoofing. o I haven't discovered anyone successfully spoofing a gaming console as of yet, but it is a bit tedious to scour logs looking for signs of spoofing, and the NAC admin console is of no help. When using filters (MAC or Subnet) within NAC, the devices don't show up in the "Summary" or "Online Users" within the NAC admin console since there is no user tied to the device. Also they don't show up under "Certified Devices" because filters bypass posture assessment. Individual devices added to NAC via a MAC filter can be viewed under "Filters>Devices>Active>Show All" but devices filtered by a Subnet Filter are never displayed. It would be nice if Cisco would make it easier to find filtered devices within NAC, ideally in a consolidated view. So we have "solved" the problem of dealing with layer-3/4 access management by going with the bassackwards security approach of allowing access by default and blocking what we want. Not ideal, but at this point I see it as an acceptable tradeoff given what should be a somewhat reduced risk pool of devices (compared to unmanaged windows PCs at any rate) that are at least logically separated from other devices. Unfortunately unless a device can at least access a browser-based login page without first needing access to other internet resources (Xbox Live, PlayStation Network etc) I don't see us able to do away with MAC address registration/filtering and the horrendous management that goes along with it. The only way to abandon MAC registration/filtering all together would be to give up on requiring user authentication, which in most cases is an option that will cause even more headaches in the end. _____________________________ Robert Biddle Network Systems Engineer / Administrator College of Mount St. Joseph From: Cisco Clean Access Users and Administrators [mailto:[email protected]] On Behalf Of McIntosh, David Sent: Thursday, May 27, 2010 10:52 AM To: [email protected] Subject: Gaming Device registration All, We are looking for possibly a new method for the way in which we handle the registration of headless devices such as the Nintendo Wii, Xbox 360, Playstation 3, TiVO, etc. For the last 5 years we have relied on a web-based form that students have accessed to provide registration information including their name, type of system, MAC address and device description. When students filled out the form the MAC address they entered was checked against a range of known MAC addresses to verify what they were registering, and if the range didn't fit they were asked to either correct their typo, or come into our remediation center for verification. In this way we hoped to minimalize the registration of computers as gaming systems in order to bypass CCA. Up until recently we have been fairly successful in maintaining a list of ports to allow open access to, and MAC addresses that correspond to the various systems. Unfortunately, we have reached the point where it is simply impossible to keep up with all the new MAC address ranges for the new systems as they come out to prevent being overloaded with walk-in traffic looking for verification. Furthermore, with the addition of applications to the newest platforms, (NetFlix, Web browsing, e-mail, etc.) it became increasingly difficult to monitor the ports that we needed to keep open, resulting in our being completely overwhelmed. The quick fix to this was simply to open the gaming role to all ports, however, this was done without the knowledge that the MAC address checking fail-safe had also been disabled. This summer we are implementing various changes to CCA, including an upgrade, and are looking for idea to re-work how we have been managing our gaming devices. I'm interested in hearing anyone else's solutions or anyone ideas for the continued management of these devices so we can, hopefully, abandon the system of managing ports and MAC addresses. David McIntosh IT Services Miami University
