Child pages
  • Wireless Network Roaming for the University of California

Wireless Network Roaming for the University of California

As an outcome of the February, 2010 ITLC meeting, the Communications Planning Group (CPG) was asked to work with the UCTrust Work Group to prepare a recommendation report evaluating the viability, risks, and  cost at an institutional level for a common wireless authentication  and access methodology to allow any member of the UC community to use  the wireless networks of any other UC entity without need for creation of guest or visitor accounts.

In the May, 2010 CPG meeting, it was decided to create a work group to pursue this issue.  David Walker agreed to convene the group, and 19 members were drawn from six campuses and one medical center: UCB, UCD, UCD Health System, UCLA, UCR, UCSD, and UCSC.

Initially, the group pursued a strategy of leveraging UCTrust to federate the "captive portals" that each campus uses to authenticate users to their unencrypted networks. During this time period, however, eduroam-US, in partnership with InCommon, became a viable alternative.  We determined that eduroam-US is a better alternative for the following reasons:

  • eduroam-US will, eventually, extend wireless roaming for UC travelers to institutions throughout the US and Europe, not just within UC.  As such we believe it will be come a de facto standard for higher education.
  • The cost to implement eduroam-US is relatively small for campuses with an 802.1x infrastructure for encrypted wireless Ethernet.  While not all campuses currently have such an infrastructure, all participating campuses plan to create one. Some of the campuses that did not participate, however, anticipate difficulty to implement and operate 802.1x.that could delay their participation.
  • While eduroam-US is new, and there are policy and operational issues it must resolve (see below), we believe that it will resolve those issues.
  • Federation of captive portals is new. If UC were to follow that strategy, it would need to do its own development work in most cases.  In other cases, negotiation with vendors would be required. UC has experience with federating applications, and we know the cost is manageable.  This project, however, would involve federating 12 or more captive portals, depending on which locations participate, so the effort is much larger than most.

The Plan

The participating campuses plan to join eduroam-US over the coming 12 months (by September, 2011), and we will work within the eduroam-US organization to resolve issues we have identified during our deliberations.  We encourage the other UC locations to join eduroam-US (scheduled according to local priorities and tolerance for eduroam-US's maturity) to enable wireless roaming among all UC campuses. The following chart shows a quick estimate of campus readiness; firm estimates will require further investigation..

Campus

Quick Estimate

UCB

Can implement eduroam within the next 12 months for the portions of the campuses with WAPs that support it.

UCD

Plan to implement by the end of 2010 for centrally-managed portions of the campus. 

UCI

Currently testing.   Planning on implementing on August 15, 2011.

UCLA

Testing now. Plan to implement by the end of 2010 for centrally-managed portions of the campus.

UCM

Have an 802.1x wireless network.  Ability to deploy AES will require more investigation.

UCR

As of 2012, eduroam is available campus wide and authentication is available for UCR individuals traveling elsewhere.

UCSD 

Can implement campus-wide within the next 12 months.

UCSF

Can implement within the next 12 months.

UCSB

Can implement 802.1x, but does not plan on adopting eduroam until there is substantial progress in resolving the operational and management issues.

UCSC 

Can implement eduroam within the next 12 months for the portions of the campuses with WAPs that support it.

UCLA and UCD will be first with implementations planned by the end of calendar year 2010.

Issues Associated with Federated Wireless Guest Access

The following issues have been identified as needing to be addressed as we role out federated guest wireless services.  We will work within eduroam to detemrine suitable resolutions.

  • Host institutions may require information about their guests.  This information is used to communicate with guests in the following situations:
    • A security vulnerability is suspected on a guest's computer.
    • A copyright infringement notice is received for a guest.
    • A security investigation involves a guest.
  • Host institutions may desire to present local information, such as its network policy, to guests.
  • A wireless guest access federation needs policies to govern operational issues and other interactions among its members.

Most campuses also have the issue that not all of their wireless access points support the eduroam specifications, specifically AES encryption.  Also, most campuses have wireless access points that are not centrally managed.  Of necessity, eduroam access will not be available from all wireless locations at all campuses.

While not specifically an issue for federated access, the implementation and operation of 802.1x and encrypted wireless access requires resources  More specifically, there are concerns that implementing encrypted wireless puts strain on users having to perform client configuration, and in turn this will place additional strain on the help desk. We will evaluate XPress Connect from Cloud Path Networks, among other solutions, for use with eduroam.

Workgroup Membership

  • Robert Cartelli, UCSC
  • Dedra Chamberlin, UCB
  • Patrick Flannery, UCDHS
  • Bob Grant, UCR
  • Chris Hain, UCD
  • Russ Harvey, UCR
  • Stephen Hock, UCR
  • Erik Klavon, UCB
  • Gabe Lawrence, UCSD
  • ken lindahl, UCB
  • Jim Madden, UCSD
  • Jeff McCullough, UCB
  • Dave Parsons, UCLA
  • Mark Redican, UCD
  • Andrew Tristan, UCR
  • Mike Van Norman, UCLA
  • David Walker, UCD, convener
  • David Wong, UCD
  • Albert Wu, UCLA
  • No labels