The Captive Portal team, consisting of staff in IST Infrastructure Services, is developing a replacement for the current authentication system used with AirBears. This announcement includes important information about this new system and the changes it will bring to AirBears.
About the new captive portal
The core technology of the new captive portal was developed by Residential and Student Service Programs (RSSP) for use with the wireless network it operates in the residence halls. The system is based on open-source software and runs on FreeBSD. RSSP has operated the core technology as part of its captive portal system in production for more than a year. We are grateful to RSSP for sharing this technology and for the assistance of Chris Cowart in helping us adapt it for use with AirBears. The Captive Portal team will be responsible for any deficiencies in the captive portal system used with AirBears.
The process of authenticating to the new captive portal will be similar to the current captive portal. After associating a client device with the wireless network, all http requests from the client are redirected to a landing web page. After successfully authenticating via CalNet or a guest account, the new captive portal displays a confirmation page. Full access to the campus network is available after authentication. One may log out of the wireless network at any point using a URL provided in the confirmation page.
In two important ways, the new captive portal differs from the old.
CalNet and guest account authentication
The new captive portal uses CAS for CalNet authentication and supports single sign-on. If you do not have a valid CAS ticket when you attempt to log on to the wireless network, you will be redirected to the CAS login page to authenticate. If you have a valid CAS ticket when you attempt to authenticate to the captive portal, you will be directed to the confirmation page — you will not need to type in your CalNet ID and passphrase. After authenticating to AirBears using the new captive portal, you will hold a valid CAS ticket and will not need to authenticate again to web applications that support single sign-on using CAS.
At present, guest account authentication is implemented using a form hosted by the new captive portal. The landing web page of the new captive portal presents you with a choice of two authentication methods: CalNet or guest account. We are working with the CalNet team to allow CAS to authenticate AirBears guest accounts. This change will eliminate the need for separate authentication methods for guest and CalNet accounts.
Screen shots of the version of the new captive portal interface are available at https://bspace.berkeley.edu/access/content/user/106466/screenshots. Please be aware that this is a minimal development interface and that the final version will likely differ somewhat in appearance.
Use of RFC 1918 address space and Network Address Translation (NAT)
The campus has a finite assignment of globally routable IPv4 addresses and we are unlikely to receive any further assignments from ARIN (American Registry for Internet Numbers). Ten percent of the campus's allocated IPv4 address space is used by AirBears. The new communications network funding model, if adopted in its present form, will continue the expansion of AirBears and with it the use of address space by this service.
We've observed that the number of wireless clients associated to the network but not authenticated is significant. At times, as many as 50 percent of associated clients are unauthenticated on some wireless networks. Many of these clients remain in the unauthenticated state for significant periods of time. The current network design for AirBears assigns globally routable IPv4 addresses via DHCP, clients who are in the unauthenticated state consume globally routable addresses, making those addresses unavailable for other clients. One of the challenges we face operating AirBears is responding to an ever-increasing demand for address space.
The new captive portal network design uses RFC 1918 address space for wireless clients. While clients are in the unauthenticated state, their traffic undergoes many-to-one Network Address Translation (NAT) when it passes through the new captive portal. In the unauthenticated state, client traffic is limited to those resources required to authenticate. Once a client authenticates, a globally routable IPv4 address is allocated for the client by the new captive portal. While clients are in the authenticated state, their traffic undergoes one-to-one NAT when it passes through the new captive portal. At all times, wireless clients use RFC 1918 addresses; the new captive portal translates each client's RFC 1918 address to a common or assigned IPv4 address depending on the client's authentication state.
The use of RFC 1918 addresses and NAT in the above manner is a compromise between the desire to preserve the end-to-end principle and the need to conserve scarce globally routable IPv4 address space. The use of one-to-one NAT for authenticated clients permits bidirectional traffic for all transport protocols. For example, a server may initiate a TCP connection to a wireless client without the use of any special mechanism in advance on the part of the client. The use of RFC 1918 address space and many-to-one NAT for unauthenticated clients practically eliminates their consumption of globally routable IPv4 address space. RSSP's operational experience with this captive portal system has shown that the use of one-to-one NAT for authenticated wireless clients is generally transparent to the end user. Some applications, particularly those that embed client IP addresses in payloads, may not work correctly with one-to-one NAT.
Future enhancements
The new captive portal at present does not support IPv6. We have plans to support IPv6 in the future. Since IPv6 address space is far more plentiful, the new captive portal will bridge IPv6 traffic while using NAT as described above for IPv4 traffic. We hope to begin developing support for IPv6 in the fall. Since the new captive portal is based on open-source software, we have far greater control over its behavior and how we perform authentication than we do with the current captive portal. We are interested in exploring support for authentication via Shibboleth to the new captive portal to permit access to the wireless network to members of federated institutions. Another area we are interested in exploring is improving authentication support for wireless devices where typing a password is cumbersome. We will need to balance ease of authentication with the security of any changes to the underlying authentication mechanism, and the difficulty of supporting these changes. We would not likely begin exploration of these areas until after we have deployed the new captive portal.Testing and deployment plan
We plan to begin testing the new captive portal at 2484 Shattuck and 2195 Hearst in late June to early July 2009. Announcements are planned for occupants in these buildings along with messages to ucb-net-announce regarding specific dates for deployment. After a period of testing at these locations, the Captive Portal team will schedule a series of open testing sessions. During these sessions, members of the campus community are welcome to test their applications for compatibility with the new captive portal. We hope to schedule those sessions after the fall 2009 semester begins.
We will make plans for production deployment across campus based on our experience with the two test locations. We will communicate our plans as we get closer to production deployment.