KIR English

Architecting Citywide Ubiquitous Wi-Fi Access



Nishanth Sastry Jon Crowcroft Karen Sollins
University of Cambridge University of Cambridge MIT

MIT

ABSTRACT

Cities around the world are currently considering building
expensive Wi-Fi infrastructure. In urban areas, resident operated
Wi-Fi access points (APs) are dense enough to achieve
ubiquitous Internet access, provided we can induce the hosts
to provide guest Wi-Fi access. However, sharing Wi-Fi involves
taking on responsibility for the guest’s actions. Our
main contribution is a novel mechanism to handoff the host’s
responsibility to a trusted point by tunneling the guest’s packets
through it. The tunnel also guarantees that the guest’s
traffic cannot be subverted by malicious hosts. Using tunneling
as a primitive, we show how to architect a citywide cooperative
for safely
sharing Wi-Fi with legitimate
guests.
We offer this as an economically viable alternative to investing
millions in new infrastructure.

1. INTRODUCTION
People used to ubiquitous Wi-Fi at their workplaces
will readily appreciate the ability to access the Intern
et everywhere. The economic importance of ubiquit
ous Wi-Fi connectivity rises dramatically in the face
of new developments such as the convergence of cellul
ar and Wi-Fi via standards such as Unlicensed Mobile
Access[21]. Forinstance,T-MobileUSA recentlyintrod
uced the ability to route cellphone calls over Wi-Fi1
.

Understanding thepotentialimpact of ubiquitousInt
ernet connectivity, many cities have moved to create
citywide wireless access infrastructure. Usually, the sol
ution involves Wi-Max as the backbone supporting a
number of Wi-Fi APs. This is an expensive solution
that can cost as much as $150,000 per square mile2
.
Wireless connectivity for a large city such as San Franc
isco will reportedly cost 15 million dollars3
.

In this paper, we argue that citywide ubiquitous Wi-
Fi access can be architected at near-zero cost because

Currently
a
visiting
student
at
MIT
CSAIL.
1
http://www.nytimes.com/2006/07/29/technology/29phones.
html
2
http://www.jupitermedia.com/corporate/releases/05.07.
06-newjupresearch.html
3
http://www.elecdesign.com/Articles/ArticleID/12413/
12413.html



Figure 1: A map of San Francisco. Each
red point represents one Wi-Fi AP (from
WiGLE.net, accessed on Jul 26, 2007).

the network infrastructure is already in place: A maj
orityof city dwellershave a broadband connection and
a personal Wi-Fi AP at home. As Fig. 1 suggests, in
dense metropolitan areas such as San Francisco, there
is sufficient density of APs to achieve near-ubiquitous
Wi-Fi by sharing access to APs amongst residents.

Ourgoalis to addresstheissue ofhow toinducehosts
(who own the APs)to explicitly and safely share their
Wi-Fi with legitimate guests, while at the same time
ensuringthatguests areprotectedfrom malicioushosts.
We note that this is almost completely a sociological
solution to a technical problem.

Our agenda is twofold. First, we examine the dang
ers involved in implicitly sharing Wi-Fi access, both
from the perspective of a host providing an unsecured
AP, and aguest hopping onto an unknownAP. Second,
we question whether cities should be investing millions
of tax dollars in building public Wi-Fi infrastructure
and suggest a safe,
low-cost
alternative: forming a coo
perative of residents to share Wi-Fi access explicitly.

Our main technical contribution is to identify tunn
eling as a mechanism to sidestep various legal and
safetyissuesinvolvedin sharingWi-Fi access. To make
Wi-Fi sharing safe for both the host and the guest, we
needto removelatenttrustdependenciesbetweenthem.

1


Theguest’spackets are routed through an opaquetunn
el and ingress the public Internet from a third point
trusted by the guest, typically the guest’s home. Since
the rest of theInternet sees this the origin of theguest’s
traffic, the home, rather than the host, becomes acc
ountablefor theguest’s actions(such asdownloading
illegal content). The home authenticates the guest bef
ore assuming this responsibility. The architecture also
puts the home in control of the guest’s DHCP parame
ters and routing, which prevents malicious hosts from
tampering.

To create a trusted network of end-points,participati
ng city residentsform a co-operative(co-op) in which
members share their Wi-Fi APs with each other. The
coopinfrastructurehelps trackIP addresses assigned to
members’ homes by their ISPs, and establishes tunnels
by punching NAT holes when required. The co-op also
enables simple optimisations for highly mobile guests

(e.g. cars)who may bein contact with agivenhostAP
for only a few seconds.
The rest of the paper is organised as follows. §2 disc
usses related work. §3 discusses the main obstacles
that prevent or inhibit the sharing of Wi-Fi. §4 motiv
ates tunneling as an approach to overcome these obs
tacles. In §5, we outline an architecture that supports
the creation and maintenance of tunnels. §6 discusses
optimisationsfor roaming andthe scope andlimitations
of our approach. §7 concludes.

The following clarifies terminology used both in this
section and in the rest of the paper: The host
is the
one sharing herWi-Fi accesspoint with a guest
who is
away from her home
network where she has an always-
on connection to the Internet. The tunnel gets establ
ished between the host and the home.

2. RELATED WORK
A low cost, “guerilla” approach that has previously
been tried is to create a community-wide mesh net-
work[1,3,18],butthis requires separate networkhardw
are setup, and can be difficult to scale beyond a core,
dense facility because each node in the mesh needs to
be within radio range of at least one other node.

Yet another approach is to provide Wi-Fi access in
exchange for tokens which can be redeemed when the
hosttravelstootherAPsinthe city[12]. While such
trading schemes would induce hosts with houses near
popular spots like bus-stops to shareWi-Fi, home owne
rsin more residential neighbourhoods wouldhavelittle
incentive to share. Since our goal is ubiquitous Wi-Fi,
we opt instead for a co-op thatprovides equal incentive
for all residents to share Wi-Fi.

Recently, afew commercial ventures such asFon[6]
andWhisher[22] haveintroduceddifferent modelsfor
sharing Wi-Fi connectivity. Whisher seems to work by
distributingtheWEP/WPAkeysto users authorisedby

the host4
, and as such, does not appear to be a viable
solutionforsharingWi-Fi withguest usersunknownto
the host. Fon sells a custom Wi-Fi AP with firmware
that requires newguest usersto authenticatethemselves
with a Fon server using the captive portal technique.
Captive portals are essentially dynamic MAC/IP Add
ress filterscontainingalist of authenticatedguestsand
therefore can easilybe evaded by sniffing the address of
an already authenticated guest and masquerading as
that address.

To the best of our knowledge, all previous attempts
to share Wi-Fi allow the guest to directly access the
Internet using the host’s connection to the ISP. As we
detail in §4, there are numerous legal and security rel
ated reasons why we adopt tunneling instead.

MobileIP[14] also relies ontunnels, to makeguestn
ode mobility transparent to external “correspondent”
nodes. Mobile IP calls for triangular routing in which
packets from the external node to the guest are routed
through the home but packets in the reverse direction
are sent directly. This is not possible in our scenario
becausehostsdo nottrustthegueststograntthemdir
ect access to external nodes. Also, mobile IP enables
the external node to initiate contact with the mobile
(guest) node. Consequently, the tunnel setup is more
involved and requirestheregistrationof a “care-of”add
ress with the home agent whenever the guest moves.
These choices make mobile IP difficult to use for fast-
moving guests such as cars, which may be in contact
with agivenhostAPforonly afewseconds[2]. Incont
rast, in our system, the guest node typically initiates
the contact, and we are able to incorporate simplificat
ions aimed at enablingfast-movingguests. Traditional
mobileIPhas alsobeenlargelyincompatible withNAT,
while our design accommodates, and indeed, makes use
of the reality of NATs and private IP addresses.

3. OBSTACLES
We will now review the obstacles from the host’s and
the guest’s viewpoints that prevent or inhibit the shari
ng of personal Wi-Fi APs.

3.1 Host’s concerns
A number of APs are left unsecured either because
their owners ideologically want to support free wireless
access orbecause theylack the tech savvyto change the
default factory settings of their AP.AP owners who are
aware of the possible dangers and legal implications of
sharing their Internet connection with potentially mal
iciousguests nearly always securetheirAPs[8].

Anatural concern ofhostsisthepossibleloss ofbandw
idth. Aninconsiderateguestshould notbe abletohog
bandwidth to an extent that the host is unable to ade


4
http://blog.whisher.com/2007/03/01/today-we-explainsharing-
your-wifi-with-whisher/#comment-46


2


quatelyaccesstheInternetherself. There maybe a need
to control guest bandwidth even when the host is not
using theInternet,in order tokeep the aggregatetraffic
envelope under limits acceptable to the host’s ISP.

Another worry, although many Wi-Fi owners are una
ware of this possibility, is that a malicious guest may
attack andinfect other computers on thehost’s network
or eventhe wireless routeritself[20].

A more difficult problem is that a guest may downl
oad illegal content such as copyrighted media files or
pornography. Most ISPs’ Terms of Service explicitly
ban their customers from performing or abetting such
illegal acts and the host would be in violation of these
termsbecause of theguest’s actions[9].

3.2 Guest’s concerns
Modern operating systems try to make connecting to
a new wireless network painless and easy. This has led
to a careless and even carefree attitude – most users
do not hesitate to hop onto any foreign wireless netw
ork that is freely available. However, surreptitiously
stealingbandwidthis ethically andlegallyquestionable.
Also, prudent guests should realise their susceptibility
to attacks and infections by a malicious host in much
the same way a malicious guest can attack a host.

Even worse, if DHCP is being used, the host’s netw
ork can assign the guest a phony DNS server IP Add
ress, forming the basis for a sophisticated “pharming”
attack[19]. By redirectingDNS requestsforpersonal
website names(web-based mail,bank websites etc.) to
bogus servers that carefully reproduce the look and feel
of the requested website, the guest can be conned into
divulging passwords and other sensitive information.

4. TUNNELING THROUGH OBSTACLES
Our main claim is that the above obstacles can be
solvedif the only accessgranted to theguestis a tunnel
to a single point in the Internet that the guest trusts.
In this section, we motivate the reasons for this decis
ion. We also briefly discuss some legal implications of
sharing Wi-Fi, and overheads imposed by tunneling.

We expect that common network security practices
will continue at the host end, supplementing the tunn
els. Forbasicprotectionagainst maliciousguests, fire-
walls should be enabled on the wireless router and/or
thehost’s computers. Severalwireless routers as well as
commercial(e.g.Fon) and open-source(e.g.DD-WRT)
router firmware allow for setting bandwidth limits.

4.1 Motivation: Why tunnel?
The guest’s concerns can be solved if her traffic can
be encrypted so that the host cannot snoop. However,
most websites todaydo not support secure connections.
To the guest, the tunnel provides a trusted intermedia
ry that can encrypt all
of its flows going through a

host that it does not necessarily trust. As we discuss
below, the tunnel allows the home
to set the guest’s
DNS server, and protects against the pharming attack
described above.

To resolve the host’s concerns, we need to examine
the roots of malicious guest usage. The first issue is
the natureof thecontentaccessedby theguest. Guests
should notbe allowedto use theforeignhost as an altern
ate Internet access point merely to evade restrictions
that may be in-place at their home or other default Int
ernet accesspoint. These restrictionsinclude thehome
ISP’s Terms of Service or Acceptable Use Policies as
well as any router-based orISP-providedparental cont
rol software5
. A tunnel does not directly solve this
problem. Instead, it hands off this responsibility to the
remote tunnel endpoint. The reasoning is that if the
guesthasthe rightstoaccesstheInternetfromapoint,
then that point should have the responsibility and the
authority to police, or limit access to content.

The secondissueis thepossibility of subverting ubiqu
itous connectivity for DDoS. Because of poor radio
links(hostAPscouldbebehind wallsorfarawayphysi
cally) andbecausehosts maylimit the bandwidth they
share, manyguests could experiencelow-bandwidthlinks.
Hence, legitimate guests within range of multiple host
APs should be allowed to use them all simultaneously6
,
using multiple wireless cards or techniques like Multi-
net[4] and multi-radiodiversity[11]. However, allowing
this in conjunction with ubiquitous Internet connectivi
ty all over the city massively amplifies the bandwidth
available and raises the spectre ofDDoS. With our tunn
eling mechanism, traffic from the guest through any
hosteventuallygets routedthrough a single chokepoint,
the guest’s own home. This limits the amplification a
malicious guest can achieve to the bandwidth that was
already available at home.

A third,potential area of concernis thatif anISP off
ers value-added services such as real-time stockquotes
or games-on-demand that are based on the customer
at the end point, the guest, who is NAT’ed behind the
same end point, will also obtain access. A similar situ
ation arises when the host has a better point of conn
ectivity, say aprivateT1line. Thehostmay notwant
to share these premium services if reciprocal access is
not guaranteed. With a tunnel, the guest is only exp
osedtoher ownISP, and access topremium servicesis
not leaked. Furthermore, as discussed above, the bandw
idth attainableby theguestislimitedby the available
bandwidth on her home network, which makes it safe
toprovideguest access even on expensivelines.

5
We
do
not
concern
ourselves
with
parental
control
toolbars
in
browsers.
They
travel
with
the
guest’s
machine,
and
cann
ot
be
evaded
merely
by
choosing
alternate
access
points.
6
To
the
best
of
our
knowledge,
Fon
does
not
allow
simultan
eously
connecting
to
multiple
hosts,
and
this
is
a
drawback.


3


In summary, most of our arguments boil down to
eliminating all the reasons (other than being located
awayfromhome)that maylead aguest to use thehost’s
AP rather than her own connection at home.

4.2 Legal issues and accountability
Forcing the guest to create a secure tunnel removes
thehost’s “abilitytosuperviseinfringing activity”which
can be a legal liability for an Access Point provider
(A&M Records v. Napster, Inc., cited in [9]). Intere
stingly, courts in the US have held that a guest could
be subject to the host ISP’s terms of service even if
notice of the terms were notgiven(AmericaOnline v.
LCGM, citedin[9]). Thus,itisin theguest’sinterest
to access the public Internet through a tunnel to her
own ISP, whose terms of service are known to her.

Forcingaccess through theguest’shome network also
improves accountabilityinIPtraceback situations[16,
17], since the home node is now apart of any traceback
pathandlegallybinding terms of terms of service of the
home’s ISP can be brought to bear upon it.

Many ISPs have terms of service that prohibit res
ellingInternet connectivity. Byrestrictingguest traffic
to atunnel, thehostis ableto shareWi-Fi without shari
ng basic ISP-provided services such as DNS lookups,
default routes, or IP address assignments. Also, since
the tunnel is encrypted, everyone other than the guest
and the home will perceive the guest’s traffic as origin
ating from its home. The tunnel traffic itself will app
earsimilartopeer-to-peer flowssuchasbittorrent and
skype that already exist in the Internet.

Even so, ISPs do have a lot of control since they
could contractually prohibit the tunnel traffic or affect
the hosts’ willingness to share Wi-Fi by changing their
pricing model. Weimaginethatinpractical situations,
co-ops could split the costs of membership with ISPs to
carry the tunnel traffic. Or, municipalities could pass
laws requiring the ISPs to support co-ops. The exact
commercial and regulatory framework will vary from
region to region and is beyond the scope of the paper.

4.3 Overheads of tunneling
The obvious worry with our approach is path length
inflation, especially in cases where the host and the
home are on twodifferent ISPs that do notpeerlocally.
However,for mostpurposes,guests only care aboutinc
rease in latency. In broadband hosts, intracity P2P
ping latencies are reported to be 30-60 ms[10] which
is almost undetectable for most normal usage.

Bandwidth is more of a limiting factor. Notice that
datadownloadedby theguestis firstdownloaded tothe
home andthen uploadedto theguestvia thehost. Most
residential broadband connections are highly asymmetr
ic. Thus the available bandwidth on home’s uplink
(median 212 Kbps [10]) limits the guest’s bandwidth.

Guest handheld

192.168.0.3
co-op local: 10.1.1.2
vpn local: 192.168.0.3
co-op rendezvous
+ STUN server
co-op local: 10.1.1.5
vpn local: 192.168.2.3
Host
+ VPN Server
+ VPN Server
Guest laptop
Laptop home
Handheld home
Figure 2: Architecture: Guest traffic is tunneled
to home. The home end of the tunnel is a VPN
server & authenticates guests. The host end is
a firewall allowing only homebound packets. A
STUN server helps set up tunnels when memb
ers are behind NATs. Guests are addressed
by a fixed coop-local IP on the host’s network,
and a vpn local IP on the home network. Both
addresses may be reused outside their scope.

This is a serious limitation for some, but may be suffi
cient for common use cases. Studies are needed to
determine whether guests can indeed achieve sufficient
bandwidth in practice.

5. ARCHITECTURE
Tunneling isillustratedinFig.2, which showsguests
with a laptop and a handheld sharing a common host
AP.As shown,packetsfrom machinesbelonging tothe
host’s network are allowed to directly access the Intern
et. Thelaptop’s andhandheld’spackets,however,are
tunneled through to their respective homes and ingress
the Internet from there.

In this section, we discuss the underpinnings of an
architecture for this kind of access: a co-op to form a
trusted network of endpoints acrossthe city and manage
theguestidentities,gateways atthehost andhome ends
of the tunnel, and a STUN/rendezvous server to help
setup the tunnel when the gateways are behind NATs.

5.1 Co-ops and co-op local addresses
To managetheguests’ identities, we assumethatthe
residents of a city will form a co-op to share Wi-Fi acc
ess. Membershipisvoluntary(butrequiredforguest
access); but the scheme allows for incremental deploym
ent. Evenif only tworesidentsaremembers,they can
reciprocally share Wi-Fi at each others’ houses. The
utility of the co-opgrows as more residentsjoin.

Each mobile device of a member is assigned a unique
privateIP address(say fromthelarge10.x space). We
call this the coop-local
address. Since the coop-localadd
ressis unique, members canfreelyuse theirdevicesfor

4


guestaccess regardless of which other member’sdevices
are concurrently guests at the same host. Also notice
that hosts can create a simple firewall rule to isolate all
coop-local addresses from the rest of the machines on
the host’s network.

One subtlety is that the coop-local address is only
usedtodistinguishbetween nodes sharing ahostAP.As
we discuss below, the guest’s coop-local address is hidd
en behind the host’s NAT, so none of the other nodes
in theInternet(including thehome) needbe aware of
this address. The guest’s applications use a different
“vpn-local” address (also discussed below). Furtherm
ore, the home is configured as the default gateway
of the guest. Thus, the coop-local address space may
safely be reused elsewhere. In particular, the guest
could log into her office VPN7
and access intranet mac
hines which may alsobeinthe coop-local address space.

5.2 NAT traversal
Many residential networks are assigned IP addresses
dynamically. Some are alsobehindNATs. Consequently,
gateways need to discover their current public IP add
resses andpunchNATholes[7] tobe reachablefrom
the other ends of the tunnels. The co-op enables this
through a STUN [15] server which the gateways can
query to obtaintheir currentNATbindings(publicIP
address+port). As shown in Fig. 2, the server also fac
ilitates rendezvous and tunnel setup by pushing the
learned NAT bindings to all other members in a secure
manner.

Periodickeepalives are used to keepNAT holes open.
Also, agatewaythatisbehind a restricted cone or symm
etric NAT may need to punch separate holes to each
gatewayinthe co-op. In afew rarecases(e.g. NATs
employing deep packet inspection), NAT holes cannot
be punched, and packets between two gateways may
have to be relayed through the rendezvous server.

In summary, allgatewaysknow the currentmappings
between the other members’ coop-local address and the
globallyreachableIP address(orNAT binding) of their
home gateway. We use this fact below.

5.3 Gateways: tunnel end points
As shown in Fig. 2, each member’s AP implements
agateway thatperformsdifferentfunctions atthe ends
of the tunnels to support and maintain them.

5.3.1 Host gateway
At the host, where the tunnel begins, the gateway
acts as aNAT andtranslatesthe coop-local addresses of
guests asits own addresstothe external world(specifi
cally, to the guest’s home). To send packets back to
home, guests can remember the home’s IP from the

7
This
VPN
would
operate
over
the
VPN
tunnel
between
the
host
and
the
home
that
we
describe
below.


last contact. If the home’s IP has changed, and the
guest sends a packet destined for the old address, the
host drops it and sends the guest an ICMP “No route
tohost” message. Theguest can thenquery and obtain
the currentaddressof thehomefromthehostgateway.

5.3.2 Home gateway
At the home, where the tunnel ends, the gateway
appears as a VPN server. We assume an SSL VPN-like
solution, similar to OpenVPN. In OpenVPN, when the
guestjoinsthehomeVPN, a virtual(TUN) deviceis
activated on the guest machine and given a vpn-local
address from the private IP address space. The vpnl
ocal address is private to the home’s
VPN and can
be safely reused, for instance by other machines on the
host’s network(asinFig.2).

Thehomegateway alsoactsasaNAT and translates
the guest’s vpn-local address as its own address (the
home address) to the rest of the public Internet. Thus,
theguest may accesstheInternetthroughits ownISPp
rovided connection to the Internet. If only web access
isdesired, an alternate method is to run aHTTPproxy
on the home’s VPN. The guest’s HTTP requests are
forwarded to the proxy, which then fetches it from the
WWW. If theproxy caches websites, this maybe faster
than the NAT option.

5.4 Security features
Maliciousguests are not allowed to spray randomIP
addresses with traffic. As hinted in Section 5.3.1, the
host gateway acts as a firewall with rules that only all
ow encrypted (VPN) packets between the coop-local
addressesof amember andthecurrentIP address(or
NATbinding) of the member’shome. Alternately, orin
addition to the firewall, the host could adopt a policy
of cutting off a particular guest if no response is heard
from the home within a reasonable time window – if
theguest successfully authenticated with the home and
opened a VPN tunnel, there should be traffic sent from
the home, in response to the guest’s packets.

Coop-local addresses cannot be easily spoofed. The
host end of the tunnel only allows packets destined to
thehome, and theVPN server at the home end authent
icates the guest. Our scheme is impervious to Sybil
attacks thatdepend upon thefact thatIDs are only virt
ual, and one can create too many of them. In our case,
since there is a realhome addressbehind the coop-local
IDs, and all packets pass through this address, Sybil
attacks cannot be launched.

Notice that the ICMP message generated when a
coop-local address sends packets to a destination other
than its corresponding home is only sent to coop-local
(10.x)addresses, andis thus contained within thehost’s
network. We ignore the minor risk that a malicious
guest could send spurious ICMP messages to another

5


guestat the samehost, although this could certainlybe
thwarted by more firewall rules.

Host firewallscannotbecompromisedwithfalseNAT
bindings for malicious home gateways, because STUN
requires its clients to authenticate themselves. Also,
thehost exchangesperiodickeepalives with thehome’s
current address to keep NAT holes open, which would
not work if the NAT binding was wrong.

Simplebandwidthlimitingbyhosts can alsobehighly
effective inpreventingDoS attacksby maliciousguests.

6. DISCUSSION
6.1 Supporting highly mobile guests
Witha very simple optimisation,highly mobileguests
canpreserve application sessions as they movefrom the
range of one host AP to another. The guest’s applicat
ions use theTUNinterface andits associated vpn-local
address, which is assigned by the home’s VPN server.
After tunnel establishment, theVPN server alsopushes
the VPN’s default gateway, DNS server, etc. to route
all traffic over it. Since these values seldom need to
change, the VPN server can be configured to always
assign the same values for a given guest. In conjunct
ion with disconnection-tolerant transports and TCP
extensions[5,13],preserving the vpn-local address all
owshigher-levelsessionstobepreserved across accesses
through different host APs.

Forfasterlinkestablishment, the vpn-local addressto
use for the TUN interface as well as the other network
parameters above could also be statically configured on
the guest machine. Establishing a secure VPN tunnel
also involves an initial TLS handshake to exchange the
random secret key used to encrypt the data. A shared
static key can be used to avoid this overhead.

We carefully chose to use fixed coop-local addresses
to eliminate the overheads ofDHCP when aguestdocks
with anewhost. Studiesin[2] showthathighly mobile
clients such as cars are typicallyin contact with agiven
AP only for very brief periods (on avg. <10 secs. at
55kmph)and the time spent acquiring a newIP address
can significantly affect the time availablefor usefuldata
access. With fixed coop-local addresses and the above
optimisations, docking with a new host only involves
associating with its SSID. After this, the guest may
start sending packets back to the home network.

6.2 Co-op scope and limitations
The co-operative is intended to be operated on the
scale of a city. Creating tunnels over larger regions
would cause unacceptable delays. Also, the host gatew
ay’s firewall size increases roughly linearly with the
size of the co-op, which places limitations on the numb
er of members that can be supported. Larger co-ops
canbe supportedby only creating rulesforgueststhat

dock with the host. (Instead of creating firewall rules
when the coop rendezvous server pushes a new coop-
local ID to NAT-binding mapping, the host can query
the rendezvous server for the current binding when a
guest docks with the host. Clearly, this comes at the
cost of slower link establishment for the guest.)

Finally, some countries impose restrictions on the
contentthat canbe accessedintheirjurisdiction. If arb
itrarilylong tunnels are allowed, aguest who manages
to obtain atrusted endpoint outsideof thisjurisdiction
would be able to access “illegal” content. We do not
prohibit or support such tunnels, but point to the poss
ibility as a non-technical reason for why a co-op may
need tobe operated on alocal, ratherthanglobal, scale.

7. CONCLUSION
In major cities of the developed world, the density
of resident-operated Wi-Fi APs is sufficient to blanket
the whole swathes of the city with ubiquitous Internet
access. However,grantingInternet accessto aguestinv
olves taking on responsibility for the guest. We have
presented tunneling back to a trusted point in the Int
ernet as a means for hosts to handoff this responsibili
ty and thereby remove reservations about sharing their
private Wi-Fi AP with the other residents of a city.
Hosts further protect themselves by placing a firewall
between guests and their computers.Guests can easily
prevent hosts from snooping over their traffic by creati
ng a secure tunnel. Together, the residents of a city
could form a co-operative of trusted endpoints to safely
share Internet connectivity throughout the city, rather
than build expensive public Wi-Fi infrastructure.

8. ACKNOWLEDGEMENTS
We thank Rob Beverly, Ji Li, Eng-Keong Lua and
Mythili Vutukuru for reading previous versions of the
paper and suggesting many improvements. We also
thank David Clark for clarifying some policy and legal
aspects of our approach.

9. REFERENCES
[1] Bicket,
J.,
et
al.
Architecture and evaluation
of an unplanned 802.11b mesh network. In 11th
ACM
MOBICOM
Conf.
(2005).
[2] Bychkovsky,
V.,
et
al.
A Measurement Study
of Vehicular Internet Access Using In Situ Wi-Fi
Networks. In 12th
ACM
MOBICOM
Conf.
(2006).
[3] Champaign-Urbana
Wireless.
http://cuwin.net.
[4] Chandra,
R.,
Bahl,
P.,
and
Bahl,
P.
Multinet: Connecting to multiple IEEE 802.11
networks using a single wireless card. In IEEE
Infocom
(2004).
6


[5] Farrell,
S.,
et
al.
When TCP breaks: Delay-
and disruption-tolerant networking. IEEE
Internet
Computing
10, 4(2006), 72–78.
[6] Fon. http://www.fon.com/.
[7] Ford,
B.,
Srisuresh,
P.,
and
Kegel,
D.
Peer-to-peer communication across network
address translators. In USENIX
(2005).
[8] Good,
R.
Should I secure my Wi-Fi access
point? http://www.masternewmedia.org/news/2006/03/
07/should_i_secure_my_wifi.htm.
[9] Hale,
II,
R.
Wi-Fi liability: Potential legal risks
in accessing and operating wireless internet. Santa
Clara
Computer
and
High
Technology
Law
Journal
21
(2005).
[10] Lakshminarayanan,
K.,
and
Padmanabhan,
V.
N.
Some findingsonthenetworkperformance
of broadband hosts. In Internet
Measurement
Conference
(2003).
[11] Miu,
A.
K.,
Balakrishnan,
H.,
and
Koksal,
C.
E.
Improving Loss Resilience with
Multi-Radio Diversity in Wireless Networks. In
11th
ACM
MOBICOM
Conf.
(2005).
[12] Nikander,
P.
Authorization and charging in
public WLANs using FreeBSD and 802.1x. In
USENIX
(2002).
[13] Ott,
J.,
and
Kutscher,
D.
A disconnection
tolerant transport for drive-thru Internet
environments. In Infocom
(2005).
[14] Perkins,
C.
IP mobility support. RFC 2002
(Standards Track), Oct. 1996.
[15] Rosenberg,
J.,
Weinberger,
J.,
Huitema,
C.,
and
Mahy,
R.
STUN -Simple traversal of
User Datagram Protocol(UDP) through Network
Address Translators(NATs). RFC 3489
(Proposed Standard), Mar. 2003.
[16] Savage,
S.,
et
al.
Practical network support for
IP traceback. In SIGCOMM
(2000).
[17] Snoeren,
A.,
et
al.
Single-packet IP traceback.
IEEE/ACM
Trans.
Netw.
10, 6(2002).
[18] SoCalFreeNet. http://socalfreenet.org/.
[19] Stamm,
S.,
Ramzan,
Z.,
and
Jakobsson,
M.
Drive-bypharming.Tech.Rep.641,Dept. of
Computer Science, Indiana University, Dec 2006.
[20] Stow,
A.
Can you trust a wireless router?
http://www.cs.indiana.edu/~
atsow/mal-router/.
Accessed Jul 15, 2007.
[21] UMA. http://www.umatoday.com/umaOverview.php.
Accessed Aug 1, 2007.
[22] Whisher. http://www.whisher.com/.

To Be Continue…