LowCost Internet Access using mechanical backhaul

1
Low-Cost Internet Access using mechanical backhaul

• S. Keshav
• University of Waterloo
• (Joint work with Aaditeshwar Seth, U. Waterloo)

2
kiosks are useful

• Kiosk shared technology human operator
• Provide a variety of government-to-citizen
  services
• birth and death certificates
• land records
• consulting on medical and agricultural problems
• crop and personal insurance
• banking
• ... (200 from eGovServices)

(Courtesy Kentaro Toyama)
3
Kiosks are well-established

• Widely used in developing countries
• e.g. Indian Public call offices
• 150,000 operational in every corner of the
  country
• profitable, provide employment
• Ministry of Information Technology plans to set
  up 100,000 in the next two years
• has received bids from IBM, Sun, Oracle,
  Microsoft subcontractors

4
Kiosk connectivity

• Dial-up
• slow (28 kbps)
• flaky (due to harsh environment)
• Very Small Aperture Terminal
• expensive monthly rental
• spare parts are hard to get
• Long range WiFi
• still experimental
• expensive up front cost (for 18m tower)
• spare parts hard to get

5
mechanical backhaul
A bus carrying a 802.11 access point (Daknet
project)
Picture from Daknet project
Term suggested by A.A. Penzias
6
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

7
Goals

• Low cost
• lt 250/kiosk upfront lt50/month operational
  costs
• Reliability
• Allow user mobility
• Data privacy
• Ability to use existing Internet services
• Use all available networks (cell, dialup,
  WiFi....)
• Support both kiosk and laptop/PDA users

8
Whats hard about this?

• Both ends of a connection are not
  simultaneously present
• Cant use standard TCP/IP, DNS, SSL
• Mostly disconnected, rarely connected
• Opposite of usual assumptions
• for example, made by Mobile IP, HIP, I3, PCMP
  etc.
• Low-cost and reliability are stringent
  constraints
• Need to share resources without compromising
  integrity

9
what can we use?

• Cheap storage (lt 2/GB)
• Wireless networks
• Cellular networks
• Delay Tolerant Networking
• overlay network
• send messages (bundles) over potentially
  disconnected links
• like email, but better routing
• extensible naming, addressing, routing

10
design Principles

• Lower costs by sharing
• Store and forward self-describing data
• Separate locationing and addressing
• Use all links, opportunistically, if necessary
• Separate data and control plane
• Proxies for legacy support
• Replication for reliability

11
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

12
Architecture overview
13
Inside a kiosk

• Kiosk controller
• Soekris net 4501
• headless, keyboard-less single board computer
• 7W (can be solar powered)
• provides netboot, file system, WLAN access...
• Recycled PCs
• Typically P3/P4 with 256 MB RAM
• Cost 100
• Spare parts widely available

14
Ferries and gateways

• Also have a Soekris box with a WLAN card
• Contain 40-100 GB RAID 1 disk
• Gateways Internet access is typically dialup or
  DSL

15
Network model
16
(No Transcript)
17
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

18
naming and addressing

• Users, kiosks, ferries, and gateways all have a
  name
• Name any string for users, phone number or
  email
• For uniformity, system uses SHA1(string) 20
  bytes
• forwarding uses 20 byte strings
• no need for DNS or PKI (e.g.for HIP)
• GUID

19
dealing with disconnection custody

• Every potentially disconnected user registers
  with a custodian
• Custodian acts as rendezvous between sender and
  receiver
• anchor point to hide mobility
• Full address of a user is ltcustodian GUID, user
  GUIDgt
• Similar to name_at_mail_server
• Custodians keep track of registered users

20
custodian choice
21
Finding the custodian

• Sender may know a users name or phone number,
  but not his or her custodians name
• Home Location Register (HLR) in the Internet
  stores mapping from user GUID to its current
  custodians GUID
• Special custodian name unbound allows sender
  to send to a destination whose custodian is
  unknown
• Resolved by Internet gateway

22
Setting up HLR signaling

• On user registration or if custodian changes,
  custodian and HLR have to be updated (just like
  SIP registration)
• User sends REGISTER message towards
  custodian,who updates local state and then
  forwards it to Internet gateway
• Gateway updates HLR
• If there was an old custodian, it must be
  informed
• Several race conditions must be handled (details
  in paper)

23
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

24
Routing

• We have assumed that, given custodians GUID or
  users GUID, can find a path to it
• How?
• Unsolved DTN problem
• We have three potential solutions, none too
  satisfying

25
Routing Choice 1 Flooding

• Flood bundles everywhere
• Or, at least, everywhere within disconnected
  region
• Effective but inefficient
• Still, may be OK for small deployments

26
routing choice 2 reverse path forwarding
HLR
27
Reverse path forwarding

• Uses a single spanning tree
• Internet gateway is also custodian
• REGISTER message is used to create forwarding
  path for a GUID
• So, location update is also used for routing
  update
• Efficient but fragile

28
Routing choice 3 LInk state

• Standard flooding of link state packets
• Determining link metrics is a problem
• should reflect gateway load, both current and
  predicted
• Pathological cases easy to construct, because
  update latency is same time scale as forwarding
  latency
• may be able to overcome if we use GPRS for
  routing updates

29
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

30
Security goals

• Goals
• Privacy
• Authentication
• Why?
• Banking
• Secure email
• Bill payment
• Train and bus reservations

31
Security

• Why not use traditional PKI?
• finding public key when disconnected is slow
• revocation problems
• A nice solution
• What if your public key is your ID?
• A private key generator, generates corresponding
  private key

32
solution overview

• Use Identity-based cryptography
• Public key is just your identity
• Private key has to be given by private key
  generator (PKG)
• If you know correspondents identity, you can set
  up a secure channel to it
• But the PKG can spy on everyone
• Problems
• How to give a disconnected user a private key?
• Revocation
• Mutual authentication

33
Using IBC

• How to give a disconnected user a key?
• User goes to a kiosk and requests a public key
• kiosk owner manually verifies identity of the
  user
• Kiosk owner gives shrink wrapped package
  containing
• read-only device (smart card or USB dongle)
• scratch-off card with security number
• Dongle has one-time password, UID, and security
  number
• If security numbers match (unused password)
• send public key encrypted by password with
  cleartext UID
• PKG returns private key using same password

34
secure communication

• If you know a users public ID (email or phone
  number), you also know their public key
• Simply encrypting with this key guarantees
  privacy
• except that the private key generator can spy on
  everyone (!)

35
Mutual authentication

• Users, kiosks, and ferries can mutually
  authenticate each other
• because they all have their credentials derived
  from the same private key generator
• simply exchange certificates
• enables opportunistic communication
• as well as billing and auditing

36
Private key revocation

• Can do time-based revocation
• Identity -gt (Identity, epoch)
• Public key SHA1(Identity, epoch)
• When epoch expires, so does key
• but need to get new private keys from time to time

37
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

38
Application support

• Goals
• simple API
• session persistence
• intelligent use of multiple networks
• interaction with legacy servers.

39
Solution

• Opportunistic connection management protocol
  (OCMP)
• Java-based application layer protocol layered
  over TCP
• hides disconnections under directory API
• allows applications to choose (per-packet, if
  necessary) which interface to use
• uses proxies to work with legacy servers
• can relocate open connections between proxies

40
(No Transcript)
41
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

42
Overview

• Implemented as extension to DTNRG implementation
  (from IRB)
• Application support implemented in Java both on
  PDAs and kiosk-controller
• HLR is based on OpenDHT (from IRB)

43
Simplifications

• Assume every Internet gateway is custodian
• RPF routing (not load sensitive)
• No cell-phone based control plane
• No data replication

44
DTN-2 additions

• Control plane pulled out as a separate app.
• uses control API to add/delete routes and talk to
  peers
• Extended DTN namespace to allow ltcustodian GUID,
  user GUIDgt
• Identity mapping from GUID to unix UIDs in
  /etc/idmap
• Home Location Register implemented using OpenDHT

45
OCMP implementation

• OCMP implemented in Java
• Runs on Linux/WinXP/WinCE/.NET environments
• Open source
• being used at UC Davis, Sprint ATL, and IIT Delhi

46
Applications

• Mobile blog
• opportunistic upload of blog from PDA or from
  kiosk
• Jabber (XMPP)
• local jabber server uses OCMP to support kiosk
  users
• HTTP-get
• Email (under way)
• with Telugu keyboard
• Flickr upload (under way)

47
STATUS

• DTN2 extensions done and released
• OCMP done and reasonably stable
• Kiosk-controller ready to go
• Security being developed stand-alone, needs
  integration
• Plan first deployment (2 villages) in May 2006
  near Vishakapatnam, Andhra Pradesh

48
Outline

• The Big Picture goals, principles, and
  techniques
• Architecture
• Naming and addressing
• Locationing
• Routing
• Security
• Application support
• Implementation and status
• Conclusions

49
Goals

• Low cost
• lt 250/kiosk upfront lt50/month operational
  costs
• Reliability
• Allow user mobility
• Data privacy
• Ability to use existing Internet services
• Use all available networks (cell, dialup,
  WiFi....)
• Support both kiosk and laptop/PDA users

50
Conclusions

• Kiosks are a good idea
• cost-effective way to bridge digital divide
• Can be very successful if provided with reliable,
  low-cost communication
• Ferries are an attractive solution
• but disconnection challenges traditional
  assumptions
• We propose practical solutions for naming,
  addressing, routing, security, and application
  development
• Mostly working -- will deploy this May in
  partnership with eGovServices

51
Acknowledgments

• DTN code is from Intel Research, Berkeley
• OpenDHT is from Intel Research, Berkeley
• This work was supported by funding from the Intel
  Research Council, Sprint Corp, Nortel Networks,
  NSERC Canada, and the Canada Research Chair
  Program.
• this space for rent