BYOD: Lessons On Negotiating Limits

You can say no to BYOD, but be prepared to enforce your decision -- and find alternatives to meet your users’ needs.

Julian Y. Koh, Associate Director, Telecommunications & Network Services, Northwestern University

January 7, 2014

4 Min Read

The challenges of Bring Your Own Device (BYOD) are a hot topic in enterprise networking. For those of us in higher education, BYOD has been the normal mode of operation since we first began rolling out networks. And one thing we’ve learned is that you can negotiate limits on personal devices, as long as you’re prepared to enforce your restrictions and find other solutions for your constituents.

The biggest BYOD population at Northwestern University, where I work, is our ever-rotating group of students. Of course, faculty and staff also try to connect almost anything to our campus networks. Our primary campuses in Evanston and Chicago have over 50,000 active Ethernet network ports and over 3,000 802.11n wireless access points. The network serves over 200 separate buildings, 19,000 students, 3,800 faculty, and 4,000 staff.

Our network, like those of many large research institutions, has been built with a philosophy of open standards and open access. On the wired network, any device that supports Ethernet and TCP/IP can connect and have access.

On the main wireless network we standardized on WPA2-Enterprise authentication and encryption, so any device that supports that standard can connect securely. We also have a guest wireless network that doesn’t provide encryption or authentication but does require users to register each week.

However, even with a policy of open access, there are devices that we can’t support on our network. The first category of prohibited devices are what we call "network extensions."  These include hubs, switches, routers, and access points that aren’t managed by the central Northwestern University Information Technology (NUIT) organization, as well as individual devices that are configured to act as network extensions.

This restriction is especially important on the wireless network, where there are a limited number of RF channels available, especially in the 2.4GHz frequency band. Thus, any device that creates its own wireless network is not allowed because of the widespread impact that device could have on other users.

While all users agree to these restrictions as part of onboarding and registration, in practice they’re incredibly difficult to police, especially as all sorts of consumer devices behave in this fashion, ranging from printers to Chromecasts. Typically we find such devices as part of troubleshooting performance issues that are reported by other users.

The next category includes devices and applications that don’t operate correctly in a large enterprise network setting. A prime example is Apple TV and other Apple products that rely on the AirPlay protocol (Bonjour, Rendezvous, or ZeroConf), but other examples include Universal Plug and Play (UPnP) devices.

The AirPlay protocol assumes that all devices reside on the same IP subnet. While the major wireless vendors are releasing updates to their products to work around this limitation, and Apple is working with members of the higher-ed community to account for enterprise networking with the next version of AirPlay, supporting these devices on our networks remains extremely challenging and time consuming.

Having said that, given our philosophy of open access, we do have a responsibility to work with our constituents and customers to understand their needs and requirements and try to come to some solution that will work for everyone.

For example, we have assisted users (primarily faculty and staff) with Time Capsule backup devices to connect them to the wired network, instead of having them create their own wireless networks. We’ve also set up separate wireless networks for use with AppleTVs and other specialized research projects.

We also consult with departments that are renovating office space to ensure that the appropriate number of wired Ethernet ports are available so they don’t feel like they need to hook up their own switches.

Looking to the future, we are investigating solutions that will let any user, including students, register AirPlay devices on the wireless network and enable sharing them with specific sets of users.

This kind of engagement with your constituents is the key to an effective BYOD strategy. Users, especially those in higher ed, typically do not respond well to unenforceable edicts that are not appropriately justified. A collaborative, flexible approach will often lead to new and exciting uses for your network and applications, as well as a robust and well-managed network.

Engagement can take place both proactively and reactively.  Sometimes conversations have started as a result of our investigation of trouble reports. Other times, we have been approached by faculty who want to install new devices. We also reach out to schools and departments that we know are interested in trying new applications.

I’ll explore the issue of BYOD restrictions and negotiations with users in higher education at Interop Las Vegas in the session “You Can Say No to BYOD.” In the meantime, I’d like to get your input on how you address personal devices on an enterprise network. Do you have a policy of openness? Are there devices you simply refuse to support?

About the Author(s)

Julian Y. Koh

Associate Director, Telecommunications & Network Services, Northwestern University

Julian Y. Koh has been at Northwestern University in one way, shape, or form for the past 25+ years, first attending summer camps during middle school. He was introduced to IT as a student worker at the NU computer center in 1995 and joined the NUIT Telecommunications and Network Services team as a full-time network engineer after earning his BS in biomedical engineering in 1997. Over the years, he has participated in or overseen the installation of multiple generations of network backbone technology (LocalTalk to FDDI to ATM to 1G/10G/100G Ethernet) as well as numerous network-based services such as IPTV, VPN, and information security incident response. Julian also earned an MS in information technology from Northwestern in 2001. He is currently responsible for the voice, video, and data network engineering teams for all of Northwestern's US-based locations.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights