Persistent Personal Names for Globally Connected Mobile Devices

Bryan Ford, Jacob Strauss, Chris Lesniewski-Laas, Sean Rhea, Frans Kaashoek, Robert MorrisMassachusetts Institute of Technology

Abstract

TheUnmanaged Internet Architecture(UIA) provideszero-configuration connectivity among mobile devicesthroughpersonal names. Users assign personal namesthrough an ad hoc device introduction process requiringno central allocation. Once assigned, names bind se-curely to the global identities of their target devices in-dependent of network location. Each user manages onenamespace, shared among all the user’s devices and al-ways available on each device. Users can also nameother users to share resources with trusted acquaintances.Devices with naming relationships automatically arrangeconnectivity when possible, both in ad hoc networks andusing global infrastructure when available. A UIA pro-totype demonstrates these capabilities using optimisticreplication for name resolution and group managementand a routing algorithm exploiting the user’s social net-work for connectivity.

1 Introduction

Network-enabled mobile devices such as laptops, smartphones, media players, personal digital assistants, gam-ing consoles, and digital cameras are becoming ubiqui-tous in the lives of ordinary people. The proliferationof these devices makes secure global peer-to-peer con-nectivity between them increasingly important. While ona trip, for example, a user in a cyber cafe may wish tocopy photos from his WiFi-enabled camera to his PC athome for storage and backup. Two users who meet in apark or other off-Internet location may wish to connecttheir WiFi devices to exchange photos or other informa-tion, and later re-establish a connection between the samedevices over the Internet after returning to their homes,without the risk of a third party intercepting the connec-tion. A Voice-over-IP user would like his WiMax phoneto be easily reachable by his friends wherever he and theyare located, but not to be reachable by telemarketers.

Convenient global communication over the Internet,however, currently requires the target device to haveboth a global name and a static, public IP address.Users must register with central naming authorities toobtain global names, and mobile personal devices usu-ally have dynamic IP addresses behind firewalls or net-work address translators [27]. Protocols such as Dy-

namic DNS [49], Mobile IP [37], and Virtual Private Net-works [22] provide piecemeal solutions to these prob-lems, but the configuration effort and technical exper-tise they require makes them deployable only by or-ganizations with dedicated network administration staff.User interface refinements alone cannot overcome thisdeployment roadblock, because the protocols depend oncentralized resources—global domain names and static,public “home” IP addresses—that are not part of mostconsumer-oriented Internet service packages. Ordinaryusers require a solution that “just works.”

TheUnmanaged Internet Architecture(UIA) is a peer-to-peer connectivity architecture that gives nontechnicalusers a simple and intuitive way to connect their mo-bile personal devices via convenientpersonal namesor-ganized intopersonal groups. A user canmergemultipleUIA devices to form a personal group, after which the de-vices work together to offer secure remote access to anydevice in the group from any other. The devices formingthe group present the user with a shared personal names-pace, which they optimistically replicate [26, 28, 47] toensure constant availability on each device whether on oroff the Internet. The devices gossip namespace changesas connectivity permits [12], and can propagate updatesvia mobile devices carried by the user [36].

UIA interprets personal names relative to personalgroups, so users can assign concise, meaningful nameslike ipod instead of long globally unique names likeipod.alicesm5186.myisp.com. In this way UIAconforms to the intuitive model with which users alreadymanage their cell phones’ address books. Users normallycreate personal names byintroducingdevices locally, ona common WiFi network for example. Once created,these names remain persistently bound to their targetsas devices move. Personal names are intended to sup-plement and not replace global DNS names [33]: userscan refer to personal names likephone alongside globalnames likeusenix.org in the same applications.

Different users can introduce their devices to nameother users and link their respective personal groups. Bobcan refer to his friend Alice asAlice, and if Alicecalls her VoIP phonephone then Bob can make callsto Alice’s phone using the namephone.Alice. Inthis way, UIA adapts peer-to-peer social networking ideaspreviously explored for other purposes [10,29,31,38,39]

to form a user-friendly peer-to-peer naming infrastruc-ture. Users can also create and collect names into adhoc shared groupsto reflect common interests or infor-mal organizations.

UIA devices cooperate in an overlay routing proto-col to provide robust location-independent connectivityin the face of changing IP addresses, Internet routingfailures, network address translators, or isolation fromcentral network infrastructure. Although scalable rout-ing with location-independent node identities is inher-ently challenging in general [21], UIA focuses on routingamong friends and nearby neighbors in the user’s socialnetwork. We expect the UIA routing algorithm to scalewell because each node only consumes storage and band-width to track other nodes in its immediate neighborhood.

UIA makes the following primary contributions, ex-panding on previously proposed ideas [19]. First, UIAintroduces a simple and intuitive model for connectingmobile devices intopersonal groups, providing ad hocuser identities, personal names, and secure remote access,without requiring the user to manage keys or certificatesexplicitly. Second, UIA presents a novel gossip and repli-cation protocol to manage the naming and group staterequired by this user model, adapting optimistic replica-tion principles previously developed for file systems anddatabases. Third, UIA leverages social networking to cre-ate a scalable overlay routing algorithm that can providerobust connectivity among social friends and neighborswithout relying on central infrastructure.

The next section introduces the operation of UIA de-vices from a non-technical user’s viewpoint. Section 3describes UIA’s design at a high level, Section 4 presentsUIA’s naming system in depth, followed by the routinglayer design in Section 5. Section 6 summarizes imple-mentation status and Section 7 evaluates the performanceof the prototype. Section 8 discusses future work, Sec-tion 9 presents related work, and Section 10 concludes.

2 User Experience

This section describes UIA’s operating principles fromthe perspective of a non-technical user; later sections de-tail how the system provides this user experience.

2.1 Introducing Devices

A UIA device ideally ships from its manufacturer pre-configured with a name for itself such aslaptop orphone, which the user can keep or change as desired.The device learns additional names as its userintroducesit to other devices owned by the same user or differentusers. The introduction process assigns persistent namesby which the device can securely refer to other devices.

In a typical introduction, the owner(s) of two devicesbring the devices together physically and connect themto a common local-area network. Each user then invokes

a local-area rendezvous tool similar to Bonjour’s [2] onhis device, finds the other device on the network, and se-lects “Introduce.” Each device displays anintroductionkey consisting of three words chosen randomly from adictionary, as shown in Figure 1. Each user then picksthe other device’s introduction key from a list of threerandom keys. If one of the devices has unintentionallyconnected to the wrong endpoint, such as an imperson-ator on the same network, then the matching key is un-likely to appear on the list, so the user picks “None ofthe above” and the introduction procedure aborts. Unlikeother analogous procedures [13], UIA uses short, user-friendly “one-time” keys that only need to withstand on-line and not offline attacks, and its multiple-choice designprevents users from just clicking “OK” without actuallycomparing the keys.

Users can follow the same procedure to introduce UIAdevices remotely across the Internet, as long as one de-vice has a global DNS name or IP address and the usershave a trustworthy channel through which to exchange in-troduction keys: e.g., a phone conversation or an authenti-cated chat session. We also envision alternative introduc-tion mechanisms adapted to specific rendezvous channelssuch as E-mail, web sites, SMS messages, or short-rangewireless links; the details of particular introduction mech-anisms are not crucial to the UIA architecture.

A user can introduce UIA devices either tomergehisown devices into apersonal groupsharing a commonnamespace, or to create namedlinks from his own groupto other users’ personal groups. The following sectionsdescribe these two forms of introduction, and other im-portant group management actions, with the help of anexample scenario illustrated in Figure 2.

2.2 Device Names and Personal Groups

At Time 1 in the scenario, Bob purchases a new lap-top and Internet phone, which come pre-configured withthe default nameslaptop andphone, respectively. AtTime 2, Bob uses UIA’s local rendezvous tool on eachdevice to find the other device on his home WiFi networkand selects “Introduce devices” on each. Bob chooses the“Merge devices” option in the introduction dialogs (seeFigure 1) to merge the devices into a personal group.

The devices in Bob’s group gossip both existing namesand subsequent changes to the group’s namespace asphysical network connectivity permits. Each device at-tempts to preserve connectivity to other named devicesas they leave the network and reappear at other locations,without user intervention whenever possible. Bob nowsees his two personal namesphone andlaptop on bothdevices, and can use these names for local and remote ac-cess. Working on his laptop at home, he uses his personalnamephone to reach the phone via his home WiFi LAN.When Bob subsequently takes his laptop on a trip, he can

Figure 1: Bob and Alice introduce their devices

remotely access his home phone from his laptop over theInternet (e.g., to check his voice messages), still usingthe namephone. UIA uses cryptography to guaranteethat an adversary cannot impersonate the device Bob callsphone, and cannot eavesdrop on his communication.

2.3 User Names and Social Networking

With the second form of introduction, users link theirpersonal groups together and assignuser namesto eachother, but retain exclusive control over their respectivepersonal groups. In the example scenario, Bob pur-chases a new WiFi-enabled cell phone at Time 3 andmeets Alice at a cafe before he has merged his cell phonewith his other devices. Bob finds Alice’s iPod usinghis cell phone’s local rendezvous tool and selects “Intro-duce as a new contact” (see Figure 1), and Alice doeslikewise. Bob’s phone suggests Alice’s self-chosen usernameAlice, but Bob can override this default (e.g., toAlice-Smith or Alice-from-OSDI) if he alreadyknows another Alice.

Bob and Alice can now refer to each others’ devicesby combining device names with user names in DNS-likedotted notation. If Alice runs a web server on her homePC, namedPC in Alice’s personal namespace, then Bobcan connect to Alice’s server by typingPC.Alice intohis laptop’s web browser, exactly as he would use a globalDNS name likeusenix.org.

If Alice’s personal web server is UIA-aware, she canuse her nameBob in the server’s access control lists sothat only Bob’s personal devices may browse certain pri-vate areas. UIA authenticates clients so that no one canimpersonate Bob’s devices to gain access to these areas.

2.4 Transitive Merging and Gossip

Bob now returns home and merges his cell phone with hishome phone, as shown at Time 4 in Figure 2. Bob’s homephone in turn gossips the cell phone’s group membershipto Bob’s laptop, so the laptop and cell phone can name

each other without him having to merge them explicitly.Alice’s devices similarly gossip her new link namedBoband learn about Bob’s three devices, after which she can,for example, refer to Bob’s laptop aslaptop.Bob.

Users can access or edit their personal groups from anyof their devices while other devices are unreachable. IfBob and Alice are on a bus together and disconnectedfrom the Internet, Alice can still reach Bob’s laptop fromher iPod via her namelaptop.Bob, even if they haveleft their other devices at home. Bob and Alice can con-tinue adding names for contacts they meet on the bus, andtheir other devices learn the new names via gossip laterwhen they re-connect.

2.5 Resolving Conflicts

Unfortunately, both of Bob’s phones happened to haveidentical default names ofphone, resulting in theirnames conflicting in his newly merged namespace. UIAnotifies Bob of the conflict, and he can continue usingthe non-conflicting namelaptop, but must resolve theconflict before the namephone will work again. Bobresolves the conflict on his cell phone at Time 5, by re-naming itcell while leaving the home phone with thenamephone. Bob’s other devices learn the resolvedname bindings via gossip, as do Alice’s devices, so Alicenow sees Bob’s phones asphone.Bob andcell.Bob.

If Bob makes conflicting namespace changes on twoof his devices while they are partitioned from each other,UIA detects the conflict once the devices reconnect. Bobcan continue using other non-conflicting names in thesame group while conflicts exist, and he can resolve suchconflicts at leisure on any of his devices.

2.6 Shared Groups

In addition to personal groups, users can createsharedgroupsto help organize and share their personal names.Bob and Alice discover at Time 6 that they share an in-terest in photography, and decide to start a photo club for

Figure 2: Example Personal Device Scenario

Figure 3: Groups and Ownership

themselves and other friends sharing this interest. To en-able members of the club to find each other easily andshare photos among their personal devices, Bob uses hislaptop to create a shared group namedPhotoClub inhis personal namespace. On creation, the shared group’sonly member is Bob himself. To add Alice to the group,Bob drags the nameAlice from his personal group intoPhotoClub, copying his name binding for Alice intothe shared group and making her the second member.Bob can similarly add other friends toPhotoClub, andthese names automatically appear in Alice’s view of thegroup the devices gossip the changes.

Although Alice can now refer to the new group asPhotoClub.Bob, she might like this group to appeardirectly in her own personal group instead of naming itrelative to Bob. Alice drags thePhotoClub name fromBob’s personal group into her own, giving herself a copyof the name leading to the same shared group. She cannow refer to group members using the same names thatBob uses, such asCharlie.PhotoClub.

2.7 Group Ownership

One or more members of a UIA group may be designatedasowners, or members allowed to modify the group. AsFigure 3 illustrates, Bob’s deviceslaptop, phone, andcell are owners of his personal group by default, al-lowing Bob to edit his personal group using any of hisdevices. The namesAlice andPhotoClub are notowners, so Alice and members ofPhotoClub can onlybrowse and resolve names in Bob’s namespace.

Groups can own other groups. When Bob creates hissharedPhotoClub group, UIA automatically includesa nameBob in the new group that gives Bob’s personalgroup ownership of the new group. After adding Alice tothe group, Bob can give her co-ownership by clicking theowner flag by her name in the group listing, enabling herto add or remove other members herself. Ownership istransitive: Bob can modifyPhotoClub using his laptopbecause Bob’s laptop is an owner of Bob’s personal groupand Bob’s personal group is an owner ofPhotoClub.

2.8 Security and Ownership Revocation

Returning to the scenario in Figure 2, Bob loses his cellphone at Time 7, and he is not sure whether it was stolenor just temporarily misplaced. If the cell phone was stolenand has no local user authentication such as a password orfingerprint reader, the thief might obtain not only Bob’sdata on the cell phone itself, but also remote access toservices authorized to his personal group via UIA names.UIA devices capable of accessing sensitive informationremotely should therefore provide strong local user au-thentication, and should encrypt personal data (includingUIA state) stored on the device, as Apple’s FileVault doesfor example [3]. The details of local user authenticationand encryption are orthogonal to UIA, however.

To minimize potential damage if a thief does break intoBob’s user account on his cell phone, Bob can revokethe cell phone’s ownership of his personal group. If thecell phone re-appears and Bob realizes that he just mis-placed it, then he can “undo” the revocation and returnthe phone to its normal status. If the cell phone remainsmissing, however, UIA ensures that no one can remotelyaccess personal information or services on Bob’s otherdevices via the lost phone once the revocation announce-ment has propagated to those devices. Similarly, the cellphone loses its access to the files Alice shared with Bobas soon as Alice’s PC, on which the files reside, learns ofthe revocation from any of Bob’s remaining devices.

2.9 Ownership Disputes

Revocation cuts both ways: a thief might try to “hijack”Bob’s personal group, using the stolen cell phone to re-voke the ownership of Bob’s other devices before Bobfinds that the phone is missing. In UIA’s current owner-ship scheme in which all owners have full and equal au-thority over a group, Bob’s devices cannot distinguish the“real” Bob from an impostor once a stolen device’s localaccess control is broken. UIA therefore allows any deviceto disputeanother device’s revocation of its ownership.

In the example scenario, when Bob next uses his lap-top, UIA informs him that his laptop’s ownership of hispersonal group has been revoked by the cell phone, whichBob realizes was stolen. In response, Bob issues a re-vocation of the cell phone’s ownership from his laptop.The two mutual revocations effectively split Bob’s orig-inal personal group into two new, independent groups:one containing only the cell phone, the other contain-ing Bob’s remaining devices. All existing UIA namesreferring to Bob’s old personal group, and any access au-thorizations based on those names, become unusable andmust be manually updated to point to the appropriate newgroup. Alice’s nameBob for example is now marked“disputed” in Alice’s namespace, and Alice’s PC rejectsattempts by any of Bob’s devices to access the files sheshared with Bob earlier using that UIA name. To update

her name for Bob and safely renew his access, Alice canre-introduce her devices directly to Bob’s the next timethey meet, or obtain a fresh link to Bob’s new personalgroup from a trusted mutual friend who already has one.

Group ownership disputes need not be permanent.Suppose two people who co-own a shared group get intoan argument, and split the group by issuing mutual re-vocations. If the original co-owners later settle their dif-ferences, they can undo their conflicting revocations orsimply merge their respective “splinter” groups back to-gether via UIA’s normal merge mechanism. Links to theoriginal group become unusable during the dispute, butfunction again normally after the dispute is resolved.

3 Basic Design

This section outlines UIA’s high-level design, which con-sists of separate naming and routing layers that togetherrealize the user experience described above. Sections 4and 5 detail the naming and routing layers, respectively.

3.1 Personal Endpoint Identities

UIA devices identify each other using cryptographicallyuniqueendpoint identifiersor EIDs. Whereas DNS mapsa name to an IP address, UIA maps a personal devicename such as Bob’slaptop to an EID. Unlike IP ad-dresses, EIDs arestableand do not change when devicesre-connect or move. UIA’s routing layer tracks mobilehosts by their EIDs as they change IP addresses, and canforward traffic by EID when IP-level communication failsdue to NAT or other Internet routing discontinuities.

A UIA device creates each EID it needs automati-cally by generating a fresh public/private key pair andthen computing a cryptographic hash of the public key.As in SFS [32], EIDs are cryptographically unique, self-configuring, and self-certifying, but not human-readable.As in HIP [34], UIA-aware network transports and ap-plications use EIDs in place of IP addresses to identifycommunication endpoints. (UIA can also disguise EIDsas “actual” IP addresses for compatibility with unmodi-fied legacy applications, as described later in Section 6.)

An EID corresponds to a particular user’s presence ona particular device. A user who owns or has access toseveral devices has a separate EID for each. A deviceaccessed by only one user needs only one EID, but a de-vice shared among multiple users via some form of lo-gin mechanism creates a separate EID for each user ac-count. Unlike cryptographic host identifiers in SFS andHIP, therefore, EIDs are not only stable butpersonal.

Personal EIDs allow multiple users of a shared UIAhost to run independent network services on the device.Since each user’s services bind to the user’s EID ratherthan to a host-wide IP address, UIA-aware network ap-plications can run exclusively in the context of the userand rely on UIA to provide user-granularity authentica-

tion and access control. When Bob connects his laptop tothe HTTP port at the EID to whichPC.Alice resolves,he knows he is connecting toAlice’spersonal web serverand not that of another user with an account on the samePC. Alice’s web server similarly knows that the connec-tion is coming from Bob and not from someone else us-ing laptop, because her namelaptop.Bob resolves toan EID specific to Bob’s account on his laptop.

3.2 Naming Principles

Each UIA device acts as an ad hoc name server to supportname lookups and synchronize namespace state acrossdevices. UIA names follow the same formatting rules asDNS names, consisting of a series oflabelsseparated bydots, and devices resolve UIA names one label at a timefrom right to left. To resolve the namePC.Alice, forexample, Bob’s laptop first resolves the rightmost com-ponentAlice to find Alice’s personal group, and fromthere resolves the second componentPC to find the EIDfor Alice’s PC as named in Alice’s personal group.

Whereas DNS resolution traverses a strictly hierarchi-cal tree of “zones” starting from a centrally-managedglobal root zone, each UIA device has a unique root forresolving UIA names, and users can link UIA groups toform arbitrary graphs. After Bob meets Alice at Time 3 inFigure 2, for example, Bob’s “root” group for UIA nameresolution, corresponding to his personal group, appearsto Alice as a “sub-group” namedBob. Conversely, Al-ice’s “root” group appears to Bob as a “sub-group” namedAlice. Since Bob’s and Alice’s naming relationshipforms a cycle in the graph of UIA groups, Bob could forexample refer to his own phone via the redundant namephone.Bob.Alice.

UIA groups may at times containlabel conflicts, orbindings of a single name to multiple distinct targets.When Bob at Time 4 merges his new cell phone withits default namephone into his personal group, whichalready contains another device namedphone, the twophone bindings result in a label conflict. Label conflictsalso arise if an ownership dispute splits thetarget that agroup name refers to, as described in Section 2.9. Nameresolution fails if it encounters a label conflict, preventingthe user from following ambiguous links before resolvingthe conflict. A conflict on one label does not affect the us-ability of other labels in the same group, however.

3.3 State Management

UIA uses optimistic replication [26, 28, 47] to maintain auser’s personal UIA namespace across multiple devices,guarding namespace state against device loss or failureand keeping the namespace available on all devices dur-ing periods of disconnection or network partitions. Eachdevice stores in an append-only log all persistent namingstate for its user’s personal group and any other groups of

Type Type-specific Record ContentCreate Owner: endpoint ID (EID) of owner device

Nonce:ensures uniqueness of new series IDLink Label: human-readable string

Target: device (EID) or group (series ID)OwnerFlag:grants group ownership if true

Merge Target: series ID (SID) to merge withCancel Target: record ID to cancel

Figure 4: Log Record Format

interest to the user, and uses an epidemic protocol [12] todistribute updates of each group’s state among the devicesinterested in that group.

UIA’s epidemic protocol uses a classic two-phase“push/pull” algorithm. In the “push” phase, when a de-vice creates a new log record or obtains a previously un-known one from another device, it repeatedly pushes thenew record to a randomly-chosen peer until it contacts apeer that already has the record. Thisrumor mongeringtechnique works well when few devices have the record,propagating the “rumor” aggressively until it is no longer“hot.” In the “pull” phase, each device periodically con-tacts a randomly-chosen peer to obtain any records it ismissing. Theseanti-entropyexchanges work best whenmost devices already have a record, complementing therumor mongering phase and ensuring that every devicereliably obtains all available records.

4 Naming and Group Management

This section describes in detail how UIA devices man-age and synchronize the namespace state comprising theirusers’ personal and shared groups.

4.1 Device Log Structure

UIA organizes the records comprising a device’s log intoseries, each series representing the sequence of changesa particular device writes to a particular group. The statedefining a group consists of one or more series, one foreach device that has written to the group. All devices par-ticipating in a group gossip and replicate all records ineach of the group’s series, preserving the order of recordsin a given series, but do not enforce any order betweenrecords in different series. Since UIA separates the nam-ing state for each group by series, devices can limit gossipto the records relating to groups they’re interested in, in-stead of scanning their neighbors’ entire device logs.

As shown in Figure 4, each log record contains a seriesID, a sequence number, data specific to the record type,and a signature. The series ID (SID) uniquely identifiesthe series to which the record belongs. The sequencenumber orders records within a series. The device thatowns a series signs each record in that series with its pri-vate key, so that other devices can authenticate copies ofrecords they receive indirectly. A cryptographic hash ofthe record yields aRecord ID, which uniquely identifiesthe record for various purposes described later.

UIA currently defines four record types, listed in Fig-ure 4 and summarized briefly below:

• Create: A createrecord initiates a new series ownedby the device writing the record, as identified in therecord’s owner field. The owner EID fixes the pub-lic/private key pair other devices use to authenticaterecords in the new series. The record ID of the cre-ate record becomes the new series ID; a random nonceensures the new SID’s cryptographic uniqueness. Thecreate record itself is not part of the new series: its ownseries ID field is usually empty to indicate that it is notpart of any series, but it can be non-empty for revoca-tion purposes as described later.

• Link: A link record binds a human-readable labelsuch asAlice to an endpoint ID or series ID denot-ing the link’s target. Links to devices, such as Bob’snameslaptop andphone, contain the EID of thetarget device. Links to groups, such asAlice andPhotoClub, contain the SID of some series in thetarget group. A link record has an owner flag indicat-ing whether the link grants ownership to the link’s tar-get, allowing the target to write changes to the groupcontaining the link record. We refer to a link with itsowner flag set as alink-owner record.

• Merge: A mergerecord joins two series to form a sin-gle UIA group. The union of all link and cancel recordsin all merged series determines the set of names thatappear in the group, forming a common distributednamespace. A merge takes effect only if the devicethat wrote the merge record also owns the target group,or if there is a corresponding merge record in the targetgroup pointing back to the first group.

• Cancel: A cancelrecord nullifies the effect of a spe-cific previous record, specified by the target’s recordID. With certain restrictions described below, linkrecords can be canceled to delete or rename groupmembers. Create, merge, and cancel records cannotbe canceled.

4.2 Namespace Operations

This section describes how UIA devices implement theimportant user-visible namespace control operations, interms of the specific records the devices write to their logs

at the events in the example scenario from Figure 2. Thefollowing section will then explain how devices evaluatethe contents of their logs to determine the effective stateof each group at any point in time.

Device Initialization: When Bob and Alice install orfirst start UIA on a device at Time 1, the device first writesa create record to its log, forming a new series to repre-sent the user’s personal “root” group on that device. Thedevice then writes a link record to the new series, givingitself a suitable default name such aslaptop. The de-vice sets the owner flag in this link record to make itselfthe sole initial owner of the group.

Merging Device Groups: When Bob introduces andmerges his devices at Time 2 to form a personal group,each device writes to its own root series a merge recordpointing to the other device’s root series. These cross-referencing merge records result in amerge relation-shipbetween the two devices, which begin to gossip therecords comprising both series so that each device eventu-ally holds a complete copy of each. This merging processdoes not actually create any new link records, but causeseach device to obtain copies of the other device’s existinglink records (the laptop’s link record for its default namelaptop and the phone’s record for its namephone) andincorporate those names into its own root group.

Aside from merging devices’ root series via introduc-tion, a user can use a single device to merge two arbitrarygroups, provided the same device already has ownershipof both groups. If Bob creates two shared sub-groups andlater decides they should be combined, for example, hecan merge them on any of his devices. The device writescross-referencing merge records to the relevant series, ex-actly as in the introduction scenario.

Meeting Other Users: When Bob and Alice introducetheir devices to each other at Time 3, the devices ex-change the series IDs of their respective root series, andeach device writes a link record to its own root series re-ferring to the other device’s root series. Bob’s new linkrecord namedAlice gives Alice a name in his personalgroup, and Alice’s new link record namedBob likewisegives Bob a name in her group. The devices do not set theowner flags in these new link records, giving Alice andBob only read-only access to each others’ namespaces.

Transitive Merge: Individual merge relationships inUIA are always pairwise, between exactly two series,but merge relationships combine transitively to determineeffective group membership. When Bob introduces hiscell phone to his home phone at Time 4, the two de-vices form a merge relationship between their respectiveroot series. Since Bob’s home phone and laptop alreadyhave a merge relationship, Bob’s laptop and cell phonetransitively learn about each other via gossiped recordsthey receive from the home phone, and the union of the

records in the three root series determine the contents ofthe resulting group. Since the merged group has two linkrecords namedphone with different target EIDs, the de-vices flag a label conflict onphone and refuse to resolvethis name.

Renaming Labels and Resolving Conflicts: WhenBob renames his cell phone tocell at Time 5 to resolvethe conflict, his device writes to its root series a cancelrecord containing the record ID of the link record defin-ing the cell phone’s previous name, then writes a newlink namedcell that is otherwise identical to the orig-inal link. Since one of the two conflicting link recordsis now canceled, the label conflict disappears, and thenamesphone andcell become usable on all of Bob’sdevices once they receive the new records via gossip. Bobcan resolve the conflict on any of his devices, because anygroup owner can cancel a link written by another device.

The user can also delete a name from a group outright,in which case the device writes a cancel record without anew link. The ownership granted by a link-owner record,however, can only be nullified by the revocation processdescribed later in Section 4.3.1.

Because UIA implements renames non-atomicallywith a cancel record coupled with a new link record, ifBob renamesAlice to Alice1 on his laptop and re-namesAlice to Alice2 on his phone while the twodevices are temporarily partitioned, on reconnection hewill have two namesAlice1 andAlice2 with no con-flict detected. This corner-case behavior, while perhapsslightly surprising, seems acceptable since it “loses” noinformation and at worst requires Bob to delete one ofthe resulting redundant names.

Creating Groups: Bob uses his laptop at Time 6 to cre-ate his sharedPhotoClub group. To create the group,the laptop first writes a create record to generate a freshseries ID. The laptop then writes two link records: first,a link namedPhotoClub in its root series pointing tothe new series, and second, a link namedBob in the newseries pointing back to the root series. The laptop sets theowner flag in only the latter link record, giving Bob’s per-sonal group ownership of the new group,withoutgivingPhotoGroup ownership of Bob’s personal group.

Suppose that Bob now uses a different device, his cellphone for example, to add Alice toPhotoClub. Bob’scell phone is already an indirect owner ofPhotoClub,because the cell phone is an owner of Bob’s personalgroup and Bob’s personal group ownsPhotoClub. Thecell phone does not yet have a series inPhotoClub,however, to which it can write records: initially only thelaptop, which created the new group, has a series in thegroup, and only it can sign records into that series. Thecell phone therefore creates its ownPhotoClub series,by writing a create record to form a new series owned

by itself, and then writing a merge record to this newseries pointing to the laptop’sPhotoClub series. Al-though no corresponding merge record in the laptop’sPhotoClub series points back to the cell phone’s newseries (in fact the laptop may be offline and unable to signsuch a record), the cell phone’s merge record takes ef-fect “unilaterally” by virtue of the cell phone’s indirectownership ofPhotoClub. The cell phone then writesa copy of Bob’s link to Alice into its newPhotoClubseries, and other devices learn of the new series and thenew name as they gossip records forPhotoClub.

Revoking Ownership: When Bob learns at Time 7 thathis cell phone is missing, he uses his laptop to revokethe cell phone’s ownership of his personal group, eitherby deleting the namecell from his personal group orby clearing its owner flag. To implement this revoca-tion, however, Bob’s laptop cannot merely write a can-cel record pointing to the link record forcell: the cellphone would still own a series in Bob’s personal groupand thus retain “hidden” control over the group.

To revoke the cell phone’s ownership, therefore, Bob’slaptop creates a new personal group for Bob and copiesthe original group’s name content into it. To create thenew group, the laptop writes a create record whose seriesID field is not empty as usual, but instead contains theSID of the laptop’s original root series. The laptop thenwrites link records to the new series corresponding to allthe active links in the old series, omitting links or own-ership flags to be revoked. The create record written intothe old root series indicates to all interested devices thatthe new series forms a group that is intended to replace oract as asuccessorto the original group.

As long as only one such “create successor” record ex-ists in Bob’s old personal group, all devices treat links toany series in the old group as if they linked to the succes-sor group instead. Upon receiving via gossip the recordsdescribing Bob’s new group, for example, Alice’s devicessubsequently resolve her nameBob to the new group, anduse it to calculate which devices should be given accessto resources she has authorized Bob to access, effectivelyrevoking the cell phone’s access.

If the cell phone writes a conflicting “create successor”record toits series in Bob’s original group, however, thenthe original group becomesdisputed, and other devicesrefuse to resolve links to any series in the original groupas soon as they learn about the dispute. Alice’s devicesthus refuse to resolve her nameBob and deny access toany resources she authorized using that name. Once Al-ice updates her broken link to refer to the correct succes-sor group, either by re-introducing with Bob or by copy-ing a fresh link from a mutual friend, her device writes anew link referring to a series in Bob’s new group, the oldgroup becomes irrelevant and Bob can again access Al-ice’s resources via the devices in his new personal group.

global M : membership table: SID→ SID setglobal O: ownership table: SID set→ EID setfunction eval membershipownership():

for each known seriessid:M [sid]← {sid}O[{sid}]← EID of device that owns seriessid

do:for each link-owner record in each seriessid:

if link target is a deviceteid:O[M [sid]]← O[M [sid]] ∪ teid

else if target is a seriestsid:O[M [sid]]← O[M [sid]] ∪O[M [tsid]]

for each merge record in each seriessid:tsid← target series ID of merge recordO[M [sid]]← O[M [sid]] ∪ O[M [tsid]]if owner EID of seriessid ∈ O[M [tsid]]:

O[M [sid] ∪M [tsid]]← O[M [sid]] ∪O[M [tsid]]for each series IDmsid ∈M [sid] ∪M [tsid]:

M [msid]←M [sid] ∪M [tsid]until M andO stop changing

Figure 5: Membership and ownership evaluation pseudocode

If link or cancel records exist on Bob’s other devicesthat his laptop has not yet received at the time of revo-cation, the laptop cannot copy these change records intothe new group and they becomeorphaned. Bob’s devicescontinue to monitor and gossip records in the old groupafter the revocation, however, to detect both orphans andownership disputes. If a device with ownership of thenew group detects an orphaned record written by itself oranother device with ownership of the new group (not a re-vokee), it automatically “forwards” the change by writinga corresponding record to the new group.

4.3 Group State Evaluation

This section describes the algorithms UIA devices use todetermine the current state of a given group from the setof log records they have on hand. Devices evaluate groupstate in three stages: (1) membership and ownership, (2)group successorship, and (3) name content.

4.3.1 Membership and Ownership

In the first stage, a UIA device collects the series IDs re-ferred to by all records in its log, and clusters them intosets based on merge relationships to form UIA groups. Atthe same time, the device computes the set of device EIDsto be considered owners of each group, either directly ortransitively. Group membership and ownership must becomputed at the same time because they are mutually de-pendent: group membership expansion via merge can in-troduce additional owners, and owner set expansion canplace additional merge records under consideration.

Figure 5 shows pseudocode for membership and own-ership evaluation. The algorithm uses a membership tableM mapping each known series ID to a set of series IDs

sharing a group, and an ownership tableO mapping eachgroup (represented by a set of series IDs) to a set of ownerdevice EIDs. The algorithm first initializes the entry inM for each series to a singleton set containing only thatseries, and initializes the owner set entry inO for eachsuch singleton group to the EID of the device that ownsthat series. The algorithm then repeatedly merges groupsand expands ownership sets until it reaches a fixed point.The algorithm terminates because member and owner setsonly grow, and each device knows of a finite number ofseries IDs at a given time.

In each iteration, the algorithm first follows link-ownerrecords, expanding the ownership set of the group con-taining a link-owner record according to the target deviceEID or the current ownership set of the target group, asapplicable. Across iterations, this step handles transitivepropagation of ownership across multiple groups, suchas Bob’s laptop’s ownership ofPhotoClub via the lap-top’s ownership of Bob’s personal group.

Second, for each merge record, the algorithm expandsthe ownership set of the group containing the mergerecord to include the ownership set of the target group,then checks whether the device that wrote the mergerecord isauthorizedby virtue of having ownership of thetarget group. The authorization check prevents a devicefrom merging a series into an arbitrary group without per-mission. In the symmetric case where two merge recordsrefer to each others’ series IDs, each merge is authorizedby the fact that the other merge grants ownership of itsown series to its target. Once a merge is authorized, thealgorithm combines the SID sets of the respective groupsto form one group containing all the merged SIDs, andsimilarly combines the respective owner sets.

4.3.2 Group Successorship

In the second stage, a device computes thesuccessorshipstatus of each group resulting from the first stage, in orderto handle revocations and ownership disputes. The devicefirst forms a directed graph reflecting immediate succes-sor relationships: a create record in seriesA yielding anew seriesB makes the group containingB a successorto the group containingA. Next, the device takes thetransitive closure of this graph to form a transitive suc-cessorship relation: ifB succeedsA andC succeedsB,thenC transitively succeedsA.

The device now assigns to every groupG one of threestates as follows. IfG has no successors, it is aheadgroup: no revocations have been performed in the group,and links to series IDs in the group resolve normally. Onthe other hand, if there is a second groupG′ that is a tran-sitive successor toG and is also a transitive successor toall other transitive successors toG, thenG′ is theundis-puted successorto G. In this case, links to series IDs ingroupG resolve to groupG′ instead. Finally, ifG has

Figure 6: Example Group Successorship Scenarios

successors but no undisputed successor, then groupG isdisputed, and links to series IDs inG do not resolve at all.

Figure 6 illustrates several group successorship sce-narios and the corresponding results of this algorithm.In scenario (1), two conflicting revocations have placedgroup A under dispute; A’s successor B also has a succes-sor due a second revocation in B but B is not under dis-pute. Scenario (2) is like (1) except a revocation has alsobeen performed in group C, forming a new head group E.Scenario (3) shows the result after the warring owners in(2) settle their differences and merge their head groups Dand E, resolving the original dispute over group A.

4.3.3 Name Content

In the third and final stage, for each head group to beused for name resolution, a device computes the group’snamespace state as follows. Given the set of all linkrecords in every series in the group, the device removesall link records targeted by a cancel record in any series ofthe group to form the set ofactivelinks. Any device thatowns a group can cancel a link written by another device,but a cancel cannot revoke ownership.

The set ofactive labelsin a group, shown in a names-pace browser for example, is the set of labels appearingin any active link record in the group. To beusable, allactive links for a given label must have the same permis-sions, and must target the same device EID or SIDs in thesame group. Otherwise the label isin conflict, as Bob’shome and cell phone are at Time 4 in the example. If Bobcreates identical links on different devices independently,such as by separately introducing both his cell phone andhis laptop to Alice to yield duplicateAlice links, thisaction does not create a label conflict when Bob mergeshis home and cell phone together because the redundantlinks have the same target and permissions.

5 Routing and Forwarding

Once the naming layer has resolved a device name to alocation-independent EID, UIA’s routing layer is respon-sible forlocatingthe target device—finding its current IPaddress—andforwarding traffic to it through other de-vices if direct connectivity is unavailable.

Many designs are conceivable that would performthese two functions, such as a general-purpose overlayrouting algorithm we explored previously [16]. In thiswork, however, we adopt a simple design that does not at-tempt to provide connectivity between arbitrary devices,but is optimized for connecting to devices in the user’simmediatesocial neighborhood: primarily the user’s owndevices and those of friends named in the user’s personalgroup, and occasionally “friends of friends,” but rarelymore indirect contacts. In practice we expect users tocreate (or copy from other users) names in their own per-sonal groups for others with whom they wish to interactregularly, justifying our assumed usage model.

In brief, UIA builds an overlay network between de-vices in its social neighborhood. To locate a remote de-vice by its EID, a device floods alocationrequest throughthe overlay to discover the EIDs, IP addresses, and portsof devices forming a path through the overlay to the tar-get. The originating device then connects directly to thetarget’s discovered IP address and port, or if the targetis not directly reachable (e.g., because of an interveningNAT), forwardstraffic to it by source-routing data via theexisting connections in the discovered path.

5.1 Overlay Construction and Maintenance

Each UIA device maintains an open TCP connection withup to a configurable number of overlaypeers. Ideally,these peers should be on the public Internet, so that adevice behind a NAT can receive messages from de-vices outside via its active peering connections. A deviceshould choose other devices when none on the public In-ternet are reachable, however, so that the overlay remainsuseful in ad hoc environments. Furthermore, the devicesof friends should be close to each other in the overlay, sothat location or forwarding paths between them are short.

To meet these goals, a device first prefers as peers de-vices that arestable, and secondarily prefers those thatare closest to it infriendship distance. A device is con-sideredstableif it does not have a private IP address [41]and has met a threshold level of availability in the recentpast. A peer’sfriendship distanceis roughly the numberof labels in the local device’s shortest name for that peer.The rest of this section explains how a device discoversstable peers and calculates friendship distances.

Each device maintains apotential peer setthat containspotential peers’ EIDs and the times, IP addresses, andports at which the device has connected to those peers inthe past. Initially, a device populates this set with the de-vices to which the user has directly introduced the device.To discover new potential peers, a device periodically ex-changes its potential peer set with those of other deviceswithin a configurable maximum friendship distance. Adevice adds to the set only those devices to which it is ableto establish a TCP connection when it discovers them.

A device classifies a potential peer asstableif it meetsan availability threshold (e.g., 90%) at the same public IPaddress and port in the recent past (e.g., the last week). Tomonitor availability, a device periodically chooses a ran-dom potential peer and attempts a connection to its lastknown location. A device need not have a static IP ad-dress to be classified as stable: a device with a dynamicnon-private IP address that changes infrequently, such asa home PC left on and connected via a DSL or cable mo-dem, will also typically be classified as stable.

A device computes thefriendship distanceof each ofits potential peers by assigning a distance of 1 to itsdirectpeers: those the naming layer identifies as devices in theuser’s personal group and in groups to which the user haslinked (the user’s immediate friends). The device thenassigns distances to indirect peers transitively, giving thedirect peer of a direct peer a distance of 2, for example.

To improve robustness, a device manufacturer can seedthe potential peer sets of its products with a set ofdefaultpeers, which devices treat as having an infinite friend-ship distance. Two newly-purchased mobile devices, af-ter being introduced and exchanging potential peer sets,thus have at least one stable peer in common at the outsetto help them re-connect after a move. Once the mobiledevices discover other stable peers at smaller friendshipdistances, however, they prefer the new devices over thedefault peers, mitigating the manufacturer’s cost in pro-viding this robustness-enhancing service.

5.2 Token-limited Flooding

To communicate with a remote device, a device first at-tempts a direct TCP connection to the IP address and portat which it last connected to the target, if any. If this con-nection fails or the originator has no address informationfor the target device, it floods a location request throughthe overlay to locate the target by its EID.

UIA uses atoken count, in place of the traditional hopcount [6], to limit the scope of location request floods.The token count bounds the total number ofdevicestowhich a request may be forwarded, rather than the num-ber of times each request may be re-broadcast. This dis-tinction is important for two reasons. First, although de-vices seek to connect with a fixed number of peers, thenumber of devices that choose a given device dependson the target’s stability and popularity, so the overlay’sdegree is highly non-uniform. Hop count is thus a poorpredictor of the number of devices a request will reach.Second, the overlay network is highly redundant: twofriends’ devices are likely to share many common peers,for example, so searchingall devices within some dis-tance of a request’s source is often unnecessary.

Location requests contain the EIDs, IP addresses, andports of devices they have traversed; devices forward re-sponses back through the overlay along the same path.

A device with an open TCP connection to a request’starget immediately responds with the target’s IP addressand port. Otherwise, it subtracts one token for itself, di-vides the other tokens among its peers not already in thepath, distributing any remainder randomly, and forwardsthe request to those peers that receive a non-zero count.The device retains the request’s target EID and return pathfor a short period, waiting for the forwarded requests tocomplete, and replying to the original request whenanyof the forwarded ones succeed or whenall of them havefailed. A request also fails if the source has not received asuccessful response within a timeout. If a device receivesa duplicate request for the same EID as an outstandingrequest (e.g., along a different path), it forwards the newrequest anyway according to its token count, giving peersfor which there were not enough tokens in previous in-stances another chance to receive the request.

As shown in Section 7, most location requests succeedwithin the near vicinity of the source in the overlay net-work. To limit the cost of the search, a device thus ini-tially sends each request with a limited number of tokensand retries after each failure with a multiplicatively in-creased number, up to some maximum.

5.3 Source-Routed Forwarding

To communicate with the target device after receiving asuccessful location response, the originator tries to opena direct connection to each device in the response path,starting with the target itself and proceeding backwardsalong the path until a connection succeeds. The originatorthen source-routes messages to the target along the tail ofthe path starting with the device to which it connected.

Consider for example two devicesa andb behind dif-ferent NATs, both of which peer with a common stabledevices. Whena performs a location request forb’s EID,it discovers the patha → s → b. Devicea then tries toopen a direct connection tob, but b’s NAT blocks thatconnection, soa forwards traffic tob throughs instead.Devices itself initiates no location requests, but merelyforwards traffic along the path specified bya.

6 Implementation

A prototype UIA implementation currently runs on Linuxand Mac OS X. As illustrated in Figure 7, the prototypeconsists of two user-level daemons implementing UIA’snaming and routing layers, respectively, and a graphi-cal application for browsing and controlling devices andgroups. The control application and other UIA-aware ap-plications on the device interface directly to the namingand routing daemons via Sun RPC. Through these inter-faces, UIA-aware applications can resolve UIA names toEIDs, explore and modify groups on behalf of the user,send packets to EIDs, receive packets on the device’sEID, and discover peers on the local-area network.

Figure 7: Structure of UIA Prototype Implementation

6.1 Prototype Status

The name daemon is written in Python and implementsthe design described in Section 4, providing group cre-ation, merging, named links between groups, namingstate gossip, state evaluation, multi-component name res-olution, and ownership revocation. The name daemondoes not yet detect and copy orphaned change recordsacross revocations as described in Section 4.2, however.

The prototype routing daemon implements in C++ thealgorithms described in Section 5. The router uses Bon-jour for local-area device discovery, and uses SSL overTCP connections for secure communication.

The UIA control application allows the user to browsethe UIA namespace and create and modify groups, as il-lustrated earlier in Figure 3, and supervises the device in-troduction process as illustrated in Figure 1. The controlapplication is still unpolished and does not yet fully sup-port shared groups or revocation, however.

6.2 Support for Smaller Devices

We have ported the UIA prototype to the Nokia 770 In-ternet Tablet, a Linux-based Internet appliance with anARM processor. The naming and routing layers havethe full functionality of the regular Linux/Mac version ofUIA, but the port of the GUI control application is not yetcomplete. In general, we expect the routing and namingmodules to port easily among smaller devices, while theGUI component requires more modifications because ofthe more specialized and restrictive user interface frame-works available on each class of mobile device. UIA doesnot rely on extensive data entry or other forms of userinteraction that are fundamentally difficult to achieve onsmall devices, however.

6.3 Legacy Application Support

The UIA prototype supports legacy applications througha tun wrapper and DNS proxy. Thetun wrapper dis-guises EIDs as device-local IP addresses and uses the ker-nel’stun device to forward applications’ TCP and UDP

packets for these special IP addresses over UIA’s routinglayer. The DNS proxy similarly intercepts name lookupsmade by local applications and resolves UIA names todevice-local IP addresses for the corresponding EIDs. Wehave run Apache, Firefox, OpenSSH, and Apple’s Per-sonal File Sharing over UIA using this legacy interfacewithout modification or recompilation.

UIA’s legacy application support layer makes the user’spersonal group appear to applications like a global virtualprivate network, by intercepting network-local broadcastpackets that applications send to UIA’s special IP ad-dresses and forwarding them securely to each of theuser’s personal devices. Because of this feature, manybroadcast-based “local-area” service discovery protocolssuch as Bonjour automatically work across all the devicesin the user’s personal group, even when some of the de-vices are in fact remote. We have used Apple’s Bonjour-based Personal File Sharing, for example, to locate andshare files remotely between devices in a UIA personalgroup as if they were present on the same LAN.

6.4 Experience with UIA

We currently run the UIA prototype on a number of desk-top and laptop machines in our lab, and regularly run ex-isting applications such as SSH over UIA to reach ourmobile devices via their short personal device names.UIA automatically accounts for IP address changes andtraverses NATs as necessary; SSH connections openwhen we take a laptop home need not be restarted. Al-though these uses are already possible via alternate pro-tocols such as mobile IP, the complexity of configuringthese alternatives has generally deterred even those of uswith the necessary technical knowledge from deployingthem. We feel that UIA’s zero-configuration paradigmfor personal naming and connectivity provides a crucialmissing element in making mobile devices usable.

7 EvaluationUIA’s primary goal is convenience and usability by non-technical users, a goal that can only be evaluated ef-fectively once UIA has been deployed longer and morewidely in the field. We can however evaluate key perfor-mance characteristics of the routing layer through sim-ulation, to verify that the proposed design is capable ofproviding the desired connectivity on realistic networks.

7.1 Experimental Setup

We use as our simulated network a crawl of the socialnetworking site Orkut gathered by Li and Dabek [29].This graph is merely suggestive; until UIA is more widelydeployed, it will not be clear how accurately the Orkutgraph characterizes UIA’s likely usage model. The graphhas 2,363 users, which we take to represent devices, asif each user owned one device. Friend relationships arebidirectional, and the number of friends per user is highly

skewed: the median is only 7, but the most popular userhas over 1,000.

Our simulator takes as input apercent stableparame-ter and randomly chooses that percent of the devices tobe stableand publicly accessible. All other devices thesimulator considers to bemobileand inaccessible exceptthrough some stable device, as if behind a NAT. We as-sume that all devices agree as to which devices are stable.

Each device chooses 16 peers and allows at most 64devices to choose it, to limit each device’s overlay main-tenance cost in a real network. Devices choose peers inorder of friendship distance. A device can only choose agiven target as a peer if the target does not already have64 peers, or if the new device is closer than one of thetarget’s existing peers, in which case the target discards arandom peer at higher friendship distance. Since we donot yet have traces with which to simulate the network’sevolution, the simulated devices choose peers in randomorder, iterating until the network reaches a fixed point.

The simulator then performs token-limited location re-quests on the resulting overlay between 10,000 randompairs at friendship distances 1, 2, and 3. Each lookupstarts with 16 tokens, and doubles after each failure, upto a maximum of 256 tokens. The simulator records thepercentage of requests that succeed after a given numberof rounds and the total number of messages sent.

7.2 Location Success Rate

An important performance metric for the location algo-rithm is the number of tokens needed to locate a targetdevice successfully. Using more tokens increases thechance of success (assuming that the overlay is in factconnected), but also increases the cost of concluding thatan unreachable device is offline. Figure 8 shows the suc-cess rate measured in the simulation for locating devicesat friendship distance 1. Using 256 tokens, the locationalgorithm achieves greater than a 99.5% success rate for10% or more stable devices. Using 64 tokens the algo-rithm achieves 97.5% success for 10% or more stable de-vices. The vast majority of requests—80% of requestsat 10% or more stable devices—succeed within the firstinexpensive round of 16 tokens.

At the far left of the graph where few stable devicesare available, the success rate drops off because each sta-ble device can only support 64 peers, and there are notenough stable devices for each mobile device to choosea full 16 peers, or in some cases any. As the percentageof stable devices increases, a linearly increasing numberof location requests are to stable devices that can be con-tacted directly without flooding, thus requiring no tokens.

We also measured the success rates for locating de-vices at friendship distances of 2 and 3, though we omitthese graphs for space reasons. The results for distance2 are almost as good as for distance 1, presumably be-

0

0.2

0.4

0.6

0.8

1

0 20 40 60 80 100

Fra

ctio

n o

f C

onnec

tions

Succ

essf

ul

Percent Stable Nodes

256 Tokens64 Tokens32 Tokens16 Tokens0 Tokens

Figure 8: Location request success rate

0

20

40

60

80

100

120

140

160

180

200

0 20 40 60 80 100

Mea

n M

essa

ges

Sen

t P

er C

onnec

tion

Percent Stable Nodes

Ideal hop count-limited256 Tokens

Figure 9: Mean messages sent per location request

cause two devices at friendship distance 2 are likely topeer with some common stable device at distance 1 fromeach of them. Success rate drops considerably at distance3, however, achieving only 50% success with 256 tokensin networks of 40% or more stable devices, for example.

7.3 Messages Sent

The lower line in Figure 9 shows the total number ofmessages sent during successful token-limited lookup re-quests for devices at friendship distance 1. A request’smessage count is ultimately bounded by its token count,but is often much less because successful lookups usuallydo not require all available tokens.

At the left edge of the graph, there are not enough sta-ble devices for every mobile device to have a peer, so fewrequests succeed. Those that do succeed do so cheaply,however, because all of the connected mobile deviceshave clustered around the same few stable devices. Themessage count peaks near the point where the number ofstable devices becomes barely sufficient to serve all ofthe mobile devices, so the requests usually succeed butonly after contacting many devices. As the number ofstable devices increases further, more requests completewithout flooding at all, since stable targets are reachabledirectly at their last known IP addresses.

To contrast UIA’s token-limited scheme with flood-ing limited by hop count [6], the upper line in the fig-

ure shows the total number of messages sent for suc-cessful hop count-controlled location requests in whichthe originating device knows via an oracle the exact hopcount required for the search to succeed in one round.As the graph shows, the token-based scheme requires farfewer messages than even this “ideal” hop count-limitedscheme. The inefficiency of the hop count scheme resultsfrom the skewed popularity distribution and redundancyof the friendship graph, as discussed in Section 5.2.

8 Future Work

Although we feel that the current UIA prototype demon-strates a promising approach to naming and connectingpersonal devices, many avenues for future work remain,some of which are highlighted in this section.

8.1 Naming

UIA currently provides no read access control for itsnamespaces, only write access control via group owner-ship. Users may wish to hide certain names, such as linksto business partners, from view of the general public, orlimit visibility of devices at work to business colleagueswhile allowing family members to see devices at home.

The naming layer currently assumes that groups aresmall and change infrequently, so that it is reasonablefor devices always to gossip entire groups and storechange records forever (or until the device is replacedor the user’s account wiped). A traditional DNS-likeremote name resolution protocol might usefully supple-ment UIA’s gossip protocol, allowing devices to resolvenames in large or rarely accessed groups held on other de-vices without replicating the entire group. A UIA devicemight also keep a separate log for each group or series,and garbage collect logs of groups the device does notown and has not accessed recently. A state checkpointmechanism might similarly enable devices to garbagecollect old change records for groups they own.

UIA currently assumes that groups are owned by oneperson or a few people managing the group by consensus:any group owner can modify the group without restric-tion. Users may wish to configure groups so that changesrequire approval from multiple distinct owners, or tomake some owners more “trusted” than others. Treating aPC locked up in a data center as more trustworthy than alaptop or cell phone could eliminate the risk of ownershipdisputes if the mobile device is stolen, for example. Theuser would have to think ahead and perform more man-ual configuration, however, and the consequences mightbe worse if the trusted PC is compromised.

As an alternative to the digital signature algorithm withwhich UIA normally signs namespace change records,we are experimenting with a security framework based onproof-carrying authentication [1]. In this framework, in-stead of a signature, a change record contains a structured

proof that the record’s meaning (e.g., “resolve namex toEID y”) has been endorsed by the group owner. Proof-carrying authentication enables new types of proofs tobe created and deployed without changing the verifier’scode. We have used this mechanism for example to createa UIA group whose records are certified by MIT’s centralX.509 certification authority (CA), so thatalice.mitsecurely maps to the person the MIT CA has endorsed asalice@mit.edu even though UIA contains no explicitcode to check X.509 certificates.

8.2 Routing

The UIA routing layer currently uses forwarding for NATtraversal, which is a general but inefficient solution. As anoptimization, we plan to incorporate hole punching [18],a technique that can build direct peer-to-peer connectionsacross many types of NAT without forwarding. Since thisand other NAT traversal techniques [8,48] only work withcertain NATs, however, UIA will still need forwarding asa fallback to provide robust connectivity.

The routing layer currently uses TCP for all UIA con-nectivity, including for tunneling the UDP datagrams oflegacy applications, limiting the prototype’s effectivenessfor handling real-time data such as streaming media. Weintend to introduce a UDP-based UIA connectivity proto-col to provide more effective best-effort delivery.

The routing layer’s search algorithm could use addi-tional hints from the naming layer to improve its per-formance. To locatelaptop.Charlie.Bob.Alice,for example, it might first locate some device belongingtoBob and ask that device to locatelaptop.Charlie.

8.3 Legacy Application Support

UIA’s legacy application interface currently cannot pro-vide each user of a multi-user machine with a fully sep-arate TCP/UDP port space for its own EID, becausethe kernel’s protocol stack offers no way to ensure thatonly a particular user’s applications can bind a socket tothe device-local IP address representing that user’s EID.Thus, without enhancing the kernel’s transport protocols,only UIA-aware applications can make full use of per-sonal EIDs. Fixing this issue requires changes to kernel-level code and is thus less portable.

9 Related Work

UIA builds on a large body of related work in the areas ofnaming systems, location-independent identifiers, gossipand optimistic replication protocols, and social networks.

UIA’s personal naming model is inspired in part bySDSI/SPKI [14, 42]. Like SDSI, UIA allows users todefine locally-scoped personal names bound to crypto-graphic targets and groups to form decentralized, com-posable namespaces. While SDSI associates public keyswith users (principals) and expects users to know about

and manage their own public keys, however, UIA simpli-fies key management by making each device responsiblefor creating and managing its own device-specific key in-visibly to the user. UIA devices formuser identities outof cooperating groups of personal devices, which the userbuilds through simple device introduction and merge.

Existing Internet protocols can provide some of UIA’sconnectivity features, but they require configuration ef-fort and technical expertise that deters even sophisticatedusers. Dynamic DNS [49] can name devices with dy-namic IP addresses, but requires configuration on both thename server and the named device, and devices still be-come inaccessible when behind NAT. DNS Security [4]cryptographically authenticates DNS names, but its ad-ministration cost has hindered deployment even by theInternet’s root naming authorities, let alone by ordinaryusers. Mobile IP [37] gives a mobile device the illusion ofa fixed IP address, but requires setting up a dedicated for-warding server at a static, public IP address. Virtual Pri-vate Networks (VPNs) [22] provide secure remote accessto corporate networks, but their infrastructure and admin-istration requirements make them unsuitable for deploy-ment by average consumers for their personal networks.

Uniform Communication Identifiers [15] provide acommon identifier for phone, E-mail, and other forms ofcommunication, along with a central address book share-able among communication devices. HINTS [30] usesname-history trails to map obsolete user names to currentones. These systems still rely on globally unique nameswith centralized registration and management, however.

Bonjour [2] allows devices to choose their own nameson local-area networks, but these names are insecure andephemeral: any device can claim any name, and its namebecomes invalid as soon as it moves to a different net-work. UIA uses Bonjour libraries to discover new deviceson the local network, but UIA names persist and remainbound to the original target device despite later migration.

UIA builds on host identity ideas developed inSFS [32], HIP [34], JXTA [23], andi3 [45], introduc-ing cryptographic EIDs that securely identify not just ahost but a particularuseron that host. Different users ofa shared UIA host can run independent personal networkservices without conflicting or requiring host-wide con-figuration, and network services can leverage UIA namesand EIDs to authenticate clients at user granularity.

Distributed hash tables (DHTs) [5,43,44] provide scal-able lookup of arbitrary flat identifiers in large distributedaddress spaces, but tolerate only limited asymmetry ornon-transitivity in the underlying network [20]. UIA’srouter in contrast handles asymmetries such as thosecaused by NATs, but does not attempt to resolvearbi-trary identifiers reliably: UIA instead focuses on reliablerouting to devices nearby in the user’s social network, forwhich scoped flooding [6] is more suitable.

DHT-based naming systems such as DDNS [9],i3 [45], and CoDoNS [40] provide new mechanisms forresolving global names. TRIAD [7] provides contentdelivery and NAT traversal by routing on global DNSnames. In place of global names, UIA focuses on globalconnectivity viapersonalnames, which users can choosewithout the restriction of global uniqueness. In addition,UIA’s optimistic replication of naming state keeps theuser’s namespace available on his devices even while dis-connected from the Internet and its global name services.

Ficus [24, 26], Coda [28], and Ivy [35] developoptimistic replication algorithms for file systems, andBayou [47] does so for databases. Rumor [25] and P-Grid [11] explore optimistic data replication on mobiledevices, Roma [46] uses one mobile device to offer cen-tral management of data on other devices, and Foot-loose [36] uses mobile devices the user carries to prop-agate updates among other devices. UIA builds on allof this work to address distributed naming and ad hocgroup management, confronting the additional challengeof maintaining consistency when not only thedata con-tentbut theset of participantsmay change independentlyon different devices.

UIA is a continuation of work begun with UnmanagedInternet Protocol [16, 17]. UIA extends the earlier workwith its personal naming system, and by leveraging theuser’s social network for routing purposes as in sybil-resistant DHTs [10] and social data sharing systems suchas Turtle [38], SPROUT [31], F2F [29], and Tribler [39].

10 Conclusion

This paper proposes the Unmanaged Internet Architec-ture for introducing, naming, and globally connectingmobile devices. UIA gives users persistent personalnames for conveniently finding and expressing who theywant to talk to, what devices they wish to access, and whocan access their own devices.

Each device starts with a generic name for itself, suchaslaptop, and a cryptographic end-system identifier toprovide authentic and private communication. A user canmerge devices to form personal groups, which cooperateto maintain a distributed namespace by gossiping logs ofthe user’s changes. A user’s group can name both theuser’s devices and other users’ groups; users can formlinks securely either by physical device introduction orvia other trusted channels. Since UIA names are local andpersonal, users need not register with central authoritiesto obtain scarce globally unique names.

UIA uses ad hoc routing through social neighbors’ de-vices to cope with a spectrum of connectivity environ-ments. Scoped flooding ensures robustness when groupsof devices form isolated islands of connectivity, and a so-cial overlay enables devices to find a target’s current IPaddress efficiently when they have Internet connectivity.

Acknowledgments

This research is sponsored by the T-Party Project, a jointresearch program between MIT and Quanta ComputerInc., Taiwan, and by the National Science Foundation un-der Cooperative Agreement ANI-0225660 (Project IRIS).We would like to thank Martin Abadi, Tom Rodeheffer,Nokia Research Center Cambridge, and the USENIX re-viewers for support and feedback on early paper drafts.

References

[1] Andrew W. Appel and Edward W. Felten. Proof-carrying authen-tication. In6th ACM CCS, November 1999.

[2] Apple Computer, Inc. Bonjour.http://developer.apple.com/networking/bonjour/.

[3] Apple Computer, Inc. FileVault.http://www.apple.com/macosx/features/filevault/.

[4] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNSSecurity Introduction and Requirements, March 2005. RFC 4033.

[5] Hari Balakrishnan et al. Looking up data in P2P systems.Com-munications of the ACM, February 2003.

[6] Yatin Chawathe et al. Making Gnutella-like P2P systems scalable.In ACM SIGCOMM, pages 407–418, August 2003.

[7] David R. Cheriton and Mark Gritter. TRIAD: A new next-generation Internet architecture, July 2000.

[8] Stuart Cheshire, Marc Krochmal, and Kiren Sekar. NAT port map-ping protocol, June 2005. Internet-Draft (Work in Progress).

[9] R. Cox, A. Muthitacharoen, and R. Morris. Serving DNS usingChord. In1st IPTPS, March 2002.

[10] G. Danezis, C. Lesniewski-Laas, F. Kaashoek, and R. Anderson.Sybil-resistant DHT routing. InESORICS, 2005.

[11] A. Datta, M. Hauswirth, and K. Aberer. Updates in highlyunreli-able, replicated peer-to-peer systems. In23rd ICDCS, 2003.

[12] Alan Demers et al. Epidemic algorithms for replicated databasemaintenance. In6th PODC, pages 1–12, New York, NY, 1987.

[13] Steve Dohrmann and Carl Ellison. Public-key support for collabo-rative groups. In1st Annual PKI Research Workshop, April 2002.

[14] C. Ellison et al. SPKI Certificate Theory, 1999. RFC 2693.[15] European Telecommunications Standards Institute. User identifi-

cation solutions in converging networks, April 2001.[16] Bryan Ford. Scalable Internet routing on topology-independent

node identities. Technical Report 926, MIT LCS, October 2003.[17] Bryan Ford. Unmanaged Internet protocol: Taming the edge net-

work management crisis. InHotNets-II, 2003.[18] Bryan Ford. Peer-to-peer communication across network address

translators. InUSENIX, Anaheim, CA, April 2005.[19] Bryan Ford et al. User-Relative Names for Globally Connected

Personal Devices. In5th IPTPS, February 2006.[20] Michael J. Freedman et al. Non-transitive connectivity and DHTs.

In USENIX WORLDS 2005, December 2005.[21] Cyril Gavoille and Marc Gengler. Space-efficiency for routing

schemes of stretch factor three.JPDC, 61(5):679–687, 2001.[22] B. Gleeson et al. A Framework for IP Based Virtual Private Net-

works, February 2000. RFC 2764.[23] Li Gong. JXTA: A network programming environment.IEEE

Internet Computing, 5(3):88–95, May 2001.[24] R. G. Guy, G. J. Popek, and T. W. Page, Jr. Consistency algorithms

for optimisic replication. InFirst International Conference onNetwork Protocols, 1993.

[25] Richard Guy et al. Rumor: Mobile data access through optimisticpeer-to-peer replication. InER Workshops, pages 254–265, 1998.

[26] Richard G. Guy et al. Implementation of the Ficus replicated filesystem. InUSENIX Summer Conference, pages 63–71, June 1990.

[27] M. Holdrege and P. Srisuresh. Protocol complications with the IPnetwork address translator, January 2001. RFC 3027.

[28] James J. Kistler and M. Satyanarayanan. Disconnected operationin the Coda file system. In13th SOSP, pages 213–225, 1991.

[29] Jinyang Li and Frank Dabek. F2F: Reliable storage in open net-works. In5th IPTPS, Santa Barbara, CA, February 2006.

[30] Petros Maniatis and Mary Baker. A historic name-trail service. In5th WMCSA, October 2003.

[31] Sergio Marti, Prasanna Ganesan, and Hector Garcia-Molina.SPROUT: P2P routing with social networks. InP2P&DB, 2004.

[32] D. Mazieres, M. Kaminsky, M. F. Kaashoek, and E. Witchel. Sep-arating key management from file system security. InSOSP, 1999.

[33] P. Mockapetris. Domain names: concepts and facilities, Novem-ber 1987. RFC 1034.

[34] R. Moskowitz and P. Nikander. Host identity protocol architec-ture, April 2003. Internet-Draft (Work in Progress).

[35] A. Muthitacharoen, R. Morris, T. Gil, and B. Chen. Ivy: Aread/write peer-to-peer file system. In5th OSDI, 2002.

[36] J.M. Paluska et al. Footloose: A case for physical eventual con-sistency and selective conflict resolution. In5th WMCSA, 2003.

[37] C. Perkins, Editor. IP mobility support for IPv4, August 2002.RFC 3344.

[38] B. Popescu, B. Crispo, and A. Tanenbaum. Safe and private datasharing with Turtle. In12th Workshop on Security Protocols,2004.

[39] J.A. Pouwelse et al. Tribler: A social-based peer-to-peer system.In 5th IPTPS, February 2006.

[40] Venugopalan Ramasubramanian and Emin Gun Sirer. The designand implementation of a next generation name service for theIn-ternet. InACM SIGCOMM, August 2004.

[41] Y. Rekhter et al. Address allocation for private internets, February1996. RFC 1918.

[42] R.L. Rivest and B. Lampson. SDSI: A simple distributed securityinfrastructure, April 1996. http://theory.lcs.mit.edu/˜cis/sdsi.html.

[43] A. Rowstron and P. Druschel. Pastry: Scalable, distributed ob-ject location and routing for large-scale peer-to-peer systems. InMiddleware, 2001.

[44] Ion Stoica et al. Chord: A scalable peer-to-peer lookupservice forInternet applications. InSIGCOMM, 2001.

[45] Ion Stoica et al. Internet indirection infrastructure. In SIGCOMM,August 2002.

[46] E. Swierk, E. Kıcıman, V. Laviano, and M. Baker. The Romapersonal metadata service. In3rd WMCSA, December 2000.

[47] Douglas B. Terry et al. Managing update conflicts in Bayou, aweakly connected replicated storage system. In15th SOSP, 1995.

[48] UPnP Forum. Internet gateway device (IGD) standardized devicecontrol protocol, November 2001. http://www.upnp.org/.

[49] P. Vixie, Editor, S. Thomson, Y. Rekhter, and J. Bound. Dynamicupdates in the domain name system, April 1997. RFC 2136.