The Story of Chronoshare, Or How NDN Brought Distributed Secure File Sharing Back
Total Page：16
File Type：pdf, Size：1020Kb
c 2015 IEEE. This is author’s version of this work. It is posted here by permission of IEEE for you personal use. Not for redistribution. The definitive version was published in the proceedings of IEEE MASS 2015 Workshop on Content-Centric Networks 2015. The Story of ChronoShare, or How NDN Brought Distributed Secure File Sharing Back Alexander Afanasyev, Zhenkai Zhu, Yingdi Yu, Lijing Wangy, and Lixia Zhang University of California, Los Angeles yTsinghua University, China fafanasev, zhenkai, yingdi, [email protected] [email protected] Abstract—Information sharing among a group of friends or from multiple peers in parallel. However instead of simply colleagues in real life is usually a distributed process: we tell requesting the desired data, these P2P applications still have to each other interesting or important news without any mandatory consider selection of specific peers and setting up connections assistance or approval from a third party. Surprisingly, this is not what happens when sharing files among a group of friends between peers since they are implemented as overlays on top over the Internet. While the goal of file sharing is to disseminate of TCP/IP’s point-to-point communication channels, which files among multiple parties, due to the constraints imposed by may take penalties of inefficient file distribution paths and IP’s point-to-point communication model, most of today’s file redundant data transmissions over the same links. sharing applications, such as Dropbox, Google Drive, etc., resort Named Data Networking (NDN) [3], [4], [5] proposed a new to a centralized design paradigm: a user first uploads files to the server (cloud), and the server (cloud) re-distributes these files to Internet architecture design. NDN incorporates basic principles other users, resulting in unnecessary tussles and inefficient data that have made the IP protocol suite widely adopted and distribution paths. To bring the truly distributed file sharing globally scaled, including the hourglass protocol architecture back into the cyberspace, this paper presents ChronoShare, a model and end-to-end principle. At the same time, NDN distributed file sharing application built on top of the Named completely changes the narrow waist layer to make it better Data Networking (NDN) architecture. By walking through Chro- noShare design details, we show how file sharing, as well as many suited for the emerging communication patterns, focusing on other similar applications, can be effectively implemented over data instead of data containers (hosts). Each data packet in NDN in a truly distributed and secure manner. NDN is named, cryptographically secured, and delivered to consumer when, and only when, the consumer requests it I. PROLOGUE with an Interest packet. Moreover, since each piece of the In the real world, information sharing among a group of data is named and secured, it can be cached anywhere in the friends or colleagues is usually done in a distributed fashion: network to satisfy future requests; and as the routers maintain we discover something interesting and tell it to our friends; our per-request states, Interests for the same data piece can be friends tell their friends, and so on. However, when a group of aggregated and the returning data packet are multicast to all friends share files using today’s popular applications, such as requesting consumers. DropBox, Box, Google Drive, etc., the sharing process does These and a number of other features from the NDN not follow this natural information distribution pattern. Instead, architecture enabled us to design and implement Chrono- people have to first upload the files to the server (cloud), Share, a completely distributed file sharing application. Chro- which then re-distributes the uploaded files to the designated noShare design is based on a new communication primitive, recipients. In the real world, this would be almost equivalent ChronoSync [6], which is briefly introduced in Section II. to living in a dystopian society where a designated officer Being completely distributed, ChronoShare is agnostic to the keeps records on who is communicating with whom and relays network infrastructure support and is mobile-friendly: users information from the originator to the recipients. can seamlessly share files among their devices, regardless of Why cannot we just replicate the real world information whether these devices are stationary and connected to the distribution process in the cyberspace? We believe that the Internet, or constantly moving and have only intermittent or reasons behind this phenomenon are the shortcomings of ad hoc connectivity. ChronoShare uses NDN’s data-centric today’s networking technology: IP was designed to solve the security to keep the provenance of each file and enable access problem of supporting a point-to-point conversation between control to the data. two entities. However, the success of the Internet has resulted The rest of the paper tells the story of ChronoShare through in IP being used to serve completely different communication a description of its design decisions and implementation patterns, such as social networking, content distribution, in- details, exemplifying how the right architecture can enable formation sharing, etc., where users are mostly interested in “good old” ways of efficient and truly distributed information obtaining desired data rather than reaching a specific node. sharing among friends. Our freely available prototype imple- One can even observe an ongoing trend toward reducing de- mentation [7] showed promising results, even though it is still pendency on centralized servers. For example, in popular peer- an open-ended story at the time of this writing, with a number to-peer file sharing applications such as BitTorrent [1], [2], of research questions yet to be fully answered, which we will one can request desired content from any peer and download elaborate as we walk through the design of ChronoShare. of the knowledge about the dataset, leaving the decision of /Bob what to do after new items are discovered to the application’s 11 /Alice/2 discretion: fetch all missing data items, fetch some of the /Dave /Alice/1 19 /Alice /Alice/3 items, or fetch at a later time when better connectivity becomes /Alice/5 available. 5 /Alice/4 shared dataset III. CHRONOSHARE DESIGN A. Design Decisions Fig. 1: Maintaining knowledge of a shared dataset There are many ways to implement file sharing in NDN, with varying level of design complexity and communication efficiency. A straightforward way is to directly synchronize II. A FEW WORDS ABOUT CHRONOSYNC the file set of the shared folder [8], in a way similar to many As a new group communication primitive in NDN, Chro- conventional synchronization applications such as rsync [9]. noSync [6] enables dataset synchronization among a group However, this may not be the best design choice, especially of participants in a completely distributed way. This primi- for file sharing among devices with varying connectivity. In tive is the most efficient when (1) the synchronized dataset a typical scenario, when one user modifies multiple files in consists of a number of sub-datasets, each produced by an a shared folder, it may not be desirable to synchronize all individual participant in the sharing group, and (2) each piece the modified files with all the group members right away—a of data is named sequentially in the participant’s namespace member may be connected via cellular network, it has no rush (Figure 1). This assumption of sequentially numbered datasets to get all the updated files, or may only need one specific file significantly simplifies the task of maintaining the up-to-date to edit right away. knowledge about the dataset, since each sub-dataset can be ChronoShare chose a different approach, which is to treat completely represented by the participant’s name prefix plus individual user operations on files as streams of “actions,” the latest sequence number under that name. For example where each action specifies which file has been modified in Figure 1, a complete knowledge about what dataset was and what changes has been made (new file, updated content, produced by Alice, which consists of five items /Alice/1, changed file system permissions, or removing a file).2 By ..., /Alice/5, can be compactly represented as a pair of name applying actions from all participants in a deterministic order, prefix /Alice plus the sequence number 5. in combination with the conflict resolution process described ChronoSync encodes the knowledge about the whole dataset (see Section III-D2), each ChronoShare user can build the into a compact crypto digest form (e.g., using SHA256), which consistent up-to-date view of the shared folder and, when we call the state digest. This digest is carried in a special desired, fetch all missing files. The main advantage of this “sync” Interest which reaches all participants in a group. action-based approach is that in typical shared folder usage Semantically, a sync Interest is a request for any dataset state scenarios, no matter how many changes a user might have changes that happen since the state represented by the digest. made to the shared folder, there is a straightforward way to To reach all the participants in a group, the sync Interests can propagate changes to other participants: others just need to be multicasted to all participants directly in small networks or fetch all the actions from the user and apply these actions via multicast overlays in large networks.1 When an incoming to their folder. Actions by each user form a “stream” of data sync Interest carries a digest that is the same as the locally items, and the streams from all users of a shared folder form a computed one, it indicates the local dataset is identical to the dataset that can be synchronized using ChronoSync primitive. dataset of the sync Interest’s sender.