1. Persistent Personal Names for Globally Connected Mobile Devices
1/14/2019
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
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

2. Dept of Computer Sci and Eng, University of Notre Dame
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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

3. Dept of Computer Sci and Eng, University of Notre Dame
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
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

6. Architecture – Naming Layer – EID
Each device is identified by a cryptographic endpoint identifiers (EID).
A hash of the node’s public key
Example: RSA 1024-bit MD5 or SHA-1  128-bit
Basics of Public-key Cryptography
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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 user’s EIDs rather than a host-wide IP address, thus providing user-granularity authentication and access control.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

8. Architecture – Naming Layer – Namespace State Management
The devices gossip namespace changes.
Use an epidemic protocol to distribute updates of each group’s 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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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 device’s root series via introduction)
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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 device’s root series without setting the owner’s 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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

13. Example: Architecture – Naming Layer
Time 7: Revoking Ownership
Hard Case:
Cannot cancel record (cell’s hidden ownership)
A new create record (Deep clone of original group)
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

15. Architecture – Routing Layer
UIP not to replace IP but to run on top of it, as a new network layer component.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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 user’s friends and immediate social neighbors.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

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 user’s 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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

19. Dept of Computer Sci and Eng, University of Notre Dame
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 kernel’s tun device to tunnel IP packets over UIA’s routing layer.
DNS proxy: Intercepts name lookups and resolve UIA names to device local IP addresses for the corresponding EIDs.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

20. Dept of Computer Sci and Eng, University of Notre Dame
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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

21. Dept of Computer Sci and Eng, University of Notre Dame
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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

22. Dept of Computer Sci and Eng, University of Notre Dame
Discussion
Are there any drawbacks of UIA?
How’s 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?
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame

23. Dept of Computer Sci and Eng, University of Notre Dame
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.
1/14/2019
Dept of Computer Sci and Eng, University of Notre Dame