Student Network History & the Gaming Network Plans
- History of the Student Network
- How are we handling the DNS
- What will users see?
- How to 'fix' 'valid' sites that are not 'allowed'?
- How do you explain the difference between 'gaming systems' and 'Exempt'?
- Why were no announcements made previously?
- What if my system stops working on September 26th?
History of the Student Network
When networking was first put in the ResHalls about 1997, IP addresses were statically assigned _one_ to each user. If you had a special academic need, a 'waver' from your department office was needed to allow a student to get a second IP. All IPs were 'real IP' with 'full access' to the Internet.
This 'all systems open to the Internet' configuration resulted in a number of problems. At the time, most students did not have any type of Anti-virus installed and (for the most part) did not know much about 'administering' their system. We had a number of incidents where viruses infected many of the machines in the ResHall network including one time where parts of the ResHall network were shut down for three days while all machines were 'cleaned'.
In the early 2000's, ITU created the 'MUST' system that forces users to have Anti-virus installed, their systems to be up-to-date and updates to be automatically installed. We also changed the configuration so most users were 'Protected' (NATted) behind new equipment (just like most home users are). All users also had the option to have 'real' (Unprotected) IP instead. During the initialization process, the user selected which type of address they wanted to use. They were also allowed to register more that one device. IP assignment was done via DHCP. Registration ('Protected' or 'Unprotected') was done by MAC address. Devices that could not perform the registration process where added to an 'Exempt' list that provided those MACs IPs from the 'Protected' pool only. This resulted in three 'Classes' of devices. The combination of requiring Anti-virus and the NATted configuration greatly reduced the number of infected/compromised systems in the Residence Halls.
Around 2007 the makers of the network equipment that was being used decided they would no longer sell or support the equipment. With the continuous construction of new housing units, a new solution had to be found.
ITU reviewed and tested a number of different Network Access Control (NAC) solutions and the current system was selected. It should be noted that _none_ of the currently available solutions provided the same flexibility and options as the system that was being used. One 'problem' all of the solutions had was that they either required software to be loaded on the system or a web portal used to 'authenticate' the user.
At the same time, there was an increase in the number of 'game systems' (Xbox, Playstation, Wii, etc) that were being installed. Many of these devices did not have web browsers and these devices were put in the 'Exempt' Class. It was then found out that many of the Network based multi-player games would not work in the NATted environment. A new 'Class' of devices was created to allow these devices to have real IPs.
Because of the dangers of having these devices exposed to the Internet (and to reduce the possibility of abuse by non-game machines), this network was configured to only allow certain game related 'sockets' to work. The overhead in managing the opening the various sockets used by each game became so high that during the Spring 2010 semester, the network was changed to allow all sockets to work. (Each game, even by the same manufacturer, seem to use different sockets and which sockets were being used was not always provided to ITU. In most cases, ITU had to review which sockets were being dropped by the firewalls to determine which ones to allow.) This presented a possible security problem (if they knew the MAC of a registered game machine, a person could have uncontrolled access to and from the Internet) but dealing with that problem was determined to be easier than the added work of determining which sockets to open up. ITU also had a new idea on how to prove some level of control on the game system network. (At the time, ITU was preparing to move the Data Center to the Aquia Building and all Engineers were needed to prepare for that.)
The Residence Hall network now consisted of four 'different networks' based upon 'Classes' that were a result of the two binary choices available: protected vs unprotected and 'can authenticate' vs 'cannot authenticate'. Most user's PCs are in the 'Protected' Class - they have NATted IPs and require authentication (either via a web login or an Odyssey client). Those that want or need to have 'real IPs' on their PCs can choose to be in the 'Unprotected' Class - they have 'real IPs' and still require authentication to access the network. As before, most systems that cannot authenticate are (or should be) in the 'Exempt' Class - they have NATted IPs but do not require authentication. For most purposes (like viewing videos or normal web browsing) this network should provide the same 'look and feel' from the Internet as a home DSL or Fios connection would behind the 'home router' that is provided. The fourth 'game system' Class was intended to be used only by systems that could not work under the NATted environment - they have 'real IPs' and do not require authentication to access the network. These systems should only require access to limited locations that are used to locate the 'server' for the games they are playing. Each system should only need to resolve a hand full or so of DNS names. If people that somehow got their PC systems on the 'game system' network could not resolve DNS names, they would not want stay there and would have their system placed in the appropriate other Class.
That is what ITU intends to do on September 26th; restrict the DNS resolution from the 'game system' network to only 'game system related' domains. Starting before the beginning of the Fall semester, ITU has been logging the domains that are being requested by devices in the 'game system' network and creating the entries required to allow resolution from domains that appear to be 'game related'. We will not be allowing common domains like Facebook, Google, Yahoo or Hotmail. We are allowing domains like Nintendo, Sony, Netflix and Zune.
We currently have 50 domains already configured to work. We will continue to check these on a daily basis for the first week or two after the 26th to identify those domains that need to be added. After that, the Support Center will create tickets to have new domains allowed much like they did last year to allow new sockets to be opened. This does require the 'game system' owner to make a decision on how they intend to use their 'game system'. If they are using it to play multi-player games that require 'real IPs', they will not be able to use that same system to read their email. ITU has to provide some sort of 'control' over the 'game system' network. ITU has tried other methods and this is the one we are trying now.
One issue that has been found recently is people registering their computers to the 'gaming network' since it doesn't require authentication. These systems will no longer have DNS resolution after September 26, and will find this network not as useful as it has been. We are in the process of finding such users and contacting them to discuss what they are doing and why.
What was found out last week was that _all_ game systems were being put in the 'game systems' Class and not just the ones that 'needed' to be. Because of this, many user devices are not in the correct Class as the networks were designed. After the 26th, this may require that some devices are moved from the 'game system' Class to a different Class.
This information is being passed along because it is important that students understand that we don't just make decisions on the fly with out thinking about them. We have to keep a balance between providing a secure and safe network (for those that cannot 'protect' themselves) and providing a network that can provide the needs of the Resident population. Some similar sized universities don't make any exceptions for game systems - "if it doesn't work, tough luck". We do understand this is your 'home' for the school year. We do try to allow you to do most things that you could do from your actual home.
We hope this explains why we are making the change on September 26th. If you have any questions about this change, or anything about networks and Mason, please let us know.
Why were no announcements made previously?
No announcements were made as we were trying to clarify how the system would work, verify that it would, as well as minimize the amount of people that were exploiting the current system as it was being developed.
How are we handling the DNS
The 'game system' network has been modified to only allow DNS queries to the bottom tier DNS servers sent via DHCP. We have created a separate 'view' for the 'game system' networks. Rather than having all queries forwarded to our second tier DNS servers, we will only be forwarding the 'selected' domains. We currently have 'the default' rule forward to these as well. On September 26th, this default rule will be changed to forward the requests to, basically, no where. This will allow the bottom servers to only resolve the domains we select.
What will users see?
Some sort of 'cannot connect to server' message _should_ be presented by the browser but the exact result will be system specific. There will be no 'cannot go there' message from SNAP. (The methods for doing that are OS specific. If we could tell, on the fly, the OS, then we would have other options to block traffic from PCs and not from Wiis and PS3s etc.)
How to 'fix' 'valid' sites that are not 'allowed'?
We have been checking the domains used since before classes started and added a total of 50 domains to the 'allowed' group. We ran the check script again on September 24. It is possible that the script is not fool proof.
A little on how this works. We turned on logging of all DNS queries. It records what DNS name is trying to be resolved by which IP. We pass the log files through a number of filers to remove lines that are either known good and already have the 'DNS allow' in place (like playstation.com) or ones that are known 'bad' (like 'hotmail.com'). If a system showed up that appeared to be 'browsing' and not 'gaming', we filtered on that system by IP rather than create filters for each of the domains they were going to. If only one or two people were accessing a particular site and they also were doing a lot of other obvious browsing, all entries from them may be filtered. We can say that since Sunday night, no one in the 'game system' network has tried to go to animeseason.com.
We have increased the logs to hold about 5 days of queries. Getting new domains added will be like it was last year to get new sockets opened. Given the date, time and MAC of the system, we can determine where they were trying to go. If it seems reasonable for a 'game system' to go there, it will be added. We are already allowing Netflix and Zune. If other sites like this show up, they will be added.
How do you explain the difference between 'gaming systems' and 'Exempt'?
That is one of the
things we don't quite have worked out. When this method for provide control on the 'game system'
network was devised, we thought that the only devices that were going into the 'game system' network
were those that needed to be there for multi-player games. We thought this 'problem' was already being
addresses. It wasn't until an email was forwarded to our group that we found out that _all_ 'game systems'
(including a person that had put their PC in the 'game system' network because they played 'games' on
their PC) were being put in the 'game system' network.
We thought the distinction was simple:
Are you using your game system to play multi-user network games? If the answer was not 'yes', then they go into 'Exempt'.
If they later find there are games they cannot play, they have a choice: a) move to the 'game system' network and give up general browsing or b) stay in Exempt, keep general browsing and don't play these games.
What if my system stops working on September 26th?
Please contact the Support Center. They will ask a series of questions so we will know what 'network' to put your system in to allow it to work as best as possible.
