Persistent Personal Names for Globally Connected Mobile Devices

1
Persistent Personal Names for Globally Connected
Mobile Devices

• Authors Bryan Ford, Jacob Strauss, Chris
  Lesniewski-Laas, Sean Rhea, Frans Kaashoek, and
  Robert Morris
• MIT

Presented by Qi Liao
2
Problem

• Device must have both a global name and a static,
  public IP address in order to communicate over
  Internet.
• Users must register with central naming
  authorities.
• Mobile personal devices usually have dynamic IP
  behind firewall / NAT.

3
Solution

• Dynamic DNS, Mobile IP, VPN
• Non-trivial configuration effort and technical
  expertise.
• Unmanaged Internet Architecture (UIA)
• A simple way to connect mobile personal devices
  via personal names organized into personal
  groups.
• Form a user-friendly peer-to-peer naming
  infrastructure.
• Overlay routing using location-independent node
  identities.
• Two layers Name Layer and Routing Layer

4
Architecture Naming Layer Naming

• Concise personal name instead of long globally
  unique names (FQDN)
• ipod vs ipod.alicesm5186.myisp.com
• Personal names remain persistently bound to
  devices as they move.
• Each UIA device acts as an ad-hoc name server to
  support name lookups and synchronize namespace
  state.

5
Architecture Naming Layer Naming
DNS UIA
name resolution label1.label2.label3 (from right to left) Example AlicePC.myisp.com Same Example PC.Alice
closure Centrally-managed global root zone Self-managed personal root group

• Supplement and not to replace DNS names.

6
Architecture Naming Layer EID

• Each device is identified by a cryptographic
  endpoint identifiers (EID).
• A hash of the nodes public key
• Example RSA 1024-bit MD5 or SHA-1 ? 128-bit
• Basics of Public-key Cryptography

7
Architecture Naming Layer EID

• (continued)
• No identity theft
• Self-configuring, self-certifying
• Globally unique without reference to central
  authorities
• Stable over time, and do not change when devices
  move or re-connect
• Contains no topology info
• not human-readable.
• Used by UIA Routing Layer to forward traffic.
• Shared device may have a separate EID for each
  user account.
• UIA-aware applications bind to users EIDs rather
  than a host-wide IP address, thus providing
  user-granularity authentication and access
  control.

8
Architecture Naming Layer Namespace State
Management

• The devices gossip namespace changes.
• Use an epidemic protocol to distribute updates of
  each groups state among the devices.
• Push/pull
• Push New log record ? repeatedly push it to a
  randomly-chosen peer until it contacts a peer
  that already has the record.
• Pull periodically contact a randomly-chosen peer
  to obtain any missing records.

9
Architecture Naming Layer Namespace State
Management

• 4 record types
• Create owner EID of a new series
• Link binds a human-readable label to an EID.
• Merge joins two series to form one group
• Cancel cancel record ID

10
Example Architecture Naming Layer

• Time 1 Device Initialization
• Device writes a create record (forming a new
  series/personal root group), and a link record
  (giving a personal name and set the owner flag)
• Time 2 Merge Device Groups
• Device writes a merge record (pointing to the
  other devices root series via introduction)

11
Example Architecture Naming Layer

• Time 3 Meeting Other Users
• Each device writes a link record to its own root
  series referring to the other devices root
  series without setting the owners flag
• Time 4 Transitive Merge
• Merge of three root series
• Hard Case what if label conflicts happen?
• Same name for multiple targets
• Name resolution fails
• Must explicitly resolve the conflict.

12
Example Architecture Naming Layer

• Time 5 Renaming Labels and Resolving Conflicts
• Cancel record (delete) and writes a new link
  record cell
• Time 6 Creating Shared Groups
• Create record (PhotoClub), two link records

13
Example Architecture Naming Layer

• Time 7 Revoking Ownership
• Hard Case
• Cannot cancel record (cells hidden ownership)
• A new create record (Deep clone of original group)

14
Architecture Routing Layer

• Naming Layer
• resolve device personal name to a
  location-independent EID.
• Routing Layer
• locating the target device using its current IP
  address, and forwarding traffic to it through
  other devices if direct connectivity is
  unavailable.
• Based on previous work Unmanaged Internet
  Protocol (UIP)
• Problem with IP
• good scalability, but bad usability.
• Problem with ad-hoc routing
• good self-management, but bad scalability.
• ? UIP

15
Architecture Routing Layer

• UIP not to replace IP but to run on top of it, as
  a new network layer component.

16
Architecture Routing Layer

• First, a src dev attempts a direct TCP conn to
  IP/port of its last connected target.
• If fails, it floods a location request (EID,
  traversed IP/port) through the overlay, response
  forwarded back through the same path.
• If location lookup request is successful, src dev
  directly connects to the target dev if reachable
  (no NAT), or forwards traffic via source-routing
  through the discovered path.

17
Architecture Routing Layer

• Hard Case
• What if a device receives a duplicate request for
  the same EID as an outstanding request?
• It forwards the new request anyway according to
  its token count, giving peers for which there
  were not enough tokens in previous instances
  another chance to receive the request.
• Token count to limit the scope of location
  request floods.

Token-count Hop-count
Total of devices to which a request may be forwarded The total of times each request may be re-broadcast.

• Overlay routing with scoped flooding scale well
  as UIA focus on routing among the users friends
  and immediate social neighbors.

18
Architecture Routing Layer Overlay
Construction

• How to choose peers?
• Stable
• Meet an availability threshold at the same public
  IP/port in the recent past.
• Closest friendship distance
• 1 for direct peers (within the users personal
  group and immediate linked group)
• 2 for the direct peer of a direct peer, etc.
• How to discover new peers?
• Devices periodically exchange their potential
  peer set within a configurable max friendship
  distance.

19
Implementation

• Two user-level daemon
• Naming layer (Python)
• Routing layer (C).
• GUI for browsing and controlling devices and
  groups.
• UIA-aware applications use Sun RPC to interact
  with the naming and routing daemons.
• Legacy App?
• Tun wrapper Disguises EID as device local IP
  address and uses the kernels tun device to
  tunnel IP packets over UIAs routing layer.
• DNS proxy Intercepts name lookups and resolve
  UIA names to device local IP addresses for the
  corresponding EIDs.

20
Evaluation Results

• UIA has not been widely deployed.
• So, can only evaluate through simulation under
  Orkut graph model (2362 devices)
• Tradeoff tokens needed to locate a target
  device successfully. (tokens? ? success rate of
  locating a target dev ?, but cost of concluding a
  unreachable dev ?)

success rate for locating devices
total number of messages sent per successful
location lookup request.

• Interpretation/Conclusion
• Left fewer stable devices, few requests
  succeeded. Those that do succeed do so cheaply.
• Right more stable devices, more successful
  requests without flooding (because stable targets
  are reachable directly at their last known
  IP/port.)
• Token-count is better than hop-count for two
  reasons overlay network is highly non-uniform
  and highly redundant.

21
Summary

• Problem
• global name and a static, public IP
• must register with central naming authorities.
• Mobility issues, dynamic IP, firewall / NAT.
• Solution
• Unmanaged Internet Architecture (UIA)
• Personal name space with overlay routing using
  location-independent cryptographic identities.
• Name Layer
• resolve local persistent personal names to
  cryptographic identifier.
• supplement and not to replace DNS
• Routing Layer
• Ad-hoc routing through social overlay network via
  scoped flooding.
• Benefit of identity-based routing 1) NAT
  traversal 2) Bridging between IPv4 and IPv6 3)
  Mobile users 4) Security, host/user
  authentication, etc.
• Not to replace IP routing but to run on top of it
• Conclusion
• Personal namespace with identity-based routing is
  more desirable than DNS and IP routing.

22
Discussion

• Are there any drawbacks of UIA?
• Hows UIA different from TeamTrak?
• Who choose readable name? Conflicts? Aliases?
• Naming without P2P EID routing? Broadcast (ARP)?
• Difference between levels of names?
• Personal name ? EID ? IP
• Uniqueness?

23
References

• Persistent Personal Names for Globally Connected
  Mobile Devices. Bryan Ford, Jacob Strauss, Chris
  Lesniewski-Laas, Sean Rhea, Frans Kaashoek, and
  Robert Morris. Proceedings of the 7th USENIX
  Symposium on Operating Systems Design and
  Implementation (OSDI '06), Seattle, Washington,
  November 2006.
• User-Relative Names for Globally Connected
  Personal Devices. Bryan Ford, Jacob Strauss,
  Chris Lesniewski-Laas, Sean Rhea, Frans Kaashoek,
  and Robert Morris. Presented at the 5th
  International Workshop on Peer-to-Peer Systems
  (IPTPS '06), Santa Barbara, CA, February 2006.
• Unmanaged Internet Protocol Taming the Edge
  Network Management Crisis. Bryan Ford.
  Proceedings of the Second Workshop on Hot Topics
  in Networks (HotNets-II), Cambridge,
  Massachusetts, November 2003.