Campus wireless at-a-glance: current and future
Wireless Service Characteristics
- Open access points (no encryption)
- Cisco “Fat” AP’s w/ BlueSocket gateways
- Captive portal, Web page re-directs – Kerberos login
- Lookup tools for help desk support
- Nessus scan
- Guest access via sponsor registration
- Approx. 270 APs currently managed from the NOC
- APs are deployed in campus “common areas”
- Departments fund MoobileNet AP deployment in their spaces
- Wireless gateways are centrally funded
- Wireless VLANs are geographically deployed; roaming within VLAN
- Current investment in wireless services is very limited.
- No revenue stream directly related to wireless services.
- BlueSocket instability
- BlueSockets periodically stop performing Web redirects
- Authenticated users continue to function; new users prevented from authenticating
- Solution: Appears to be a memory leak – working with vendor to diagnose
- Slow login
- Typical login expected to take 20-30 seconds; includes time for web page redirects and security scan
- Recent complaints of slower login times; some user reports of logins taking several minutes
- Troubleshooting revealed 3 security scans being conducted
- Bluesocket wireless gateway memory leak can cause delays in re-directs
- Without scans, login period is several seconds (typically)
- Solution: Ensure only one security scan occurs, fix memory leak (temporary solution – scheduled reboots of wireless gateways)
- DHCP address depletion
- Users do not need to authenticate to obtain an IP Address
- Solution: Expanded DHCP address pools & re-balanced wireless VLANs (short-term solution); working with vendor to implement dynamic 1:1 NAT – will allow private address space on the wireless side
- Limited Coverage
- Working with CCFIT to identify and prioritize coverage areas
- Costs
- Departments bear the cost of Cisco AP procurement & NAM installation
- Investigating new cost and funding models
- Security Issues
- No session encryption unless SSL protocol available
- Any user can associate with an AP and obtain access to the wireless VLAN
- Wireless clients may generate malicious traffic onto other wireless users and the campus network
- Authentication allows access off of the wireless VLAN
- No RF Management
- Solution: Addressed by controller-based solution.
- No control of non-CR wireless deployments on campus
- Solution: Policy revisions, required minimum standards.
- 802.1x for exisiting MoobileNet
- Separate SSID, not beaconed
- Encryption from endpoint to AP
- Testing underway
- Supplicant support – IT Express ramp up, self-help configuration guides, downloadable configuration tool, communications
- Populating LDAP with password hashes
- 802.1x for wired network
- Testing has gone well
- Feature request into Foundry – multiple authentication hosts required
- RADIUS/LDAP
- Integration of a preferred VLAN attribute into LDAP
- Moving RADIUS server into production mode
- Future integration of various permits, time and location based policy decisions
- Testing controller-based wireless solutions
- Product testing nearly complete
- Incorporates 802.1x and captive portal authentication methods
- Supports LDAP-preferred VLAN attribute – permits secured wireless access to department VLANs (opt-in)
- Solution addresses security, RF management and roaming issues
- Integrates with RADIUS authentication development efforts
- Network Admission Control Testing
- 802.1x integrated into testing regime
- Testing with wired network access
- Request for Proposal will be released in March 2007
- Tested and deployed CAT 5e power injectors
- Deployment models have been developed – Costs and scope identified on a per building basis
- Wireless Valley Software – modeling tool that optimizes AP placement and coverage within a building
- Wireless infrastructure requirements are now incorporated into new construction projects
- Working with CCFIT & campus to:
- Identify funding model
- Prioritize deployment efforts
- Continue development and enhancements to authentication policies and delegated management tools