GNuggies: A Proposal for Hosting Resilient Stateless Services Using Untrusted Nodes Harshit Agarwal

Infrastructure as a Service (IaaS) Cloud provider dynamically manages the allocation of machine resources. AWS Lambda, Google Cloud Functions, Azure Functions. Cheaper, Easier, Better.

Dealing with increasing censorship Net neutrality repealed. AWS refuses to host WikiLeaks. Authoritarian regimes with limited freedom of speech and information. Other applications with social benefits not allowed on popular hosting platforms (like PirateBay).

GNuggies: IaaS Using Volunteer Machines Machines volunteered by people. Untrusted machines. Architecture design to increase security and resilience. No liability to volunteers, services tough to take down through legal or any other means. Incentives for contributing. Compatibility with existing protocols.

Related Work BOINC, SETI@Home IPFS BitTorrent Vectordash

Attack Model Malicious individuals Malicious institutions Malicious responses Reading private data Malicious institutions

Attack Model: Malicious Institutions Adding a large number of malicious machines to GNuggies. Directives for ISPs. DDos attacks.

Architecture: Preliminaries Stateless and deterministic services. Malicious machines once detected, will be removed from GNuggies immediately. All machines uniquely identifiable and identity cannot be spoofed.

Architecture and Design

Architecture and Design: Client

Architecture and Design: Volunteers Machines that are added to the GNuggies network by the public. Maintains connection to other volunteer machines and core GNuggies services. PCs, laptops, etc.

Architecture and Design: Services Stateless and deterministic. Hosted in Docker containers, Docker image to be replicated on volunteer machines. Infrastructure details abstracted from service creator.

Architecture and Design: Service Clusters Clusters to host a service. Leader election and load balancing. 3 service cluster replicas per service, for response verification. Membership keeper keeps clusters balanced.

Architecture and Design: Node Clusters

Trust∝Age

Architecture and Design: Node Clusters Nodes split into 3 clusters, by age. Oldest 1/3rd nodes in trusted cluster. Each node cluster holds one service cluster replica per service. Nodes unaware of their age and cluster.

Architecture and Design: Membership Manager

Architecture and Design: Membership Manager Acts as an introducer. Keeps track of age and task assignment. Allocates tasks and services to volunteers. In charge of Fairness in task allocation.

Architecture and Design: Task Allocation Need fairness in allocation of services to volunteers. Using Max-Min Fairness. Services that receive more requests, will get more resources. Allocations re-computed every 24 hours, nodes change services often.

Architecture and Design: DNS

Architecture and Design: DNS For every service, IP of host constantly changing. Need central Name Service to track services and hosts, which all services could point ISPs to.

Architecture and Design: Proxy

Architecture and Design: Verification

Architecture and Design: Verification 3 responses per request, look for consensus. Inform Membership Keeper and remove nodes detected as malicious.

Architecture: Bringing it Together Proxy Client GNuggies DNS Trusted Node Probation Node 1 Probation Node 2 r2 r1 r3 Proxy r1, r2 &r3 r1 Verification Service Client Verified Correct response

Verification Look for consensus among the three responses. In case of no consensus, use oldest machine’s response. Any machine flagged as malicious is removed from GNuggies immediately. Verification run for every single incoming request.

Formal Analysis

Terminology Trustworthy machine: A machine that is known to currently not be malicious. Fully trustworthy machine: A trustworthy machine that we know will not turn malicious at any point in the future. Malicious response: A response sent by a malicious machine, which is not the same as the expected response from the hosted service.

Time Spent by Malicious Machines on GNuggies Assuming all trustworthy machines, any machine that turns malicious, will be detected and removed from the platform immediately. In this scenario, number of malicious machines will always be close to 0. Malicious machines removed from GNuggies right after their first malicious response is detected.

Reliability If the oldest 2/3 machines are fully trustworthy, and there are no changes on the the size of the platform, it is impossible for any service to be disrupted, or for any client to receive a malicious response. Malicious machines will only be in Probation Cluster 2, and will get detected and removed from GNuggies immediately, so no service disruptions will be observed.

Resilience to Malicious Institutions Assuming all n machines on GNuggies are fully trustworthy, an outside agency will have to submit more than n/2 malicious machines as volunteer machines on the platform, in order to disrupt services or to fool the verification service. More than n/2 machines needed to make fewer than the oldest 2/3rd machines fully trustworthy.

Minimum Requirements to Host Services To host m services on GNuggies, at least 6m volunteer machines are needed (assuming they are all trustworthy). At least one leader and one other machine needed, per service cluster. And we have 3 service clusters per service.

Incentives

Goals for Incentives Users should want to contribute compute. Users should not want to behave maliciously.

Payoff∝Age

Payoff per Request Assuming that service creator is charged 1 unit of some currency for every request served. If there are n machines on the platform, age goes from 1 to n, 1 being the oldest. 3 machines service a request, in order of age: n1, n2, and n3

Average Payoff in Each Cluster

Incentives Incentive to join GNuggies. Incentive to stay on GNuggies. Incentive to not turn malicious.

Questions?

Thank you!