Engineering February 2005 Report to CNAG

New CNAG Rep

Erick Engelke is currently taking over CNAG duties for Bruce Campbell who has moved to Science. The temporary reduction in staff has been challenging.

Networked Computer Security

There are a large number of unmanaged or undermanaged computers on campus, including many servers. This is a huge drain on staff time, and needlessly interrupts or slows reasonable faculty and student activity.

EC is taking a pro-active approach to increase the security on all Engineering systems by engaging the departments on the topic of security, best practices and future planning.

Wireless - TTTS

The NAA TTTS has had an incredible effect on the reports of wireless overages. By essentially eliminating overusage complaints, the support headaches of chasing users has also been eliminated, saving us a lot of needless administration time and leaving us with happier users.

The TTTS encourages self-correcting behaviours, users find downloading DVDs doesn't work and they give up doing that, but doing schoolwork is unaffected. The metaphor is easy to understand, though the name may sound kind of funny.

Someone asked me to explain the ResNet strategy for dealing with network overusage compared to the TTTS. ResNet resembles a cliff to a lemming, you seem to be able to run full speed, then suddenly you drop and don't know what hit you.

Wireless Security

We still see quite a few incidents of wireless machines trying to spread virii or otherwise attack campus machines. We should consider tightening the wireless access in several ways:

eliminate simple plain text protocols (particularly TELNET, FTP)
phase out vulnerable protocols (RPC, SMB, etc.), may have to happen on a term boundary and with user education, we can use the NAA to display suggestions and even links to workarounds
encourage the usual encrypted protocols (ssh, sftp and similar, https, imaps, rdp)
support encryption - doable today

OpenVPN - client uses SSL to encrypt network traffic. Downside, like most VPNs, requires client install and OS privileges.
SSLExplorer - client uses Java in web browser to encrypt data, does not require installation of drivers or applications, not limited to any particular OS or version! Documentation online. I have spent some minutes with this, it's interesting.
or buy a VPN, but same issues exist:

SSL VPN options (Nortel , etc.)
OS VPN options (Cisco, etc. )

If we do buy a VPN product, it makes sense to buy a best of breed rather than something from an upstart which tend to just cobble together the same low cost technologies we would implement in our own creations. Also, due to the processing requirements of the VPN, it is almost required for the VPN to be a separate machine from the router which routes wireless. VoIP over wireless will require decent latency, but if the router is also the VPN, it must not slow down VoIP traffic. By separating the router from the VPN we also can scale better because we would add capacity where and when we need it, rather than having to delay until we can upgrade the whole big mess at once. Also, not all VPNs are compatible with all our clients. Few can deal with VoIP phones, WiFi PDAs, WiFi blackberries, embedded WiFi products, etc. We need to have flexibility for the future, and that comes from being able to define our needs now, and being able to adjust our definition in light of new technologies which we don't know yet!

consider a MOTU : "message of the user", an enhancement to the NAA which would allow us to save a message (or url) for particular users with a message which would be displayed at wireless login. For example, user: jblow may be informed that their last session appeared to contact Market Research or something similar, and give a URL on where to find more information about the risks. The MOTU could also be used for the next 1.5 months to give directed warnings to known users of plaintext passwords that they should start to migrate.
use a snort-like technology to automate some of the threat detection
alternate entry points into existing systems:

Engineering has two Windows terminal servers on Nexus. Users from our faculty can use RDP to exchange files or do various operationgs and don't need RPC/SMB for that.
CUPS has been running on one of our Engineering servers, we can direct Engineering wireless users to print through CUPS rather than the usual Windows protocols - also works from home.

Our present NAA subnets don't make sense. We should consider a different subnet size so that the wireless community can grow without being bound by 245 station limits on each subnet size.

Overall, the flexibility of the NAA is very important. We can make suggestions on any aspect and get quick results to deal with problems. The only change from Engineering's perspective is that we plan to outsource most of our NAA administration to Science.

Vernier

On Vernier, IST says {DP} Decision now required on whether to keep the Vernier units that are currently here for the "demo" period. We would only keep those units if we plan to migrate, I haven't seen a CNAG recommendation that the Veriner solution be adopted, presumably we will discuss that at the February or subsequent CNAG meeting.

Architecture

Architecture is re-joining Engineering. We will be reviewing networking along with all other issues to make it more consistent with the Engineering model.

Erick Engelke

February 14, 2005