190 likes | 364 Views
Architecting Citywide Ubiquitous Wi-Fi Access. Nishanth Sastry Jon Crowcroft, Karen Sollins. Architecting Citywide Ubiquitous Wi-Fi Access. I: What’s wrong with sharing Wi-Fi? II: Tunneling based Architecture to safely & securely share Wi-Fi. Guest. Host. Guest’s Home. Terminology.
E N D
Architecting Citywide Ubiquitous Wi-Fi Access Nishanth Sastry Jon Crowcroft, Karen Sollins HotNets-VI
Architecting Citywide Ubiquitous Wi-Fi Access I: What’s wrong with sharing Wi-Fi? II: Tunneling based Architecture to safely & securely share Wi-Fi HotNets-VI
Guest Host Guest’s Home Terminology Host AP + Firewall + NAT
Hosts have to trust guests to be well-behaved What’s wrong with sharing Wi-Fi? (1/2) Malicious guests can ... • be bandwidth hogs • infect host computers • download illegal content • be part of DDoS botnet* Use bandwidth limiters & firewalls *Where each flow is too small to be detected
What’s wrong with sharing Wi-Fi? (1⅜/2) Then there are the freeloaders... seeking better connectivity than their homes And kids escaping parental control software @ home How do we induce hosts to share Wi-Fi?
What’s wrong with sharing Wi-Fi? (1⅝/2) Captive portals, commonly used for logins at public hotspots (e.g. cafés & Fon), are essentially dynamic firewalls & are susceptible to users who sniff & spoof an authenticated user’s address
What’s wrong with sharing Wi-Fi? (2/2) Hosts can be malicious too. e.g. Pharming Guest has to trust host router!
How to safely share Wi-Fi? Home • takes on responsibility for guest’s traffic • hides guest traffic from host by encrypting • acts as trusted source for guest DNS/IP Eliminate latent trust dependencies
Guest Tunnel VPN server Host Guest’s Home Tunneling removes dependencies Host AP + Firewall + NAT Trusted Services vpn-local IP Guest’s DHCP NAT beyond tunnel
Tunnel setup: Co-operative Host AP + Firewall + NAT Guest coop-local IP Co-op distributes two registries: Coop-local IP Member ID Mapping of members’ ISP assigned IP Guest’s Home STUN
But, what about performance? • Path length inflation • Intra-City Latency • 30—60ms [Lakshminarayanan IMC’03] Guest downlink = home downlink+uplink! • Asymmetric broadband limited uplinks • Median uplink bandwith = 212 Kbps [ibid] • Sufficient for emergency response [LeMay earlier] • Performance comparable to p2p flows
Scale and scope of the co-op depends on: • regional laws governing “legal” content technical factors... • end2end latency • sizeof(coop-local IP space) • AP memory for home & coop-local IP tables Works for citywide co-ops (broadband members)
Technical summary 5. vpn-local IP Guest 1.coop-local IP 3.Tunnel 4. Guest’s Home 2. STUN
Key features enabled by home • Accountability in IP tracebacks • Simultaneous access through multiple hosts • crucial for access with weak signals 5. vpn-local IP Guest 1.coop-local IP 3.Tunnel 4. Guest’s Home 2. STUN
Two paths to adoption • I: Without ISP support: Will host’s ISP let it share its connection? • hinges on what “internet connection” is • mandate sharing! unlicensed spectrum is public good • II: With ISP support: offer business model • Think ComcastVoice citywide! Co-op can benefit from ISP: • increase uplink bandwidth for guest access • make better tunnels (e.g. MPLS VPNs)
Co-op tunnels ≠Mobile IP tunnels X Triangular routing not possible External node typically initiates contact Need to register “care-of address” precludes highly mobile guests like cars
Local IP addresses • vpn-local/coop-local IPs are private IPs • vpn-local is local to guest-home pair • can be reused by host & other guests • coop-local is local to guest-host pair • can be reused on office VPNs of guest/host
Dealing with NATs • Restricted Cone or Symmetric NAT • Punch holes separately to each member • NATs with deep packet inspection • STUN/rendezvous server acts as relay