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

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

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

5. Architecture – Naming Layer – Naming Supplement and not to replace DNS names. 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 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. 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. 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 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) 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. 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 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) 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 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. 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. 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. • Overlay routing with scoped flooding scale well as UIA focus on routing among the user’s friends and immediate social neighbors. 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. Dept of Computer Sci and Eng, University of Notre Dame

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

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

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

22. 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? Dept of Computer Sci and Eng, University of Notre Dame

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