SSID Consolidation proposal
13000 access points
4 SSIDs:
Stanford
Stanford Secure
Stanford Visitor
Eduroam
(Plus SHC and others)
50,000 maximum concurrent connections: Max academic 40,000; dorms 20,000
Proposed end goal, just 2 SSIDs:
Stanford Visitor (visitors)
Eduroam (every real "Stanford" user, plus traditional educational visitors)
Why? "Stanford Branding" was deemed important long ago, and it's no longer as much of a concern, or is it?
If staff only had access to eduroam, how would registration work? Visitor and Eduroam do not currently require NetDB registration.
Eduroam would have SNSR enabled for Stanford people. Non-Stanford educational users would continue to use it as they do.
Goal: Keep functionality, but with just 2 SSIDs
Concern: for security purposes, automatic joining to "Stanford" would fail.
Communication would have to go to everyone, eduroam is not well known in the community. LOTS of people would have to know.
A rogue SSID broadcasting "Stanford" could then be used for bad things.
Eduroam would be linked to Cardinal Key for authentication. Eduroam would be locked down. We could list "Stanford" as an untrusted SSID.
Linux users can't use Cadinal Key, they would still use the existing name/password of eduroam.
What about "Stanford Residences"? They'd still use eduroam (w/ or w/o Cardinal Key)
Conferences? (Wireless Guest). Wireless Guest would still be kept if necessary. Eduroam helps for research/education conferences, but not for summer school/camps, non- higher ed clients.
What about IOT devices, printers, etc. Bonjour-style discovery might work across vlans with Cisco provided tools, might not work. Single vlan and multicast are dangerous, but multicast can be useful for some tools and use cases.
Many other educational institutions use eduroam, it's very well supported for conferences, can be very easy to join if you already use it.
Eduroam can get regular Stanford IP numbers, Stanford Visitor doesn't, so you get better connectivity through eduroam.
Branding doesn't seem to be important, but communication is critical. Lots of information needed.
Will change be phased? Most likely get rid of Stanford Secure first, move all those users to eduroam. Then encourage eduroam for Stanford users, then get rid of Stanford SSID. Lots of communication.
Phase in certain areas? Kill "Stanford" by location, see how that works.
Timing: Not until Summer 2020 at the earliest. Communicate with students before they leave.
Office 365 move: Students weren't moved, new class were moved to O365, others stayed with google until they graduated. May not work so well with wifi.
SNSR will configure new machines for eduroam at first.
Device compliance and eduroam: ISO will work with UIT Networking to make sure it works well.
Frosh received registration process as lengthy and cumbersome, so they use Visitor instead and never register. Can registration be as easy as possible?
Windows 10 "home" users have some problem with registration. Cardinal Key qualification.
With eduroam, Student onboarding may be much quicker. They'll have to log in, we'll know who they are, may make the registration process shorter.
Pre-NSO packet should contain information. Assumes students know how to read.
Students can enroll in eduroam before they arrive, that may make registration of their MAC etc. much faster.
University HR will send employee IDs before people arrive. That could let them use eduroam on day one. Welcome center for staff could be given information.
Faculty orientation, once/year, not as convenient.
Some "visitors" (post docs) are sort-of employees. How to they integrate. They may object to having things installed on their personal devices.
Visitor network currently configured to reject registered MAC addresses, what if they can't use eduroam as well? If a registered device is non compliant, it can't use visitor, it can't use regular network, how will it work?
Service desk: eduroam is a bit of a savior. Allows people to connect and get updates, become compliant, register, etc.
IOT? How to make that work for wireless-only IOT devices?
IOT is just another registered device. When you have gotten ISO approval for the IOT device, just register it in NetDB. Hopefully the MAC is on the box somewhere.
Every new SSID is 3-5% overhead. Isolation by SSID can really impact wireless and slow users. Wireless is shared, not switched.
Lots of research being done on IoT. Most are custom built devices. Possibly hundreds or thousands to register. Separate wifi? Not optimal.
IoT on a separate network is suggested. How to do that? SSID (overhead), vlan segregation?
Computer Science: eduroam is great...IoT devices that can't do encryption, how to get them working? Run own radius servers? Isolate networks.
Ask vendor of IoT device: Does it work on cell service? Does it require wireless?
IoT vendors may not always follow the rules about not re-using MAC addresses.
IPv6-only clients can be very challenging.
IoT is a big concern. Research (engineering professors) vs. production (building control etc.), very different concerns. Need separate conversations.
Primary impediment to improved WiFi in outdoors: Funding and University Architect (antennae forbidden). Wireless needs wired somewhere, and antennae are sometimes ugly. If you really need it, put in a ticket.
Law School had a request for location based services. Very expensive. WHo else? LBRE, Engineering. CIO council committee.
IoT: What if wired and wireless IoT devices are not in same vlan? Everything on wireless is private, many IoT devices expect public addresses, and expect to be communicated TO from some off campus devices. NAT may be problematic. Will IPv6 fix the problem? Many are v4 only.
