Davis Social Links or: How I Learned To Stop Worrying And Love The Net Matt Spear and Xiaoming Lu and S. Felix Wu School of Computer Science UCDavis Davis, CA 95616 Email:
[email protected],
[email protected],
[email protected]
Abstract—When the Internet was conceived, its fundamental operation was envisioned to be point-to-point communication allowing anybody to talk directly to anybody. With its increasing success, the Internet is under increasing attack, e.g. spams, Denial of Service (DoS), Domain Name Server (DNS) hijacking, etcetera. This paper introduces a clean-slate approach to redesigning the Internet, entitled Davis Social Links (DSL). Instead of directly connecting the source and sink, DSL routes the message (or request to communicate) through social contacts each of which can decide to drop the message/request based upon the previous hops prior actions. In this way, trust is an integral part of networking. DSL separates identity from location, and promotes searching to a fundamental operation in the network. DSL also provides end-users control over who can reach them, and who their messages reaches. Finally, DSL provides components in the operating system to aid the user in identifying applications which are misbehaving. These features help make the entire network more resilient to attacks, and provides mechanisms that current and future applications can utilize to stop worrying and love the Net.
I. I NTRODUCTION Since its inception in the 1970’s the Internet has grown from a handful of trusted machines to a large conglomeration of machines, but the basic architecture has remained the same. From its inception the Internet relied on an assumption of trusted autonomous nodes, but this has been exploited in numerous attacks, e.g. Domain Name Server (DNS) spoofing, spam, and Denial of Service (DoS). This assumption allows actions without consequences. For example, having an unwanted interaction (e.g. providing a spoofed website, or email/blog/link spam) does not directly affect one’s standing. For simplicity we classify any unwanted interaction as spam, and any wanted interaction ham. Finally, the Internet assumes that everybody should be able to communicate with everybody, but this has been exploited by DoS. In response to these problems, we propose Davis Social Links (DSL), which leverages social connectivity and changes the fundamental network operations. Many applications provide some mechanism for searching, from DNS to Peer-to-Peer (P2P) to search engines to sales sites. As such DSL provides this as a fundamental network operation. In DSL when a user wishes to find nodes possessing some data, or providing some services they query the network. By providing this mechanism applications can concentrate on sorting and filtering the returned set rather than reinventing a network search mechanism. Furthermore, in DSL these “keywords” are not assumed to identify a single node, in contrast to DNS, a set of keywords could identify a set of
any size of matching nodes (which aids in preventing DNS hijacking attacks). In the current Internet, an end-user has no control over who can reach them; if they open a port then anybody can reach them, or they can setup their machine so that nobody can reach them. Neither of these options are desirable, and the former has been exploited for DoS attacks. DSL changes the fundamental connectivity assumption—it makes connections to default to off, i.e. direct communication is possible only if both end points agree to allow it. Instead of requiring machines which want to allow everybody to connect to them, DSL uses social connectivity. In DSL edges have social meanings, i.e. there is an Out Of Band (OOB) context. This is akin to what has been seen in Facebook and other Online Social Network (OSN). However, Facebook and many of the other sites allow direct communication between any pair of nodes. In DSL a trusted path from the source to the sink must be found consisting solely of friend links. Restricting the communication as such aids in preventing unwanted messages, and aids in identifying nodes which generate unwanted interactions. In the Internet every node on the path between endpoints can read a user’s message. The obvious solution to this is to encrypt the message before sending. Furthermore, even if the message is encrypted, a node may wish to restrict the flow or to exclude certain nodes from the chosen path. DSL provides both options, encrypting all messages using an Identity Based Encryption (IBE), and utilizing policy to control which nodes the message can pass through so that flow identification cannot be attempted. Actions have no real consequences in the current Internet. A node which sends an unwanted message is equally likely to succeed in sending another message as a node which sent wanted messages. This has led to the proliferation of spam, and unwanted interactions. DSL places trust between each pair of connected nodes, and forwards messages proportional to the trust of the edge. This excises nodes which generate unwanted messages, and aids in finding a trusted route avoiding malicious nodes. DSL changes the fundamental operations of the network, adding searching, simplified caching, trust, and control over reachability to stop applications from having to reinvent these important services. With trust as a integral component, DSL is able to provide security, reliability, consequential actions, and cutting off nodes which misbehave. Furthermore, DSL requires a minimal number of changes in the physical layer
in order to accomplish the above. Importantly, DSL does not require that each hop in the physical layer be authenticated, i.e. the physical layer does not need to have an Public Key Infrastructure (PKI). II. R ELATED W ORK There has been a lot of discussion on clean-slate designs for a Next-Generation Internet, c.f. [1], [2]. A general consensus has been reached that a number of items need to be included. Most notably: 1) identity and location should be separated, 2) trust has to be an integral part of the network, 3) transparency should be maintained when trusted nodes communicate, and 4) control units should be placed at the edges of trust domains. DSL includes all these features, and notes that for trust to exist there must be an OOB relationship (e.g. business partners, or social acquaintances). In response to a proliferation of network attacks, e.g. DoS, there have been a number of approaches to provide end-user authentication, and capabilities in the network. In [3], nodes can communicate only when both ends agree. Each router maintains a “Connect” table detailing what pairs of nodes are allowed to connect. A difficulty arises in that many end-hosts would like to allow anybody who is “trusted” to be able to connect, but would like to exclude those “untrusted” entities. How to accomplish this is not straightforward. [4] extended the concept to handling arbitrary capabilities, e.g. number of bytes transmitted, but in so doing requires the router be more complex (e.g. they need to be able to compute MACs). [5] introduced a scheme that ensured that an attacker could not spoof any address that was not within the IP range of their router. In all of theses schemes the authors assume a strong attacker; the attackers can arbitrarily control routers in the backbone. In this paper we make the assumption that the attacker cannot control routers, and therefore authentication and connect capabilities only need be at the ingress points of the backbone. We note that if the assumption of a stronger attacker is required DSL can operate with any of these schemes. As noted before, trust must be an integral component of the network. There are essentially two classes of trust systems: credit based, and reputation. In a credit based system, c.f. [6], [7], each node is given some initial credits, and each message consumes some credits. In [6], if the message was wanted (ham), then the credit is returned, otherwise it is lost. In contrast, reputation systems, c.f. [8], [9], maintain the trustworthiness of a node. The trustworthiness is generally defined to be the probability that the next interaction will be wanted. Reputation can either be tracked globally (each node has a trust value for every other node), or locally (each node has only a trust value for each neighbor). It has been shown, [10], that global reputation systems are exploitable. In contrast, it has been shown, [11], that in many P2P systems the number of repeat interactions is small. Therefore, neither a purely global or local system will work. In [12], we introduced a simple scheme where nodes are connected in the network if and only if they have a social connection, nodes track the trust of their neighbors, and interaction outcomes are propagated from sink to source. This work is utilized in DSL.
The final component of network security is the end-hosts. There has been a lot work in securing applications from tainted data, c.f. [13], [14]. These extend the hardware (or a virtual machine) to make all data from the network tainted, and if this data reaches a control branch then an exception is raised. This has been shown to help in protecting against buffer overflow attacks and their ilk. DSL can make use of these, but also introduces an extra component (AppTrust) that applications can only generate a finite number of unwanted messages before they are blocked. Once an application is blocked the user must explicitly unblock it. III. A RCHITECTURE In this section we first introduce a few key concepts in DSL (identity, policy, communication, and excommunication), and then describe DSL’s network stack in detail. DSL has end-users authenticate with their Internet Service Provider (ISP), and assumes attackers cannot compromise routers in the backbone. As authentication only occurs between the end-user and the ISP, there does not need to be a PKI. A. Identity In stark contrast to the current Internet, identity in DSL is not fixed, a node can change their identity at any time. In DSL identity is not tied to location. DSL has three separate identities: 1) a set of keywords, 2) a DSL Networker (DSLNet) identifier, and 3) a physical identifier. Any node which is not an immediate friend is not identified via a global identity, instead the source searches for a set of nodes satisfying its requirements using keywords. A keyword describes either data to aid in identifying the node, or the services a node provides. For example, a keyword set (k) could be {Naruto, California, video download}. The keywords are part of a shared global lattice, which aids in removing ambiguity and in aggregation, this has been shown to be very effective in sensor networks [15]. Many words are ambiguous within differing communities, e.g. gnu could be an operating system, an animal, or a previous South African government, but given context the distinctions are clear. In DSL context is given explicitly by identifying the path in the lattice to the imaginary root. An application can add keywords and specify themselves as a callback. By doing so whenever a remote node attempts to make contact their request is forwarded to the appropriate application. When a source wishes to find a remote node it searches for it via a set of keywords. DSL will translate the keywords to a set of DSLNet identifiers. It is up to the source to choose the set of sink identifiers to communicate with, similar to google search. A user’s DSLNet identity is hidden except to immediate friend nodes and those requesting data. This allows a user to have a mobile identity, even over multiple ISPs. ISPs are responsible to map the DSLNet identifier to a physical identifier, which describes the user’s physical location for routing. Note, users must authenticate their DSLNet identifiers with their local ISP to prevent spoofing. B. Policy DSL gives users control over who can reach them, and whom their messages reach. This is accomplished by setting
E. DSL Stack We now detail how the various components of DSL work together, and what functions they provide. DSL is composed of three layers: 1) physical provides simple routing and disallows communication unless both ends agree to allow it, 2) DSLNet provides the routing, forwarding, searching, and connection mechanisms, and 3) DSL Manager (DSLMan) handles the management of the friendships, trust, and keywords. Figure 1 displays the components of DSL. We proceed in a bottomup fashion. App
{
DSLMan
{
{
DSLNet
a policy for each keyword. Policy in DSL is [k, t, d] ⊆ K × T × D, that is it is a set of keywords, a minimal trust, and a maximal distance the path must satisfy in order for communication to proceed. Each node on the path from the source to the sink must satisfy the sink’s policy, or communication will not proceed. Node’s can utilize policy to setup a community where messages are guaranteed (at the network level) to not leave the community, nor can outside nodes inject messages into the community. Furthermore, nodes outside the community cannot become members of the community unless they are friends with a node inside the community (due to the restriction that every node on the path must satisfy the policy). The policy can also be utilized to restrict messages from a source to a set of sinks, e.g. a source can utilize the policy to restrict their query to a geographical region, e.g. searching for taxis in Davis CA. C. Communication
D. Excommunication Finally, to aid in controlling exposure, a sink can excommunicate remote sources to prevent the sources from communicating with the sink. This is separate from the excising that trust provides as trust is a function of the majority, e.g. an advertisement campaign could be appreciated by a large majority of nodes but disliked by a small minority and without a separate mechanism this small minority would be unable to prevent the source from contacting them. This can be accomplished with a secure traceroute.
T r u s t
K e y s
Key F w 2 ID d
R o u t e
C o n n
{
PHY
Communication in DSL proceeds only along social links. Therefore, a node will be forwarding messages for its friends (and friends of its friends, etcetera). DSL provides two scenarios for communication, one being anonymous and one being efficient. In the efficient style the source (s) sends a request to the friend (i) which has the best combination of trust and path length to the sink (t). This request includes the identifiers of s and t (s’s identifier can be hidden using IBE so that it is only revealed to t). i then considers its trust in s to determine if it is worth allowing s’s communication to proceed, and if so forwards the request to the its best friend. This proceeds until either t is reached, or some node decides it is not worth forwarding the message. If all nodes between s and t inclusive agree to allow the interaction to proceed then s and t form a temporary edge—i.e. they inform the physical layer to allow direct communication between them. At any time s or t can decide to terminate the connection, and t can provide an outcome to the interaction. The anonymous protocol proceeds in a similar manner, except, instead of forwarding a request, the actual message is propagated (along with an identifier for the interaction if the source wants the sink to be able to reply). This style of propagation is used in many anonymity systems [16], [17] to provide sender anonymity. If the user does not trust the ISP, they can also generate chaff (i.e. messages that appear real but are fake [17]). Thus, the source’s identity is hidden from the sink, and their actions are hidden from the ISPs.
AppTrust F r i e n d
Fig. 1.
The layers and components of DSL.
1) Physical: DSL does not define the physical layer, which allows it to be deployed over most networks (including the current Internet). DSL assumes the physical backbone is a trusted domain, but the end hosts are not trusted. The physical layer provides basic authentication. Ideally there is a defaultoff policy, but without it DSL still functions, but will not defend certain attacks such as DoS. When a node initially connects to the ISP to receive a physical identity it must provide its DSLNet identifier, and authenticate that it is the owner of this identifier. This implies that ISPs should be responsible for giving out DSLNet identifiers. The mechanism for authentication could be ISP dependent, but the best choice is to utilize public keys. When a node registers an account with an ISP they would generate a public/private key pair and exchange the public keys with the ISP. This ensures that even if the ISP’s authentication server is somehow compromised the user will be unaffected. Once the DSLNet identifier is authenticated the ISP should prevent messages going through the router’s port which have an improper identifier. The default-off policy ensures that only the pairs of nodes which both agreed to allow communication can communicate. Currently, routers possess a forwarding table which determines which router is best to forward a message with a given destination to. This table will still be needed, and the routers can add a second table denoting which pairs of nodes can communicate. Intuitively, the second table seems expensive as one would expect every router in the physical layer to share the table, but, in actuality, only entry-point routers need to only store the table for the nodes connected directly to it. This can be accomplished as long as the routers can trust that the other ISPs will not allow messages to enter that are not validated. 2) DSLNet: As noted above, the DSLNet layer handles the actual communication mechanics. It consists of four key
components. a) Connections: The connection component (Conn) is utilized in setting up friend connections. As noted above, in order for a node to communicate in the network it must have friend nodes. This component can automatically respond to friend requests by querying the friend component of the DSLMan layer. b) Key2ID: The Key2ID component provides an efficient mechanism for translating a set of keywords into a set of DSLNet identifiers. DSL utilizes a Distributed Hash Table (DHT) [18], [19] to accomplish this, each node is an actor in the global DHT. A simple extension is made to the DHT to ensure that the source satisfies the policy of the sink; this is accomplished using a geometric division of the keyword and policy space, but due to space limitations we do not provide the details. If a node desires receiver anonymity it can form an anonymous path to a node which is willing to publish its content. This node would then publish the content for the anonymous node, and would forward all requests along the path to the true sink. c) Forwarding: The forwarding layer (Fwd) is responsible for determining if it is worth the risk associated with forwarding a message from the friend. The forwarding layer interacts with the trust component of the DSLMan layer to determine the likelihood that the interaction will be wanted, and the routing component to determine the next best hop. The forwarding component also ensures that the preEquation (2)vious hop satisfies the policy the sink specified. Forwarding is probabilistic, discussed more in Section IV-B. This is essential, if forwarding was deterministic once a node’s trust value became too low it would be unable to communicate, and therefore unable to recover its reputation in situ. As forwarding is probabilistic a node can recover lost reputation given enough effort, or the node can take advantage of OOB communication to get its neighbors to reset its trust. We note here that even though forwarding is probabilistic a malicious node can only generate a constant number of unwanted messages. d) Routing: The routing component of the DSLNet layer (Route) is responsible for determining the best next hop for a message. The routing layer also interacts with the trust component of the DSLMan layer to determine the trust of the neighbors. The routing layer combines this trust information with distance information, the exact mechanism is described in Section IV-C, to determine which neighbor has the best combination of distance and trust. F. DSLMan The DSLMan layer is responsible for managing the social information. e) Friends: The friend component simply records the DSLNet identifiers of the nodes which should be connected to by default. Applications can interact with this layer to add friends (or temporary friends) as needed. f) Keywords: The keywords component (Keys) manages the keywords, policies associated with each keyword, and which applications have registered as callbacks for each keyword. When keywords are added or removed this component interacts with the Key2ID component of the DSLNet layer to update the DHT.
g) Trust: This component is responsible for tracking the likelihood the next interaction will be desired for each action for each friend. DSL provides a basic set of actions, but applications can add actions as are needed by them (e.g. an auctioning service might add an action to describe a node’s reliability in selling/buying). DSL only tracks trust between connected nodes (friends). After every interaction the sink is able to rate the outcome, that is it can punish (or reward) all intermediary nodes (and the source) for allowing the interaction. This ensures that malicious nodes are suppressed by their neighbors. In an application which uses the pull model, the source requests data from the sink and it would be the source supplying the outcome. 1) AppTrust: The AppTrust layer marks the demarcation between the networking components and the operating system. AppTrust tracks the trust for each application utilizing a global trust system. Users can set a policy so that applications which generate too many unwanted messages or whose trust is too low are blocked. This component provides safety that an application is bounded in the amount of damage it can cause to the user’s reputation. Once an application is blocked the user can manually remove the block or the application. This component should also aid users in identifying when they have become infected with a virus. Importantly, the trust of an application is persistent, i.e. when an application terminates its trust is written to a safe region on the hard drive so that when the application starts back up its trust is not reset. G. Application Any application can sit on top of DSL. Applications can also provide a mechanism for authentication of remote users using some a priori agreed upon mechanism, i.e. a bank can give user a key to mutually authenticate. IV. T RUST In DSL, messages can only traverse social links, and each node keeps track of the trust of its neighbor for every action. In the following we describe the trust structure adopted, how to decide to drop messages, how to efficiently find a route, and what features this design gives. We give an overview of the various components, refer to [12] for a full disatever recussion. A. Structure The structure for the trust in DSL of node v from v’s neighbor u’s perspective with action a as: Tau (v) = hm, n, ci ∈ R[0,1] × R[0,1] × N
(1)
where m represents the fraction of “recent” interactions that were wanted, n represents the fraction that were unwanted, and c is the count of interactions. m and n are updated using an Exponential Moving Average (EMA): mi ← λo + (1 − λ) · mi−1
(2)
with 0 ≤ λ ≤ 1, and n is updated similarly. Utilizing an EMA allows DSL to adapt quickly to dynamic changes in the behavior of nodes. After each interaction (e.g. an email message, an instant messaging conversation, a result set for a given query,
etcetera), the sink can provide an outcome (o) denoting the quality of the result. If the interaction proceeded properly o ← 1, otherwise o ← 0. Note that any 0 ≤ o ≤ 1 can be used when outcomes can have varying degrees of satisfaction, e.g. when a user receives a result set from a server some #Wanted fraction may be unwanted and the user may use o ← #Returned . This outcome is propagated from the sink to the source (and up the source’s network stack to the AppTrust layer). Each node along the path updates the trust value of the previous hop using (2). By propagating the outcome to the source, the source will become cutoff by its neighbors, and the source can utilize its AppTrust layer to identify the application which cause the lowering of its reputation. Note that in a pull model (the source requests data from the sink), the action of the outcome propagation is reversed. By default DSL uses three actions: (1) initialization (init) (when a node is the source of a message), (2) forwarding (f wd) (when a node forwards a message which it is not the source of), and (3) routing (rt) (when forwarding messages to a node, the likelihood it also forwards the message) . B. Probabilistic Dropping In the following we use the term message to denote either the actual message (in the anonymous setting) or the request (in the efficient setting). As paths can become long, and it is unreasonable for a very trusted node to have a low probability of success solely due to path length, DSL allows any message to proceed through u from the previous hop (v) with probability 1 whenever σ(Tau (v)) ≥ τ . σ represents the probability that the upcoming interaction will be positive; !1+ǫ mc + m/λ + 1 a σ(Tu (v)) = (3) 1 τ −ǫ−1 · (m + n) · c + m+n λ where ǫ > 0 is utilized to bound the number of unwanted interactions a node can generate. When σ(Tau (v)) < τ , DSL probabilistically drops the message proportionally to σ. This ensures that malicious nodes rapidly become excised, and that every node can recover lost reputation as they are never completely cutoff. One important consequence of this is that nodes must provide wanted interactions for every action in order to avoid being excised. For example, a spammer cannot recover its reputation simply by forwarding wanted messages from its neighbors, nor can a freeloader recover by sending wanted messages. C. Routing DSL utilizes a simple algorithm which extends any existing routing protocol: N EXT H OP(u, t) = max αδ(v, t) + βσ(min Tau (v)) + γD(v) v∈N (u)
a∈A
(4) where N (u) denotes the neighbor set of node u, δ(v, t) denotes the scaled distance through v to the destination t, A denotes the set of actions, and D(v) denotes the degree of node v.
D. System Properties In [12], we describe and prove the following important features of this system: 1) bounds the damage a single node can cause, 2) adapts rapidly to dynamic changes (in fact it gives recovery/lose of a node’s reputation in a constant number of messages), 3) bounds the ability of a Sybil network to send unwanted messages, 4) is tolerant to colluding and errors in marking the outcomes, and 5) provides incentives for a node to behave properly in each action to avoid being excised . These features help to make DSL applicable in realistic systems. V. E XAMPLES In this section, we give some examples and discussion of some of the important procedures in DSL. A. Initial Friend Connection First we discuss the procedure where two friends can connect and begin to send communication between them. As aforementioned, in order to communicate at the physical layer both end-points must agree to allow the communication. DSL provides a bridge between the social layer and the physical layer to form edges between friends. In Figure 2(a), we show an example network where A wishes to form a connection with B who is in a different ISP (for clarity we name the nodes with capital letters, and number the ISPs). First, note that the routing table is shown for each ISP; this could remain the same as in the current Internet, or it could change drastically as in [20]. Initially, A authenticates its DSLNet identity to 1; this will probably be accomplished by A signing a challenge from 1. B also authenticates its DSLNet identity with 2, and 1/2 record that A/B’s is bound to the port A/B reside on the router (to prevent A/B from being able to spoof other’s DSLNet identity). Next, A contacts 1 informing it to form an edge with B (using B’s DSLNet identity). 1 determines the route to B (through 2), and forwards the request. 2 forwards the request to node B, and it propagates up B’s network stack until it reaches the connect component of the DSLNet layer. The DSLNet connect component queries the DSLMan friends component with A’s DSLNet identity, and if B has A as a friend then B informs 2 that the connection should be allowed, however B may need to pass the request up to the application layer to determine if the connection should be allowed. Assuming B allows the connection, then 2 informs 1 that the connection is allowed, and 1/2 update their connect table to allow the connection. Note that only 1 and 2 need to update their connect table. The final routing and connect tables are shown in Figure 2(a). Now we consider the case where C attempts to forge a connection with A, when A tries to form connection with only B. This can be stopped with the following two methods, depending on the power of ISP: 1) if the ISP can record what connection requests are outstanding, then 2 will identify that C has no connection requests outstanding and will not allow it to continue; 2) otherwise, A can identify that C’s DSLNet identity is not B’s, and it will not allow the edge to form (making connection a three-pass protocol instead of two). In both scenarios, C cannot force an edge to form between itself and A by attempting to reply to connection requests A
Routing 2 B C 2 3 D
A
ISP 1
B A
DSLMan
Connect B 1
A Routing 1 A B 2 2 C
ISP 3
Routing 1 A 3 D
C
Connect D 1
ISP 2
D
DSLMan
M
Connect B 1 C 1 D 1
D
O
DSLMan
A B C
C
B
AppTrust
DSLMan
AppTrust
C
(a) The thick pipes indicate social connection, the solid lines (b) The AppTrust component expanded on nodes A and D using indicate end-host to ISP connection, and the dashed lines indithe network from Figure 2(a). A sends D a message, and D cate physical connections between ISPs. Each ISP maintains a replies with an outcome (wanted or unwanted). The message Routing table (how to route to whom, an example is shown), path is shown in solid, and the outcome path is dashed. and a Connect table (who can communicate with whom), not shown is the DSL stack. Fig. 2.
An example network with social and physical topology.
initiates. In a similar manner, D is unable to force a connection between itself and A. B. Communication We now discuss how communication proceeds in DSL. As previously noted, there are two mechanisms for communicating: anonymous, and efficient. A simple network is used, and shown in Figure 2(a); A is attempting to communicate with D where AB, BC, CD have all been initialized to allow communication between each other. 1) Anonymous: First, in the anonymous medium, A searches for a destination using a set of keywords (e.g. {Naruto, download}). This request is passed to the DSLNet’s Key2ID component, which looks up in the DHT the matching nodes; assume that A chooses D as the destination. A sends a message with data (not a connection request) and passes it to B, who decides if it is worth the risk to forward the message (as described in Section IV-B), records that A is the previous hop for the message by noting the unique message ID, and passes the message to C. C repeats the process and passes it to D. D can decide if it likes the message, and propagates the outcome containing A’s message’s unique ID as described in Section V-C. If requested by A, D can also use the reverse path for replying to the message from A (and then A can provide an outcome and possibly reply, etcetera). 2) Efficient: The efficient protocol proceeds similarly except A crafts a temporary connection request containing its DSLNet identifier and sends a connection request (not data message) to B with D’s DSLNet identifier. B determines if it is worth allowing the interaction, and if so forwards the request to C. C repeats this process and forwards the request to D. D decides if it is willing to form a connection tunnel with A, and if so informs the physical layer of its request (following Section V-A). Now, A and D can communicate
for some number of messages directly, once the interaction ends (A or D terminates the connection by informing the physical layer to remove the entry from the connect table), D can provide an outcome and send it to C as before. Note, A can hide its DSLNet identifier from B and C if it encrypts its identifier using IBE. C. Outcome Propagation Figure 2(b) shows an example communication between app1 on A and appi on D, hiding the physical layer components. When appi receives the message it generates an outcome, and passes it to D’s AppTrust which verifies the message’s ID was seen before. D’s AppTrust passes it to D’s DSLMan, then D’s DSLMan updates TfDwd (C) using Equation (2), and passes the outcome to C’s DSLMan, which updates TfCwd (B). C’s DSLMan passes the outcome to B’s rt DSLMan; B’s DSLMan updates Tinit B (A), and TB (C). B’s DSLMan passes the outcome to A’s DSLMan layer which updates Trt A (B). Finally, A’s DSLMan passes the outcome to A’s AppTrust layer, which updates the trust of app1 . If app1 ’s trust value is too low (or app1 has sent too many unwanted messages) AppTrust will block it to protect the user. VI. I MPLICATIONS In this section, we describe the behavior changes that would need to be made for various classes of users. When appropriate, we describe the economic incentives for making the transition. In all cases, the benefits of anonymity and hiding the data being transported are assumed. A. End Users For end users which mainly send/receive data, they need to take responsibility of their actions, e.g. avoid sending spams and dropping messages as bad behaviors will be punished in
DSL. If they become infected with a virus which generates spam, DSL provides safety mechanisms to bound the amount of reputation that can be lost before the virus’ application will be cutoff. This mechanism will aid the users in identifying that they have become infected and they can remove the offending application. Once the virus is blocked (or removed), the user can recover their lost reputation (with the loss being a minimal amount). End users should also have an easier time providing services to the network. Currently, each application must define their own searching/caching and trust mechanisms, but, in DSL, these are provided as network services. Therefore, the end users should be able to provide data and services with minimal work. As an example, Youtube [21] has enjoyed success largely because they designed a simple searching/publishing mechanism. In DSL the end users can take advantage of the searching component to simply provide the data they wish to share (by adding the description into the Key2ID). 1) Public Machines: A special class of end users is nodes which are accessed by a number of unique individuals. There are really three (not mutually-exclusive) options: 1) require the users login with their DSL identities, 2) restrict the amount of damage each user can do to the machine with stringent AppTrust policies, or 3) require each public machine to be connected to a single exit point to the main network. Requiring the users to login with their DSL identities is by far the best option, but it is not always doable. For example, users may not wish to reveal their identities to the owner of the public machines, or they might forget their identification. By requiring users login with their DSL identities, the owners guarantee that their public machines’ reputation will not be affected by whatever the users do, and anything bad/good the users do will be reflected on their DSL identities. Putting stringent restrictions on the machines utilizing the AppTrust is similar to what is currently done. By limiting the damage any user can do to a machine the owners can be sure that their machines’ reputations will not be adversely lowered. The downside of doing so is that it may not be easy to recover the lost reputation (however small it may be) once the user has left the machine. This means that successive malicious users could cause a common application to be blocked and successive users would be unable to use the application without interacting with the managers. The public machines can be connected in a star network with the central node being the only output to the network. The damage of each machine behind the central node is bounded using AppTrust. The central node tends to have higher trust value if only a few machines behind it are malicious and will still be able to communicate with the outside world. Additionally, the central machine can be configured to reset other public machine’s trust when user logs off.
that as there is a DHT this can be used to aid in distributing content cheaply. 1) Search Engines: Currently, search engines utilize a lot of resources to cache the majority of the web, and provide a mechanism for sorting the results. With DSL there is no longer a need to cache the entirety of the web, as search is fundamentally part of the network. Therefore, these entities have two options: stop caching and simply focus on sorting, or proceed as they currently are. If they wish to stop caching, then they can save the money spent on the storage area networks, and instead concentrate on sorting the results that DSL returns. DSL does not specify a sorting algorithm on returned results, this is left up to the application to handle (as differing application may have very differing desires for relevance). The search engine companies can morph their business model to simply provide a sorting algorithm, and can support themselves as they currently do (via advertising). The other option, is to continue as they currently are. They would request the data, and cache it locally, then users could contact them for the data. There is still a desire for caching as nodes may shut down and be unable to answer a request for a given piece of data. By caching they can provide a search interface to the data they have collected, and can ensure the data is available. DSL provides a few modifications that would be very helpful to search companies. Foremost, DSL has a lattice so there is no ambiguity in searching, e.g. when a user searches for Naruto, the search engine would be aware if the user intended Naruto the anime/manga character or Naruto the location. Secondly, the site can add actions to trust to determine how relevant the result set was; they can then tune their results according to the “satisfactory level” of the users using their service. 2) Social Networking Sites: OSN sites currently, provide a simple centralized mechanism for users to find and interact with their friends. Many of the features of OSN are defined as part of the networking components of DSL. OSN can migrate their services to be more feature rich, providing the operations described in Section VI-C, or they can morph into a P2P architecture. 3) Auction/Sales: Auction and sales sites, can easily take advantage of the trust component that DSL provides. They can add actions to reflect their needs, and allow more accurate tracking of the trust, e.g. eBay may wish to add a buying/selling action to track how trustworthy the node has been inside their system. Furthermore, they can utilize the routing component and find a trusted path, wherein each node is willing to vouch some OOB insurance if the source welshes on the contract, c.f. [22]. As with the other providers, they can provide these services in either a centralized or distributed setting. C. Social Context Service Providers
B. Service Providers We consider how service providers would adapt, and what economic incentives there are to upgrading their systems. First, note that by upgrading their machines they would ensure that they could not be attacked by a DoS attack. Secondly, note
DSL also introduces a new area for service providers; as a node can only communicate if at least one of his friends is on, nodes may wish to share their social context with a service provider, the Social Context Social Provider (SCSP). To utilize the SCSP the friends of node which subscribes to the SCSP
(u) would connect to the SCSP, and u would share its policy for forwarding (at a minimum trust and friend list) with the SCSP. Now, if u was to become unavailable the SCSP would act in u’s place to forward the messages of u’s friends. To fund the cost of forwarding the messages/requests the SCSP could either charge u directly, charge u’s friends directly, or through advertisements. This allows u to ensure that his friends will be able to communicate even in his machines absence. D. Internet Service Providers As the end user and service providers would all want ISP to upgrade, they will put pressure on ISPs to upgrade their hardware or possibly do a software upgrade via a patch. VII. C URRENT S TATUS & F UTURE W ORK We have evaluated the trust component of DSL in [12]. Our evaluation shows that DSL excises spammers and freeloaders at the source, provides little incentive to execute a Sybil attack, with negligible false positive and negatives (less that 0.5%). Furthermore, we proved analytically that DSL bounds the number of unwanted messages a node can send in its lifetime, and that a node can recover/lose its reputation in a constant number of messages. DSL works even in the presence of collusion, spammers which generate both wanted and unwanted messages, and errors in the marking of the outcomes. Finally, DSL is able to maintain a constant number of unwanted messages received per node independent of the number of attackers. To evaluate the effectiveness of DSL architecture, we used Facebook as the physical layer and Friend component of DSLMan, and tested our initial DSL over Facebook using students in our lab [23]. We also developed a SMTP application to reside on top of the DSLMan layer, allowing users to send message through DSL using their normal email clients. We are currently evaluating and building the other components, e.g. efficient DHT keyword searching with policy, building AppTrust into the Linux kernel, and deploying a full version of DSL over OSNs (e.g. Facebook), and the current Internet as an overlay. We are also planning on evaluating DSL over the upcoming GENI [24] project. VIII. C ONCLUSION In this paper, we proposed a clean-slate design for a new Internet architecture, entitled DSL. DSL inserted trust as an integral component in the network and leveraged social connections to aid in building trusted social paths and creating judicious forwarders. DSL added search as a fundamental network operation, and decoupled location and identity. We described how DSL gives end-users control over who can reach them, and who can read their messages. DSL also adds an important component to the operating system layer to track the trust of applications to aid the user in identifying misbehaving applications. These additions should provide current and future applications access to the components they require without having to reinvent the wheel.
R EFERENCES [1] T. Roscoe, “The end of internet architecture,” in HotNets ’06, 2006. [2] D. D. Clark, K. Sollins, J. Wroclawski, and T. Faber, “Addressing reality: an architectural response to real-world demands on the evolving internet,” in FDNA ’03: Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture. New York, NY, USA: ACM, 2003, pp. 247–257. [3] H. Ballani, Y. Chawathe, S. Ratnasamy, T. Roscoe, and S. Shenker, “Off by default!” in Proc. of workshop on Hot Topics in Networks (HotNetsIV), 11 2005. [4] X. Yang, D. Wetherall, and T. Anderson, “A dos-limiting network architecture,” SIGCOMM Comput. Commun. Rev., vol. 35, no. 4, pp. 241–252, 2005. [5] X. Liu, A. Li, X. Yang, and D. Wetherall, “Passport: secure and adoptable source authentication,” in NSDI’08: Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation. Berkeley, CA, USA: USENIX Association, 2008, pp. 365–378. [6] A. Mislove, A. Post, P. Druschel, and K. P. Gummadi, “Ostra: leveraging trust to thwart unwanted communication,” in NSDI’08: Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation. Berkeley, CA, USA: USENIX Association, 2008, pp. 15–30. [7] B. Cohen, “Incentives build robustness in bittorrent,” 2003. [Online]. Available: \url{http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1. 1.14.1911} [8] B. E. Commerce, A. Jsang, and R. Ismail, “The beta reputation system,” in In Proceedings of the 15th Bled Electronic Commerce Conference, 2002. [9] S. D. Kamvar, M. T. Schlosser, and H. Garcia-Molina, “The eigentrust algorithm for reputation management in p2p networks,” in WWW ’03: Proceedings of the 12th international conference on World Wide Web. New York, NY, USA: ACM, 2003, pp. 640–651. [10] D. DeFigueiredo, E. Barr, and S. F. Wu, “Trust is in the eye of the beholder,” UC Davis, Tech. Rep., 2007. [11] M. Piatek, T. Isdal, A. Krishnamurthy, and T. Anderson, “One hop reputations for peer to peer file sharing workloads,” in NSDI’08: Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation. Berkeley, CA, USA: USENIX Association, 2008, pp. 1–14. [12] M. Spear, X. Lu, N. Matloff, and S. F. Wu, “Karmanet: Leveraging trust ed social path to create judicious forwarders,” UC Davis, Tech. Rep., 2009. [13] J. R. Crandall and F. T. Chong, “Minos: Control data attack prevention orthogonal to memory model,” 2004. [14] M. Costa, J. Crowcroft, M. Castro, A. Rowstron, L. Zhou, L. Zhang, and P. Barham, “Vigilante: end-to-end containment of internet worms,” SIGOPS Oper. Syst. Rev., vol. 39, no. 5, pp. 133–147, 2005. [15] X. Lu, M. Spear, K. N. Levitt, and S. F. Wu, “ibubble: Multi-keyword routing protocol for heterogeneous wireless sensor networks.” in INFOCOM. IEEE, 2008, pp. 968–976. [16] M. K. Reiter and A. D. Rubin, “Crowds: anonymity for web transactions,” ACM Transactions on Information and System Security, vol. 1, no. 1, pp. 66–92, 1998. [Online]. Available: http://citeseerx.ist. psu.edu/viewdoc/summary?doi=10.1.1.42.2499 [17] R. Dingledine and Nick, “Tor: The second-generation onion router,” in Proceedings of the 13th USENIX Security Symposium, San Diego, CA, USA, August 2004, pp. 303–320. [18] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Schenker, “A scalable content-addressable network,” SIGCOMM Comput. Commun. Rev., vol. 31, no. 4, pp. 161–172, 2001. [19] P. Maymounkov and D. Mazi˜ares, Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. Springer, 2002. [Online]. Available: http://www.springerlink.com/content/2ekx2a76ptwd24qt [20] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, and I. Stoica, “Rofl: routing on flat labels,” SIGCOMM Comput. Commun. Rev., vol. 36, no. 4, pp. 363–374, 2006. [21] “Youtube.” [Online]. Available: www.youtube.com [22] D. d. B. DeFigueiredo and E. T. Barr, “Trustdavis: A non-exploitable online reputation system,” in CEC ’05. IEEE Computer Society, 2005, pp. 274–283. [23] L. Banks, P. Bhattacharyya, M. Spear, and S. F. Wu, “Davis social links: Leveraging social networks for future internet communication,” in FIST ’09, 2009. [24] “Geni.” [Online]. Available: http://www.geni.net/ [25] S. Kubrick, “Dr. strangelove or: How i learned to stop worrying and love the bomb,” 1964.
