1 / 14

The Case for Peer-to-Peer Wireless LAN Consortia (PWC)

The Case for Peer-to-Peer Wireless LAN Consortia (PWC). A P2P Approach to WLAN Roaming. Introduction (1 of 2). Ubiquitous Internet Access a Necessity However, WISPs are facing difficulties WISP roaming practically non-existent Many under-exploited private WLANs do exist

gdelatorre
Download Presentation

The Case for Peer-to-Peer Wireless LAN Consortia (PWC)

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. The Case forPeer-to-Peer Wireless LAN Consortia(PWC) A P2P Approach to WLAN Roaming

  2. Introduction (1 of 2) • Ubiquitous Internet Access a Necessity • However, WISPs are facing difficulties • WISP roaming practically non-existent • Many under-exploited private WLANs do exist • The Peer-to-Peer Wireless LAN Consortium (PWC): • A Framework for uniting all WLANs in one global group • A Community of WLAN Administrative Domains that offer wireless Internet access to each other’s registered users • The PWC is a P2P network of Domain Agents (DAs) • DAs are physical nodes that represent one domain each • Their purpose is to eliminate the overhead of roaming agreements • Instead, DAs obey a simple token-exchange rule

  3. Introduction (2 of 2) • Domain Independence: a PWC Distinctive Characteristic • DAs make autonomous decisions concerning the amount of resources they provide to visitors • Key difference from other roaming schemes • PWC Simplicity • No central entity controls the PWC or the interactions of its participants • No cost of entry for domains • PWC subsystems leverage its P2P nature: no external servers are required

  4. Background • Motivation • Existing under-exploited WLANs • IEEE 802.11 simplicity • Next-generation portable devices • WLAN Roaming Today • Practically non-existent • Hotspot aggregation (e.g. Boingo Inc.) is not WLAN roaming • Limitations of WISP associations (e.g. Pass-One) • Service-mark logic • Insufficient privacy • Insufficient autonomy • Administrative overhead and complexity • The PWC as a P2P System • Shared good: bandwidth • Autonomous peers: independent domain agents • Free-riding: domains that may not provide access to visitors • Incentives and rules: token-exchange rule

  5. PWC Requirements • 1. Domain Independence • The peers make autonomous decisions • Concerning their contribution level • Concerning their participation status • 2. Domain Reciprocal Behavior • Free-riding must be minimized • PWC system rule: token-exchange • This rule “guides” domain behavior • 3. Easy-to-Join • No administrative overhead • Similar to joining a P2P file-sharing network • Assuming the domain WLAN infrastructure is already in place • 4. PWC Self-Sufficiency • PWC subsystems rely only on the PWC peers themselves • 5. Decentralization • No central entities • No central authority manages the PWC

  6. PWC Entities • Domain Agents (DAs) • The PWC is a P2P network of DAs • DAs are nodes running the PWC DA software • Exactly one DA per PWC administrative domain • Each DA has a unique logical name: • aueb.gr, cometa.net • The_Aveiro_Smith_Family • Users • Registered with one (or more) DAs • Each has a unique identifier (user_name@logical_domain_name) • Bandwidth • The PWC ‘good’ - 802.11 bandwidth and bandwidth to the Internet • Tokens • Unforgeable virtual currency • Exchanged between DAs • Represent the value, which DAs ascribe to their consumed bandwidth

  7. PWC High-Level View AP AP AP DA ‘Black’ AP DA ‘White’ AP AP DA ‘Gray’ AP AP AP DA: PWC Domain Agent AP: WLAN Access Point : User WLAN view P2P view

  8. PWC Domain Agent Modules • 1. Name-service • Maps logical domain names to DA IP addresses • Uses a Distributed Hash Table (DHT) • 2. Authentication • Maintains a database of registered users • Along with their security credentials • 3. Traffic Policing • Logs and shapes egress and ingress Internet traffic • Allocates specific amounts of bandwidth to visitors • 4. WLAN • Firewall, DHCP, DNS, NAT/NAPT, WLAN control • 5. Distributed Accounting • Secure storage of PWC accounting information • Also uses a DHT • 6. Consumer Strategy • Regulates the consumption actions of the domain’s roaming users • 7. Provider Strategy • Regulates contribution to visitors • Dynamically assigns “prices” to consumed resources • 8. Privacy Enhancement • Ensures PWC user anonymity and untraceability

  9. PWC Security Issues • PWC security is a superset of WLAN security • The usual confidentiality, integrity, and availability problems apply • The following three issues are PWC-specific: • 1. Traffic Logging by Untrustworthy Providers • User traffic completely visible to the visited Domain Agent • Encryption does not hide useful metadata (e.g. remote-party address) • SOLUTION: Tunnel (encrypt and route) through the home DA • 2. Identity Privacy: PWC Pseudonyms • User name visible to the visited DA • SOLUTION: Use algorithmically updated user aliases • 3. Anonymity and Untraceability: PWC Mixes • User name and home domain name visible to the visited DA • Home domain name required for PWC accounting • SOLUTION: Use PWC privacy enhancement modules (PWC mixes)

  10. PWC Mixes Blue arrows represent token flow DA ‘B’ (Second mix) DA ‘A’ (First mix) DA ‘P’ (Provider) DA ‘C’ (Consumer) “My PWC user ID is alias_X@A” (Appends real ID and a mix chain, all encrypted using layered public-key encryptions) user_X@C P, A, and B cannot know if the domain on the right is the real consuming domain or a mix A, B, and C cannot know if the domain on the left is the real providing (visited) domain or a mix

  11. Open PWC Issues • 1. Secure Distributed Accounting • Maintains PWC accounting history • Must be fault-tolerant, scalable, hack-proof • 2. Tokens and Token Generation • Cryptographically secure, unforgeable tokens • Generated, perhaps, by a PWC internal distributed bank • Distributed to new PWC entrants • 3. Domain Heterogeneity • Domains covering areas diverse in size and location • Domains may have completely uneven populations of registered users • Small domains may receive only very few requests (and thus tokens) • 4. “Offline” Domains • Domain Agent autonomy may mean a DA is unreachable/offline • Who “pays” for a roaming user of that domain? • The roaming user? Another domain?

  12. Deploying the PWC • Domain Agent Administrative Interface • Must hide PWC complexity from Domain Agent administrators • DAs must require a minimum number of input parameters: • 1. A list of registered users and their security credentials • 2. The domain’s aggregate egress and ingress Internet bandwidth • 3. A “map” of WLAN cells and local traffic bottlenecks • 4. The average WLAN load (local registered users and visitors) • 5. The average PWC usage by roaming users of the domain • Some of these parameters will be administrator’s ‘best-guesses’ • PWC Profit Opportunities • 1. Vendors of PWC Domain Agents • 2. Vendors of PWC support modules • 3. PWC domain aggregators • 4. “Pay-as-you-go” domains

  13. PWC Domain Agent Prototype • We’ve built two prototype PWC Domain Agents • Running on PCs with Red Hat Linux 9 (2.4.20 kernel) • Developed using C, Java, and Python • Each DA is also a WLAN router, connected to the Internet and to a Cisco Aironet 1200-series WLAN AP • Modules completed: • Authentication • Using IEEE 802.1X • Using a custom web-based login function (and the iptablesfirewall) • Traffic Policing • Using the libpcap library and the tc utility • WLAN • Using Linux IP masquerading (for NAT/NAPT) and standard Linux DHCP, DNS, and routing functionality • Strategy (using a very simple P2P token-exchange rule) • Still needed: • Unforgeable tokens, secure DHT (for distributed accounting and name-service), more complex strategy algorithms, PWC mixes

  14. Concluding Remarks • The PWC is a simple alternative to existing roaming schemes • The PWC is designed around organic growth • PWC strategic agents replace static roaming agreements • Although, by design, the PWC cannot provide any strong guarantees, it could become a suitable vehicle for achieving ubiquitous, low-cost, Internet access • PWC autonomy and privacy considerations could make it more socially acceptable • Real-world regulations could, however, affect PWC growth • More analysis and simulations are needed to assist in designing optimal PWC rules

More Related