1 / 12

Requirements for Internet Access in Public Places

Requirements for Internet Access in Public Places. Anand Balachandran University of California, San Diego http://www-cse.ucsd.edu/users/abalacha. Collaborators. Anand Balachandran (UCSD) Allen Miu (MIT) Geoff Voelker (UCSD). Computing in Public Places. Current trend in Internet access

yvon
Télécharger la présentation

Requirements for Internet Access in Public Places

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements for Internet Access in Public Places Anand Balachandran University of California, San Diego http://www-cse.ucsd.edu/users/abalacha

  2. Collaborators Anand Balachandran (UCSD) Allen Miu (MIT) Geoff Voelker (UCSD) 50th IETF Meeting, Minneapolis

  3. Computing in Public Places Current trend in Internet access • Ubiquitous network connectivity infrastructure • Not restricted to offices and homes • Access at airports, shopping malls, convention centers • Multiple access technologies (Ethernet, Wireless LANs, Bluetooth, DSL modems etc.) • Proliferation of lightweight portable mobile devices • Use and pay model; “shopping” for access 50th IETF Meeting, Minneapolis

  4. Security in Public-area Networks Current Schemes • MAC-level Filtering • No protection against hardware address spoofing; does not scale • WEP Key Security • Keys are hard-wired and cannot be changed flexibly • WEP keys can be broken over time • OK for small enterprises, but does not scale well • IEEE 802.1x port-based access control • Access dependent – does not support APs that are not IEEE compliant (e.g. HIPERLAN, HomeRF, Bluetooth) • Requires changes to existing AP hardware and software • TLS-based authentication requires user certificates 50th IETF Meeting, Minneapolis

  5. Our Vision A protocol for network access should be: • Hardware agnostic • independent of access technology • IP-version agnostic • Works with both IPv4 and IPv6 • Individual-centric • Allow network operators to track who is using the network and how it is being used • Give user a choice on how they are authenticated -- protect their privacy • Support multiple authentication schemes • AAA (DIAMETER), Global authenticators, E-cash systems (MasterCard, Visa) • Support users who do not have a “home” domain • Enables “free” access • Payment is implicit – drives resident business for the host organization 50th IETF Meeting, Minneapolis

  6. Service Models • Model 1: Free access to local resources • Does not require authentication but needs a valid IP address • Allow access to the Intranet • e.g. Mall portal, splash screens, indoor navigation service, Starbucks coffee ordering etc. • Model 2: Authenticate and pay • Allow access to the Internet • Allow applications like location-based buddy list, spontaneous sales that are based on profiles etc. • Differentiated charging 50th IETF Meeting, Minneapolis

  7. Scope of Our Access Protocol • User-network Interaction • User automatically discovers the existence of the network • User gets a valid IP address (e.g. through DHCP) • User verifies authenticity of the server (e.g. certificates) • User provides personal credentials to authentication server • Server provides user with a “key” upon successful authentication • Key is time bounded (e.g. access limited to 30 minutes.) • Protocol is not tied to any single encryption scheme • Protocol is decoupled from routing and location updates for mobile hosts • Can use Mobile IP for this 50th IETF Meeting, Minneapolis

  8. Research Fallout • User Registration and Authentication Protocol • Multiple modes of authentication possible (including TLS) • Handles simple aspects of user-network interaction • Provides mutual client-server authentication • Key management and renewal • Network discovery • Protocol agnostic mechanism based on broadcast beacons • Complements existing standards • mobility management and routing (mobile IP) • AAA-type functionality on the NNI Network deployed and operational in a mall 50th IETF Meeting, Minneapolis

  9. Experiences Mall deployment • Operational for 7 months • Provides basic Internet access and location-based services Ongoing efforts for campus deployment at UCSD Related publications • A. Miu and P. Bahl, “Dynamic Host Configuration for Managing Mobility between Private and Public Networks,” In Proc. 3rd Usenix Symposium on Internet Technologies and Systems (USITS’01), San Francisco, CA, March 2001, to appear. • P. Bahl, A. Balachandran, and S. Venkatachary, “Secure Broadband Wireless Internet Access in Public Places,” In Proc. IEEE International Conference on Communications (ICC’01), Helsinki, Finland, June 2001, to appear. 50th IETF Meeting, Minneapolis

  10. Existing (Partial) Solutions for Access • Mobile IP • Essentially a routing protocol; integrates the tasks of configuration and routing for mobile users in a foreign domain • AAA • Addresses interaction between registration agents in different administrative domains (NNI) • Authenticated DHCP (UC Berkeley) • Similar to port-based access control at Layer-3 • Netbar System at CMU and InSite at Michigan • Hardware centric approaches 50th IETF Meeting, Minneapolis

  11. Network Architecture 50th IETF Meeting, Minneapolis

  12. Discovery Protocol Detects the existence of the network service • Decouple discovery from configuration protocol • Remain protocol-agnostic • Server broadcasts service beacons in the local network • Passive approach to avoid unwanted solicitation messages in the private network • Better alternative to client polling (saves network bandwidth, especially the air interface) • Beaconing can be used for network-wide load-balancing, fail-over, and location services 50th IETF Meeting, Minneapolis

More Related