3 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS 1 Exploiting Anonymity in P2P-based Systems Hristo Chonov Abstract After David Chaum, considered the father of anonymous communications, proposed a system for anonymous in 1981 many new systems has been implemented on the scene aiming to offer better protection than their predecessors. But trying to cover some security holes in the anonymity new protocols can cause other security issues. In this paper I describe some of the peer-to-peer network protocols that employ anonymization techniques and some of the known approaches that can be used to exploit anonymity in overlay networks built on top of those protocols. At the end, I make a conclusion based on a table showing the most widely uncovered and effective types of attacks. I. INTRODUCTION Anonymous overlay networks allow Internet hosts to communicate with each other, while preventing linkability between sender and receiver from the rest of the overlay. This means they conceal who is interacting with whom. Those networks have a very important usage like for online privacy, resisting censorship, evasioning surveillance. At some places in the world there is no freedom of speech and censorship is imposed. There expressioning online could be considered as a crime and thus the authors need to protect their real identities. This kind of networks could also be used to resist blocking circumvention censorship. Of course they could be used for illegal file sharing, what someones are doing, by running BitTorrent on the top of Tor for exchanging illegal content. But actually this is not what these systems are built for, it s just an exploitation of them. Some of the schemes use global list to choose relays from it. An alternative is to organize the nodes of a network overlay in a distributed hash table (DHT), which can form a decentralized and distributed system that maps identifiers to nodes and has a mechanism to determine the responsible node- ID for a given identifier. The problem however with DHTs is that they are proven to have very weak points and thus be very insecure queries in DHTs are easy to observe and manipulate. That s why redundancy mechanisms for securing DHTs are developed and will continue to be developed in the future. In this paper I review both mechanisms for finding relays i.e. overlays based on a global list and overlays based on a DHT. In the most cases the anonymity has a price and that is the speed. The anonymous peer-to-peer network overlays are structured in two areas: The first one is Low-Latency anonymity systems and the second one is High-Latency anonymity systems. The time of message delivery in High-Latency systems like Mixmaster and Mixminion is around 4 hours. This two networks are assuming that the attacker can see the whole network traffic and also can manipulate some of the nodes, who are taking part in the anonymous message transfer. On the other side Low-Latency systems like Tor attempts to reduce the delivery delay to provide normal speeds for internet browsing and file sharing. In the current open peer-to-peer overlay networks every client can participate without the need to prove that it is trust-able. Thus a small fraction of malicious nodes can easily be built, what can lead to incorrect message delivery. That s why closed peer-to-peer overlay networks where the clients connect to the nodes they trust have evolved. In some cases to participate the network a client needs an invitation. The closed peer-to-peer networks are usually very small and increasing the size of the network makes it more insecure. I ll mainly concentrate on open peer-to-peer systems. The main objective of an adversary in an anonymous communication system is to link the initiators of connections with their respective communication partners and vice versa. Outline The rest of the paper is organized as follow: In Section II I give a short background information and in Section III I briefly describe well known look up mechanisms and their weaknesses. Sections IV to XI present different systems for anonymous communication and how the anonymity in those systems can be exploited. At the end I make a conclusion about the most uncovered weak points which could be used to exploit the anonymity in the respective systems. II. BACKGROUND David Chaum, considered the father of anonymous communications, proposed a system for anonymous in 1981 which is count as the the first one of its kind. He introduced the term MIX that is a server between sender and receiver performing cryptographic transformations on the messages and forwarding them to the next destination in such a way that the input address could not be linked with the output address. Most of the existing anonymous routing layers utilize Chaum- MIXes for anonymity. Figure 1. illustrates a path in a MIX system. Other technique built on the idea of Chaum-MIXes is Onion-routing, where the messages are encrypted in layers and sent through several network nodes (onion routers), which remove the upper encryption layer to uncover routing instructions. Fig. 1. Example Path in a MIX system 3

4 2 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS In the following sections I review Tor and Torsk, which are Onion-routing schemes and Tarzan, Cashmere, Salsa and MorphMix, which are Chaum-MIXes based systems. Torsk, Cashmere and Salsa also are based on DHTs for finding relays. They all represent open peer-to-peer networks. III. STRUCTURED PEER-TO-PEER OVERLAY NETWORKS A. Overview In structured P2P networks, peers employ a globally consistent protocol. Thus the nodes in the overlay can route and search for other peers. The most such networks are using distributed hash table DHT. These following are look up mechanisms, which doesn t built a whole system and actually does not employ any anonymization techniques, but they can be used as a base for building a peer-to-peer system that provides anonymity. Some of this look up mechanisms are Pastry, Tapestry, Chord and CAN. Lets just briefly describe them. In Pastry the nodes get assigned an unique IDs and maintain a list of their neighbors called leaf set, which is used for storing replicas. The IDs of the nodes included in the leaf set are numerically close to the current node-id. From a message to be send is built a key, which is used for choosing the node towards which the message will be routed. Beside the list of neighbors a node maintains also a routing table. Two options to route a message are available. First, the message is forwarded to a node-id from the routing table, which shared prefix with the key of the message is at least one bit longer than the shared prefix with the current sender. Otherwise, the message is forwarded to a node-id which shares the same prefix length, but is numerically closer to the key than the current node. Finally, if no node is found to which the message should be forwarded the destination is either the current node or its immediate neighbor. Tapestry is similar to Pastry, but the nodes don t keep a neighbors set. Tapestry also uses a surrogate routing mechanism by trying to forward the message to a node that matches the key s n-th digit. If no such node exists in the routing table, the n-th digit will be incremented till an appropriate node is found. Unlike Pastry Chord uses circular ID space and routes the messages only in clockwise direction. Chord doesn t have a routing table but maintains a so called finger table, which contains up to m pointers to online nodes. A node always is aware of it s predecessor. The more deeper an entry in the table is, the more distant node it ll point to. Chord maintains the replicas by mapping keys to node-ids. CAN is based on d-dimensional Cartesian coordinate space. A hash function is assigned to each dimension. The entire space is partitioned amongst the nodes. Each node has a routing table consisting of O(d) entries, which are the neighbors of the current node. B. Attacks 1) Attacks based on the node-id assignment [1]: The security of structured peer-to-peer overlay networks depends on the assumption that the assignment of node-ids can t be controlled from an attacker. If an attacker succeeds in finding a way to control the distribution of the node-ids she can use a lot of mechanisms to violate the network overlay. An attacker needs to control small fraction of nodes. When, in Chord, the attacker chooses appropriate node- IDs she can accomplish that all the entries in a victim s finger table point to enemy nodes. The access to a target object can also be controlled by choosing node-ids close to the target key and so the attacker can gain full control over the target object by owning all the replicas. So the attacker can delete, modify, corrupt, or deny access to the object. Using both techniques an adversary is able to reveal identities. Sybil attack: If the attacker can gain control over many legitimate nodes she can accomplish 1. and 2. without the need of freely choosing node-ids. This kind of attack is called Sybil attack. 2) Attacks based on the maintenance of the routing table [1]: The first attack works only against routing algorithms which are aiming to improve network efficiency by calculating the delays between nodes. If an attacker controls enough number of nodes she can intercept a delaycalculating request from a correct node to hostile node and get another faulty node closer to the correct node answer to the request. This way an attacker can populate the victim s routing table with bad entries. The second attack is based on the routing updates. It is hard to check their trust in network overlays like Pastry and Tapestry. The attacker can just start populating the overlay with updates pointing to hostile nodes. As result the correct nodes will announce their bad entries in the routing updates. Storage Anonymity means that a request for a particular data doesn t reveal the node storing this data. Chord doesn t provide such anonymity since the answer of such a request is the IP address of the node on which the data is stored. Problem: Pastry and Tapestry employ very weak constraints which node-ids should be granted in the routing table. This gives the opportunity to use the network proximity and thus to improve routing performance. CAN and Chord on the other side employ very strong constraints: only the closest node- IDs should be accepted in the routing tables. This improves the security, but thus the network proximity can t be used. IV. ATTACKS AGAINST GENERAL CHAUM-MIXES BASED AND ONION-ROUTING BASED NETWORK OVERLAYS A. Timing Attacks in Low-Latency MIX Systems A MIX can be defined as a proxy that hides the conversation between its incoming and outgoing connections. Routing through many MIXes provides strong unlinkablity of senders and receivers. Among the systems using MIXes for routing are 4

5 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS 3 Onion-routing, Freedom and Tarzan. Using a timing attack an adversary tries to identify, if two malicious MIXes M first and M last that belongs to him are on the same path. To reveal the Identity of the sender and the receiver one of the MIXes should be the first and and the other one the last in the chain and they must be aware of their position. This way an adversary is able to find a correlation in the timings of both malicious nodes and thus link the initiator with the receiver. The first method to exploit the attack is to compute the difference between the arrival time of packet x n and its successor packet x n+1 at M first and M last. The adversary can compare both differences and for example, if the delay at M first was large and both nodes lie on the same path the delay at M last is more likely to be larger than average. This method is sensitive to dropped packets and some otherwise perfect correlations could be identified as a mismatch. More powerful approach [8] is to use a nonoverlapping and adjacent windows of time. During this periods both malicious nodes will count the packets on every path they are belonging to. Finally the collected counts need to be compared. To make this attack even more powerful M first could drop intentionally packets to enhance the correlation. Onion-routing and the second version fo Freedom do not offer any special mechanisms to prevent timing attacks if an adversary happens to own the first and the last node of a chain. Tarzan and the original version of Freedom employ constantrate cover traffic between pairs of mixes and send traffic between covered links. Freedom however is still vulnerable to timing attacks, because the traffic between the initiator and first node and between the last node and the receiver is not covered. In Tarzan and in Freedom the mixes are able to distinguish between real and covered traffic and the malicious nodes can consider only the first for the timing attack. B. Intersection Attacks in Onion-routing Systems The Onion-routing project has drawn the attention to such kind of attacks and also named them Traffic Confirmation Attacks. This kind of attacks is based on the fact that not all the nodes are active at the same time and that users typically communicate with a small number of parties for example a user queries the same web sites in different sessions. To reveal the identities of the nodes the observer records the active users and intersects the sets. This is possible only if the observer knows all the nodes in the system. When the attacker has reduced the possible set of initiators she can switch to another tactic e.g. Packet Timing to reveal the original initiator. V. TOR SECOND GENERATION ONION-ROUTING A. Overview Tor is a Low-Latency circuit-based anonymous network overlay, thus it s main aim is to hide the identities of the clients. When a client wants to establish a connection to a server, it first obtains a list of Tor nodes from a directory server and then picks up n nodes from the Tor network and afterward builds a circuit. The messages are encrypted n times with encryption keys negotiated separately with the hops in the circuit. The first encryption is done with the key known to the last node called exit node and the last encryption is done with the key known to the first node in the circuit. This represents the so called onion routing and every node in a circuit knows only its predecessor and successor. Multiple TCP streams from one source are put together in one circuit to improve efficiency instead of building many circuits from a single node. This improves the anonymity and it is restricted to put new streams in circuits containing streams older than 10 minutes. Tor protects against non-global adversary that only control fraction of the nodes. Tor doesn t protect against attacks trying to find out, if two parties are communicating with each other by observing them this kind of attack is the already mentioned traffic confirmation attack. Tor only makes it difficult for an adversary with weak suspicions to collect more information. B. Attacks 1) Traditional traffic analysis global passive adversary: One kind of attack is to consider the time of connection initiations. Statistical variant of this attack is also developed. Both attacks could be used to determine if a specific node establishes connections to a set of web sites regularly. Low cost traffic analysis - One corrupt node in the Tor overlay network is required to accomplish this attack. The corrupt node first must establish connections to the nodes in the network to measure and monitor the latencies of those connections for some period of time. The aim of this is to determine the traffic loads of the nodes the attacker has made connection with. Then from this traffic patterns are derived. They can be used to be built a template indicating how a stream based on the reply of a server outside the overlay network will look like inside of it. A comparison of all links is needed to find similarity with the model built from the template and so even the position of a node in the circuit can be found. [6] 2) Traffic analysis non-global passive adversary: Packet Counting Lone Connection Tracking []: This attack is applicable on the 2 nd generation onion routing, Tarzan and MorphMix. The attacker only needs to observe all the links used by a connection. By counting the packets on lone connections the anonymised streams can be followed. The term lone connection means that only this connection is traveling toward a particular link. If the packets number on D->X and X->T is very similar, it can be assumed that X is communicating with T, as it can be observed on Figure 2. There are some restrictions about the measure interval to implement the attack: First, it must be larger than the mix delay. Otherwise the incoming and outgoing packet counts will be made dissimilar. Second, it must be shorter than the mean time new connections are built between the pair of links. A simulation [] in a network with 100 nodes showed that 92 Figure 3. shows a graph of the number of nodes against 5

6 4 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS Fig. 2. Packet Counting Example Fig. 4. Attack Model Against Tor TCP port the client is listening on, 3. peer ID of the client and 4. optionally the IP address of the Alice s NIC device. In return the tracker sends a sub list of peers already joined the torrent. Finally, the client sends a handshake to the peers to establish a connection with them. BitTorrent can also use DHT over UDP to search for a tracker controlling the desirable torrent. BitTorrent can run over Tor network as over proxy. So it is possible to use the Tor network for communication with the tracker and the peers. The client can decide to use Tor for only one of them or both. Fig. 3. Lone Connections Simulation the lone connections when there are 60 connections all running through 2 links. Traffic-analysis of Tor - Tor employs round-robin sending of packets. If a stream has no more cells to be forwarded, it is skipped and the node proceeds with the next waiting connection. Thus the load on a Tor node affects the latency of the connections running through it. This can be used by an attacker. An adversary can route a connection through a Tor node and with another corrupt node measure the latency to learn the traffic load of that node by connecting with it and sending probe traffic. If traffic pattern is already extracted the traffic load can be compared with it and thus an attacker is able to detect the nodes it is relayed through. The following attack is just a more powerful version of the previous one and is based on the assumption that a victim node is trying to access a corrupt server which sends the data in specific traffic pattern. Using this pattern a template can be derived and it can be checked which nodes correspond to it. One such traffic pattern could represent sequences of short bursts of data. Figure 4. shows an example model of this attack. [6] VI. BITTORRENT ON TOP OF TOR A. Overview of BitTorrent When joining a torrent Alice first sends an announce message to the tracker containing 1. unique torrent identifier, 2. B. De-anonymizing IPs in BitTorrent on top of Tor In a study [2] 6 Tor exit nodes have been mounted all over the world for 23 days. 1) Inspection of BitTorrent control messages: The tracker announces can contain the IP address of a client and according to the study 3968 unique public IP addresses were captured, which represents 58 Clients supporting the Extension Protocol may also send additionally their IP addresses. As result 1131 unique public IP addresses were collected 33 2) Hijacking Trackers Responses: The following is typical man-in-the-middle attack and works, if the client is using Tor only for communication with the tracker. The attacker Bob can hijack the tracker s response to an announce message from Alice. Then Bob can just send an altered sub list with peers where the first one is Bob himself. This way Alice will try to establish a direct connection with Bob and thus revealing her public IP address. Comparing this IP address with the public addresses of the Tor s exit nodes can show, if it belongs to Alice or to the exit nodes. Finally, 2240 unique public IP addresses were collected - 3 3) Exploitation of the DHT: As Tor doesn t support UDP the client will connect to the DHT without Tor and Alice will publish it s public IP address in the DHT and despite of the connection to the peers over Tor the IP address of Alice can still be looked up in the DHT. This is possible only when Bob is controlling Alice s exit node and so knowing her BitTorrent port number. Later Bob can search in the peer list for this torrent in the DHT and compare the port numbers. After finding a match it is possible that the published IP address belongs to Alice. This tactic resulted in 6151 unique public IP addresses. 6

7 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS 5 A. Overview VII. TORSK Torsk improves the scalability of Tor and retains the benefits of the client-server architecture claiming it doesn t introduce new attacks. Torsk distributes most of the Tor directory service over a DHT and propose usage of secret buddy nodes and certificates to keep the look up initiator anonymous. The look up mechanism is based on Kademlia DHT and Myrmic. Torsk look-up: Every node maintains a finger table and when it wants to look up data x, it first selects t (usually 3) pointers close to x. Then the querier starts independent look ups at the t pointers and builds a list with the closest nodes from every look up he has learned. Next the node selects again from every list t pointers and start the same way independent look ups. This iterative process terminates when at the end of an iteration the lists with the closest nodes to x stay unchanged. Every node has a certificate from a trusted central authority, that contains all fingers of the node. Finally, the querier can check if the node he has found is responsible for x by verifying it s certificate. During the iterative process every node included in the search learns x and if a hostile node is looked up it can associate the found node with the query initiator. Secret buddy: To remain anonymous the nodes select random buddies in the network and when a node searches for some data it gets the query executed from one of its buddies. The selection of buddies is realized with random walks before starting the look up, what prevents Timing Analysis Attacks. The buddies should be used only one time and not repeatedly. B. Attacks 1) Inherited attacks: As Torsk is just a implementation of Tor that aims to make the overlay network achieve scalability it inherits the weaknesses of the previous system. Thus all the attacks mentioned in the Tor section are applicable also against the Torsk overlay network. 2) Buddy Exhaustion Attack: Since the buddies should be used only one time on the end node of a built circuit, Buddy Exhaustion Attack can be used and thus the attacker can succeed placing malicious entry and exit nodes in many circuits. Then the attacker can apply DoS attack or use timing analysis attack. The attack consists in flooding the node that is looked up with the aim to extend the circuit. Since the random walk for selecting new buddies is restarted every time when an invalid certificate is found, the attacker can just let the malicious nodes expose invalid certificates and with enough large fraction of hostile nodes it is most likely a malicious node to be included in a random walk. Thus the victim node can t recover from the exhaustion attack. The performed study [3] shows that with this attack over 80 A. Overview VIII. SALSA Salsa is a DHT-based layered circuit anonymity scheme. Look up mechanism: The querier selects r random nodes A 1...A r and gets them separately look up for another r nodes Fig. 5. Example Binary Tree In Salsa B 1...B r. Then connections are built from each A 1...A r node to each B 1...B r node. The initiator then asks the B nodes to search for a final node. Next the querier selects a circuit randomly and connects the final node to it. The nodes get mapped trough a hash function of their IP addresses into points in the ID space. This is done for bound checking and so the closest node to a target is selected. If a path exceeds a threshold length, it is discarded. The ID space is partitioned in groups as each node knows all of the participants in its group and also knows some nodes in the other groups to route look up requests in the system. The groups are organized in the form of a binary tree. A node has a global contact for each level in the tree, which is selected at random from the child subtree where the node is not belonging to. A global contact is chosen by hashing the concatenation of the selecting node s IP address and the level height. This is done to ensure that a node cannot select arbitrary global contacts. Figure 5. shows an example for a binary tree in Salsa. B. Attacks 1) Intersection Attack: To accomplish this attack in Salsa an attacker only needs to have at least one node in each group. When 4096 groups exits, an attacker needs hostile nodes to ensure success with probability 0,9998. [4] The other mechanism of gaining overview of the network is by using the look up process. This is a long procedure and new nodes are joining over and over again. 2) Active path compromise attacks: If an attacker gets all the nodes in a particular stage compromised, she can get all the IDs/public keys of the next set of nodes, being looked up, modified. Since a node can not determine the validity of a public key the bound checking algorithm is defeated. The remaining stages of the path building can now be emulated. If the attacker gets the first and the last node in a circuit compromised she can use end-to-end timing analysis to compromise the path. 3) Conventional Continuous Stage Attack: Another way of compromising path is to have at least one malicious node at every stage of the path. Lets take the three attacks nodes A 1,

8 6 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS A 2, A 3, where 1, 2 and 3 stay for the different stages. A 1 looks up A 2, which on his turn looks up A 3. A. Overview IX. CASHMERE Cashmere is a recursive DHT based network overlay on top of Pastry DHT. A node has k-bit signed node-id. The nodes are divided in groups with m-bit IDs, where k is equal or greater than m. The group-id serves as a prefix of the nodes. A node participates in a group if the ID of the group is a prefix of its ID. Every group has assigned public/private keys and the group members receive them. The nodes obtain also the public keys from the other groups. Messages in the overlay are routed using group-ids. The first found node, that has this group-id as a prefix is responsible for forwarding the message to all other members in this group. The forwarding of messages is done through n groups. The sender encrypts separately the path and the message in layers using the public keys of the groups. Thus the same path can be used multiple times. A group in the path decrypts the path message with it s private key and finds out the next group in the path and the symmetric key to decrypt the outer layer of the message. B. Resending captured messages Attack [4] If a observer catches a message m 1 delivered to group G 1 and m 2 to G 2, the attacker can try to send m 1 over a new path, including both groups and built by the attacker. Then depending on that if m 2 is seen on the same place, where the first m 2 was caught it is sure whether G 1 and G 2 were/are neighbors on the original path. This attack is possible, because only public-private key structure is used for encryption. It is not applicable in overlays where only session keys are used for encryption. A. Overview X. TARZAN Tarzan is the first anonymizing communication system that is both self-organizing and fully-decentralized. Every node in the network is a client and a relay. Not both ends of a tunnel need to be in Tarzan for the communication. If a client wants to connect to a server not in Tarzan, the last node in the circuit (the exit node) acts as a NAT-Server. Tarzan is based on the Chaum-MIXes idea and every node in the tunnel adds or removes encryption layer depending on the direction. When joining Tarzan, a node ask k nodes already in the network to share with it mimic traffic. This means they must send him their mimics. The mimics are normal nodes in the network and the joining node builds a bidirectional connections with them. When Alice wants to establish a connection with a server, she picks up the first node n 1 of her mimic list. Then she asks n 1 for its mimic list and picks up the second node from it. This process is repeated until the path reaches length of l hops. The l + 1 node in the path is the NAT-Server and Alice picks up it randomly from her peer database. The initiator first negotiates symmetric session keys with the hops in the circuit. The IP packet that has to be send is first encrypted with the key of the last node in the tunnel and last with the key of the first node. Before forwarding the packet each node first removes the outer encryption layer and then tags the packet with the flow identifier of the next node in the tunnel. The last hop removes the last layer and sends the original IP packet. The response from the server then gets encrypted l times in the tunnel and Alice needs to perform l decryptions. B. Attacks 1) Low Cost Attack: The term low cost attack means that the attacker requires only a partial view of the network. Like the low cost attack against Tor a corrupt node must find the other nodes and establish connections with them to monitor their latencies. When the adversary is ready with the monitoring she can use the latencies information to obtain the traffic load of the nodes, she has built connections with. If the nodes were on a path to a corrupt server there will be similarity between their traffic load and the traffic load of that server. Checking all the nodes can lead to learning the whole path. For this attack to be applicable, the traffic loads of the nodes must be extracted from the latencies, as the described above Tor attack. Second, the corrupt node must be able to discover all nodes. Third, an establishment of direct connections to all of them should be possible. In the testbed of Tarzan during the study [5] a mimic part wasn t available and it wasn t possible to conduct an experiment to obtain, if the mimic mechanism is able to destroy the timing characteristics. So the problem if it is possible to extract the real traffic loads was left open. Tarzan offers the ability to discover all other nodes in the network overlay through a goosip-protocol based mechanism. The last condition is also met. Through the mimics is not possible to be established a direct connections to all nodes, unless the desired nodes are mimics of the corrupt node. But the NAT-Server node can be freely chosen and thus it is possible to be established a one-hop connection to the desired nodes if they are treated as the NAT-Server of that connection. As conclusion the applicability of the attack against Tarzan depends only on the open question if the mimic traffic can destroy the timing characteristics. 2) Intersection Attacks: Since as already mentioned a node is capable of discovering all nodes in the network an Intersection attack is thus applicable here. 3) Packet Counting Lone Connection Tracking []: As I already said in the Tor Section that this attack is applicable also against Tarzan. A. Overview XI. MORPHMIX MorphMix is a peer-to-peer anonymous network based on MIXes. Each node is a client that generates anonymous traffic and at the same time is a mix server that forwards anonymous traffic for other nodes. A node finds other nodes in the system through its neighbors. To defend against attacks based on colluding nodes that redirect to a set of other colluding nodes when a tunnel is built up, MorphMix introduces new collusion 8

9 EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS detection mechanism (CDM). Each node has virtual links via TCP to its neighbors. MorphMix uses fixed size messages and layered encryption to defends against traffic analysis and also protect the message content. To build a anonymous tunnel the initiator D firsts select node A from its neighbors and establish a symmetric key with it. If the initiator wants to extend the tunnel he asks A to recommend nodes. Then D selects one of the recommended nodes, B, and gets a witness node C from the already known nodes to establish a symmetric key between D and B. This continues until D stops appending nodes to the tunnel. The witness mechanism is also used for the selection of the first node, thus a node is not aware of its position in the tunnel. CDM To improve security each node maintains a fixed size extended selection list L ES which consists of the suggested selections and the 16-bit IP prefix of the node that recommended them. To detect that a malicious node recommends another malicious nodes MorphMix distinguishes the nodes from each other by their 16-bit IP address prefix, because it is very costly for an attacker to own nodes in many unique /16 subnets. For every recommended selection a comparison in the extended selection list is made. B. Attacks 1) Intelligent Selection Attack if a colluding node knows it is the first one in the tunnel: 1) For every victim we construct a list of selections S, so that there is no overlap in the subnets between the nodes in S. 2) Global pointer p g keeps reference to a node in the list that is to be offered the next time. 3) Every time the pointer is incremented and when it refers to the last node in S the pointer is moved to the first node and the iteration goes so on. 2) Intelligent Selection Attack if a colluding node doesn t knows it is the first one in the tunnel: 1) We reply to a v s request by assigning local pointers p l to the elements referenced by p g and offer v this selection. 2) For every successive request we increment p l and offer the selection it points to. 3) After the tunnel is built up we just measure the length of the tunnel and determine if the initiator was v or some other node. 4) In the case v was the initiator we set p g to point to the elements referenced by p l. The Intelligent Selection Attack is very powerful especially against new nodes, because their extended selection lists are empty. 3) Packet Counting Lone Connection Tracking []: As I already mentioned earlier in the Tor Section that this attack is applicable also against MorphMix. Low cost traffic analysis and Packet counting are also very powerful threats that can be used against plenty of the existing anonymous communication systems. I hope this review of the attacks will motivate the development of a communication system that implements anonymization techniques and doesn t expose weaknesses which can be used to employ the attacks described in this paper and also others not reviewed here. Personally I think that the development of a new system should not follow the approaches of the existing ones and needs to take a whole new way, because analysis of the old schemes has proven that those systems could not be made resistant against all the attacks. The focus of my paper were Low-Latency Open anonymous peer-to-peer systems and I haven t reviewed any closed ones a.k.a. Darknets like Nulsoft s WASTE and Freenet. However I suggest extensions of this paper that include those systems and even more of their kind. REFERENCES [1] Miguel Castro and Peter Druschel and Ayalvadi Ganesh and Antony Rowstron and Dan S. Wallach Secure routing for structured peer-topeer overlay networks. Proceedings of the 5th symposium on Operating systems design and implementation - OSDI 02, III-B1, III-B2 [2] Pere Manils and Abdelberi Chaabane and Stevens Le Blond and Mohamed Ali Kaafar and Claude Castelluccia and Arnaud Legout and Walid Dabbous Compromising Tor Anonymity Exploiting P2P Information Leakage. VI-B [3] Qiyan Wang and Nikita Borisov In Search of an Anonymous and Secure Lookup. ACM CCS, VII-B2 [4] Andrew Tran and Yongdae Kim Hashing it out in public: common failure modes of dht-based anonymity schemes. WPES, VIII-B1, IX-B [5] Rungrat Wiangsripanawan and Willy Susilo and Rei Safavi-naini Design principles for low latency anonymous network systems secure against timing attacks. In Proceedings of the fifth Australian symposium on ACSW frontiers (ACSW 0, 200. X-B1 [6] Steven J. Murdoch and George Danezis Low-Cost Traffic Analysis Of Tor. In Proceedings of the 2005 IEEE Symposium on Security and Privacy. IEEE CS, V-B1, V-B2 [] Andrei Serjantov and Peter Sewell Passive Attack Analysis for Connection-Based Anonymity Systems. In Proceedings of European Symposium on Research in Computer Security (ESORICS, V-B2, V-B2, X-B3, XI-B3 [8] Brian N. Levine and Michael K. Reiter and Chenxi Wang and Matthew Wright Timing attacks in low-latency mix systems (extended abstract. Proceedings of the 8th International Financial Cryptography Conference (FC 2004), Key West, FL, USA, February 2004, volume 3110 of Lecture Notes in Computer Science, IV-A XII. CONCLUSIONS As we can see based on Table 1. that makes a summary of the attacks described here the Intersection Attack approach seems to be serious problem for Onion-routing schemes. 9

20 P2P SERVICE DESCRIPTION LANGUAGE 1 P2P Service Description Language Dimitar Goshev Abstract P2P networks are increasingly used for different kinds of services, which could be generally implemented in a P2P cloud system. Technologies known from the Service Oriented Architecture, such as description languages for services could be a powerful tool in such a P2P service cloud. This paper gives an overview of the Service Oriented Architecture, describes the role of a P2P service description, and introduces the Ontology Web Language for Services as a description language for P2P services. It illustrates that a description language for P2P services could provide substantial value to the P2P computing paradigm and is one of the technologies and machanisms that will allow transition from file-sharing to service- and data-sharing in P2P networks. I. INTRODUCTION In the recent years P2P netowrks are increasingly used for a variety of services. The diversity among the types of P2P services, along with the different kinds of P2P systems, has made it difficult to establish a widely accepted set of standards and protocols, that would facilitate the description of P2P services. Each one of the contemporary P2P networks accommodates its own proprietary set of protocols, which are arbitrarily designed in a way to enable their specific features and properties. They present limited or no capabilities for automated service discovery, selection, composition and invocation. A description of P2P service, which provides sufficient information to enable mechanisms for publishing and discovery of the service in the P2P network and facilitate interaction between the peers, could be one way to address these issues. An interpretaion of such a description must be consistent among all the participants in a service interaction. Therefore a necessity to establish a standartized approach for describing the services arises. In this paper this is addressed by introducing the Ontology Web Language for Service(OWL- S) as a description language for P2P services. Thus enabling description of P2P services, that can be used unambiguously across and between different implementations. OWL-S allows the service description to answer questions, such as What does the service provide?, How is the service used? and How to access the service? in a machine-understandable form. Descriptions in OWL-S are in no way limited to services, which follow the client/server model. In fact the research shows, that by introducing semantics to service description, OWL-S enables mechanisms to discover and locate services in P2P netwrorks and is powerful enough to describe details on how to divide composite services into sections, which can be executed by different execution peers. This paper is organized as follows: In order to present traditional approaches to service description, discovery and invocation, chapter 2 gives an overview of the Service Oriented Architecture(SOA), an architecture designed to support the implementation of services. Chapter 3 provides information about the role of a P2P service description language and the speciffic issues, which a P2P service description will address. Chapter 4 gives a detailed view of OWL-S and how it could be used for P2P service description and chapter 5 presents briefly alternatives, which has been considered during this research. II. SERVICE ORIENTED ARCHITECTURE When we deal with the notions of service and service description, it is inevitable to have a look at the Service Oriented Architecture(SOA), in order to gain knowledge about the traditional approaches to service description, discovery and invocation. SOA is an architecture designed to support the implementation of services. It could be defined as a set of design principles for building large loosely coupled systems, which package functionality as inter-operable services. SOA defines an interaction model between three primary parties - the service provider, the service broker and the service client [Figure 1]. Figure 1. The three primary roles in the service interaction model. The service provider creates the service description and implementation and publishes its interface and access information to the service registry. The service broker manages registries, and supplies information about services to enables clients to discover the service. The service client locates entries in the broker registry and binds to the service provider in order to invoke the given service. A. Overview of techologies in SOA The traditional service solutions use a server-centric approach to manage all components. This limits their deployment to static domains, since a service invocation will fail, if 20

21 2 P2P SERVICE DESCRIPTION LANGUAGE the server component changes its availability or location. The services are typically defined by a set of standards, including Extensible Markup Language(XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery and Integration(UDDI). These technologies are described bellow. 1) SOAP: Commonly an invocation of a service is accomplished through exchange of a series of messages, normally encoded in XML. SOAP, a lightweight protocol for exchange of information in a decentralized, distributed environment, is the most widespread technology for exchanging these messages. The protocol consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data-types, and a convention for representing remote procedure calls and responses[8]. SOAP typically depends on other Application Layer protocols, most notably Remote Procedure Call (RPC) and Hypertext Transfer Protocol (HTTP), for message negotiation and transmission. However the SOAP/TCP[9] and SOAP-over-UDP[5] specifications, present an alternative approach, which eliminates the need of application layer protocol. SOAP also provides mechanism for binary data transfer. That is the SOAP Message Transmission Optimization Mechanism(MTOM) - a W3C recommendation by Microsoft, IBM, EBA and Canon. MTOM makes use of the XML-binary Optimized Packaging(XOP) format for optimizing the transmission of SOAP messages. It combines the composability of Base 64 encoding with the transport efficiency of SOAP with Attachments(SwA). Non-XML data is processed just as it is - the data is simply streamed as binary data in one of the Multipurpose Internet Mail Extensions(MIME) message parts. Solutions for data transfer with MTOM, such as file transfer in chunks, exist and demonstrate the feasibility of using this technology for data transfer in P2P networks. Experiments show that XOP/MTOM, keeps performance of binary data transfers via service interface at a reasonable level[15]. Other alternatives for handling binary data in SOAP messages are also available: SwA and Direct Internet Message Encapsulation(DIME). 2) WSDL: The WSDL definition describes how to access a service and what operations it will perform. The data-types for the information passed between the service consumer and provider are described using WSDL. The services are described as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint[3]. A WSDL document uses the following elements to describe a service: Types - a container for data type definitions using some type system. XML Schema is used (in-line or referenced) for this purpose. Operation - an abstract description of an action supported by the service. Four types of operations exist: a request-response,where the client expects response from the service, a solicit-response,where the service expects a response from the client, one-way operation, representing a call by the client to the service, and a notification, representing a call by the service to the client. Interface - an abstract set of operations supported by one or more endpoints. Binding - a concrete protocol and data format specification for a particular port type. Endpoint - defines the address or connection point to a service. Service - a collection of related endpoints, which has been exposed to the web based protocols. 3) UDDI: The discovery of the services is facilitated by UDDI. It defines a standard method for publishing and discovering the network-based software components of a SOA. The core information model used by the UDDI registries is defined in an XML schema. The UDDI XML schema defines four core types of information: business information, service information, binding information, and information about specifications for services. UDDI provides only a central registry [2]. Figure 2 illustrate a traditional scenario of development and deployment of services. Figure 2. B. P2P and SOA The traditional services development/deployment scenario. From the described technologies above it is clear, that the traditional service solutions, present an approach, where the three main parties of the interaction model are commonly thought of as separate entities. However, it is more useful to consider the client, the provider and the broker as simply different behavioral roles, rather than separate pieces of software. In fact SOA doesn t impose a particular implementation style such as specifically a client/server, request-response model. The alternative approach to service interaction, namely services communicating in a P2P fashion, requires each node to accumulate one, two or all of the roles simultaneously. 21

22 P2P SERVICE DESCRIPTION LANGUAGE 3 In a P2P SOA, each node should be able to act as a provider of a set of services, a consumer of a service, and a broker, which offers information about services presented by the node and other nodes in the network. Of course, the nodes are responsible for their own security, reliability, process, and management capabilities. III. DESCRIPTION OF P2P SERVICES In order to provide a P2P service description language, first we need clear definitions of What is a P2P service? and What is the role of the P2P service description?. A. P2P Service A service is defined as a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description[12]. In [10] is stated that, the term P2P service has emerged as a result of the merging of P2P and service oriented computing paradigms and that the term itself has not yet reached consensus among the P2P community. The definition of a service is not restricted to services following client/server approach. Therefore in this paper the term P2P service is considered equivalent to the term service defineded above, with the additional knowledge, that these services are used in a P2P network. B. P2P Service Description In general the description of a P2P service should present sufficient information to enable mechanisms for publishing and discovery of the service in a P2P network and facilitate interaction between the peers. While, there are certain elements that are likely to be part of any service description, many elements such as function and policy may vary. The specific goals of the description could be summarized as follows: Publication and Discovery - Describe what this service does and how to locate it in the P2P network. Present such a description, that could be used by discovery systems, which perform on distributed registries on ad hoc and managed networks. Specify the set of constraints and policies, under which the service operates. Selection - Provide enough details about the service capabilities and other critical information, that a client needs in order to decide whether or not, the described service is the most appropriate one for the given task. Service invocation - Provide information on how the client can interact with the service and how exactly to access it. This information should be preferably presented in a way understandable not just for developer of a client agent, but for a software agent, to enable automated invocation of P2P services. Composition - Present information on how to combine multiple services in the P2P cloud to achieve the desired goal. The description should contain enough detail on how to divide the described composite service into sections, which can be executed by different execution peers. Verification and Monitoring - Supply information about how to verify the service execution and recognize when errors occur, log and track progress of the execution. Security - Provide information about how to address issues such as authentication, authorization and privacy, evalute security parameters, etc. In the next chapter is illustrated that description of P2P services with OWL-S, accomplishes to supply the necessary information to achieve all of the listed above goals. IV. OWL-S The Ontology Web Language for Services is an ontology for services. It is often referred as a semantic markup language for describing services, due to the fact that it provides a standard vocabulary to create service descriptions, comprehensive enough to support the entire lifecycle of service tasks[4]. It is formerly known as DARPA agent markup language for services(daml-s) and some of the researched materials reffer it as such. OWL-S is based on the Ontology Web Language(OWL), a semantic markup language for publishing and sharig ontologies. In OWL ontologies are primarily exchanged as RDF documents(an RDF/XML serialization). OWL-S presents a semantic markup to describe what is being sent and why, not just how it is being sent. It has been developed as a joint effort between Carnegie Mellon University, Nokia, Stanford University, SRI International and Yale University as an aim to provide ontology, which automates the discovery, invocation, composition, interoperation and monitoring of servicess. It complements existing technologies such as SOAP, WSDL, UDDI, and Web Services Business Process Execution Language (WS-BPEL) by providing rich typing and class information that can be used to describe and constrain the range of service capabilities much more effectively than XML data types[13]. OWL-S supplies an abstract or application level description absent in other description languages such as WSDL. The OWL-S ontology includes three primary subontologies: the service profile, service model, and grounding[ Figure 3 ]. Genrally the service profile provides information about what does the service provide, the service model, also referred as process model gives information on how to use the service, and the service grounding supplies the necessary details about accessing the service. A. Service Profile The service profile is a high-level characterization of the service. It defines explicitly what are the server capabilities and what it provides. Its main purpose is to enable advertising, discovery and selection for services. It contains two type of properties, that describe the service - non-functional and functional properties. 22

23 4 P2P SERVICE DESCRIPTION LANGUAGE Figure 3. Top level of the service ontology. The non-functional properties describe what is achieved by the service, its limitations and boundaries, as well as other information such as location of the service, QoS features describing its characterics, etc. The functional properties consist of inputs, outputs, preconditions and effects. 1) Inputs, Outputs, Preconditions and Results: Inputs represent the the object descriptions that the service works on, i.e. the information that the service will receive. Outputs represent the object descriptions that it produces, i.e. the information that the client will receive. Preconditions define what must be satisfied in order the service to function as expected and effects, also known as results, describe what conditions will be changed after the service completes. Inputs, outputs, preconditions, and effects are used, by all three components of an OWL-S service model. The service profile could contain only the ones that are necessary for the discovery and selection of the service. B. Process Model All services described with OWL-S are represented by an instance of the OWL class service, which properties associate it with a process model. A process model[ Figure 4 ] describes how the service is used, i.e. how it executes its tasks. It contains all of inputs, outputs, preconditions and effects, to describe precisely the behavior of the service. The process model decribes three type of processes: composite, atomic and simple processes. Atomic processes correspond to the actions a service can perform by engaging it in a single interaction. Simple processes, can be used to provide abstracted, non-invocable views of atomic or composite processes. Composite processes are decomposable into other (non-composite or composite) processes[1]. The composition is created through control constructs. The available control constructs are: Sequence - a list of control constructs to be done in order. Split - process components to be executed concurrently. Split + Join - same as Split with additional barrier synchronization. Choice - for execution of a single control construct from a given set. Figure 4. Top level of the process ontology. Any-Order - processes, which have to be executed in some unspecified order but not concurrently. If-Then-Else - conditional control constructs. Iterate, Repeat-While, and Repeat-Until - for iteratation over a given set until a condition becomes false or true The process model could be used to automate the interaction with P2P services. There exist a working solution for automatic automatic invocation of services described in OWL- S, namely the OWL-S VM. C. Grounding The service grounding specifies the details on how to interact with the service. It enables service calls to be translated to messages for use by transport protocol languages. For example the grounding could be used to create mapping to WSDL[ Figure 5 ] or Universal Plug and Play (UPnP) Figure 5. Mapping between OWL-S and WSDL. 23

24 P2P SERVICE DESCRIPTION LANGUAGE 5 D. Other Ontologies Apart from the ontologies described above, OWL-S defines an ontology for the required resources. This ontology covers the description of physical resources, temporal resources and computational resources related to the services. In [23] is described a method for extending the monitoring capabilities of OWL-S through event based monitoring. An additional Event Ontology is introduced to achieve that and enable further capabilities for logging, performance measuring, evaluations of security parameters and execution progress tracking of services. OWL-S also creates a layer of abstraction on top of the various existing security standards, such as XML Signature, WS-Security, etc, as well as abstraction for security notations such as Authentication, Authorization, AccessControl, Confidentiality, Privacy, Anonymity, Negotiation, KeyDistribution, etc. This is achieved through several security related ontologies. These are namely the Credential Ontology, Security Mechanisms Ontology, Service Security Extensions Ontology, Agent Security Extensions Ontology, Privacy Ontology and Cryptographically Annotated Information Object Ontology. E. P2P Service Discovery Solutions for service discovery in a P2P network with semantic descriptions support are described in several papers( [20], [14], [21], [22], [18] and [1]). They all describe capability-based service discovery in systems, which doesn t contain a central registry. The described in [18] and [20] P2P service discovery mechanisms use OWL-S for service description and rely on the Gnutella P2P protocol. An actual implementation of platform independent and highly flexible service discovery system for ubiquitous peer-topeer networks is described in [1]. Again OWL-S is used for service description, WSDL is used for interface descriptions, and SOAP for remote invocation over a JXTA P2P infrastructure. The inference engine JTP (Java Theorem Prover) is used as reasoner for evaluating the service capabilities. The author of this paper concludes, that reasoning using an inference engine and semantic descriptions, allows powerful service discovery. F. Automated Service Invocation OWL-S supplies declarative, computer-interpretable API that includes the semantics of the arguments to be specified when executing service calls, and the semantics of data returned, when the services succeed or fail. Therefore services described in OWL-S could be automatically invocated in contrast to the traditional approach, where an agent is preprogrammed to perform calls to the particular service. An existing solution for automatic invocation is OWL-S VM. This implementation also takes into account privacy and authorization constraints that cryptographic techniques can implement. Peers using services implementing the OWL-S VM are able to maintain secure communication with other peers. SOAP security annotations are used to implement the actual message encryption or signing. [] V. ALTERNATIVES In the course of this research several others alternatives for service description were considered. These are WS-CDL, WSCI, WSMO, WSDL-S, PSDL, to name a few. Here are briefly presented two other languages, which were considered as main alternatives of OWL-S. A. WS-CDL WS-CDL describes P2P collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior, where ordered message exchanges result in accomplishing a common business goal. WS-CDL is targeted for composing interoperable P2P collaborations between any type of Web Service participant regardless of the supporting platform or programming model used by the implementation of the hosting environment[6]. In WS-CDL the collaboration between services takes place within a set of agreements about the ordering and constraint rules, through which messages are exchanged between participants. However it is widely accepted that the language has several drawbacks which makes it impractical. It is lacking separation between meta-model and syntax as well as comprehensive formal grounding[11]. As a further drawback it is difficult to write WS-CDL specifications that can be considered elegant or intuitive and specifications of even smaller interactions become rather lengthy[19]. Few implementations exist s.a. WS-CDL Eclipse and LTSA WS-Enginee but both were last updated in The last specification of the language is from 2005 and the W3C Choreography Working Group was closed in B. WSMO Web Service Modeling Ontology(WSMO) is to some extend similar to OWL-S. It is based on concepts from the Web Service Modeling Framework(WSMF) It defines four components: Ontologies - provide the terminology and formal semantics for describing the other elements in WSMO. Goals - consist of non-functional properties, imported ontologies, mediators used, post-conditions and effects. Web Services - provide a semantic description of Web services, including their functional and non-functional properties. The main descriptions are the capability and the interface. Mediators - represent connectors that resolve heterogeneity problems in order to enable interoperability between heterogeneous parties[16]. In contrast to OWL-S, at the moment software tools and libraries for WSMO are rare. VI. CONCLUSION Contemporary P2P networks accommodate their own proprietary set of protocols and provide limited or no capabilities for automated service discovery, selection, composition and invocation. OWL-S and other service description languages were examined as possible solution to address these issues. 24

26 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES 1 Cheating Detection in P2P-based Massive Multiplayer Online Games Georgi Hadshiyski Abstract In the recent years there has been a lot of development of Massive Multiplayer Online Games (MMOGs), which has shown to be very profitable and is now a billion-dollar industry. However because of the huge number of players, the normal client-server architecture approach doesn t scale well and it becomes increasingly hard to support the traffic and the computational power needed for the servers. A peer-to-peer approach to the game development solves those scalability issues. However this new approach is more cheating-prone because the server loses most of the control over the game state. Cheating in MMOGs is a serious issue because it can lead to player dissatisfactions and losses for the companies providing games. In this paper we review and compare different types of cheating, discuss why cheating is a problem and look into the ways to detect and prevent cheating in MMOGs. I. INTRODUCTION In the recent years there has been an enormous growth in the availability and the speed of the internet connection throughout the globe. This enabled the creation of massive multiplayer games where hundreds, thousands or even millions of people can play together inside a virtual game world. This new genre of computer games has been very successful and profitable. The game called World of Warcraft (WoW) now has more than 12 million subscribers worldwide and the company that created the game (Blizzard Entertainment) collects revenue in the billions each year. Although the development of Massive Multiplayer Online Games (or MMOGs) have shown to be quite profitable, the huge number of people playing simultaneously introduces a completely new set of problems. The main problem is the difficulty to support the game server. On one hand big server farms are needed just for the computation of the game state. This is very expensive and can be error-prone because it introduces a single point of failure. On the other hand the sheer number of people playing at the same time requires a huge amount of traffic going in and out of the server. This can also become expensive with the growth of the number of people simultaneously playing and can lead to game lag if the server can t support that many people. Game lag can be very frustrating to players and thus can lead to players dissatisfaction, resource misuses and profit losses. To tackle the scalability problems, a peer-to-peer approach can be used to decentralize the game. In the normal client-server approach all of the information is transferred between the server and the player and the game state is computed at the server. With the peer-to-peer approach however, most of the game traffic and game state computation goes between the players themselves, thus relieving the huge computational and bandwidth pressure on the server. That way the game can scale well even with million of people playing at the same time. This not only saves money on servers and bandwidth, but also increases the stability of the system. Although this approach solves the scalability issues in MMOGs quite well, it also introduces other problems. With this peer-to-peer decentralization the server loses most of the control it has over the correctness of the game state. With the computation of the next game state happening in the clients themselves, it becomes easy to manipulate and cheat inside the virtual game world. Cheating prevention is very important in the development of any multiplayer game. If there are cheaters in the game, the normal players can easily become frustrated with the gameplay and thus stop playing. This problem is even more serious in MMOGs because most of them operate by requiring a monthly subscription fee from the players. So the reduction of the number of players means direct profit losses. Cheating detection and prevention is extremely important to ensure commercial viability of P2P-based MMOGs. The rest of the paper is organised as follow: In the following Section of the paper we review a typical game architecture in order to better understand the relationships between the different entities both in centralized and decentralized MMOPGs. In Section 3 we discuss the possible implementation types of cheating detection architectures. After that we define and review different categories of cheating. By providing this classification we can better understand the cheating possibilities and then be able to tackle each of those problems separately. The fifth Section makes comparisons with similar work in this area done by other authors and in the end we make conclusions about the plausibility of cheating prevention in this kind of systems and the need for future work. II. GAME ARCHITECTURE A typical server-client oriented MMOG has the architecture shown on Fig.1. First, there is an authentication server which is responsible for account management.(a) Then there is a game server, which is responsible for maintaining the game state(b). All of the clients(c,d,e) are communicating directly with the game server after they have logged in. As seen in Fig.2, in a P2P-oriented MMOG architecture the management of the game state is outsourced to the client. The only centralized server left is the authentication server(a). The computational power and traffic needed for maintaining a login system is not that high and thus decentralization of account management is not needed. In this kind of architecture however there is no longer a need for a game server. Instead, 26

27 2 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES Fig. 1. Client-Server based game architecture server in order to create and maintain different constraints on the clients. Although easily implemented, this approach suffers from the scalability issues that come from the use of a server-client oriented architecture. With an increased number of players, the computational power needed for cheating detection rises and becomes very costly. Another possibility is to outsource the detection system to the client nodes. This approach is better suited for a peer-to-peer based game architecture because it enables good scalability. In this kind of cheating detection architecture the clients themselves are computing and verifying the validity of other players actions. The general idea is that although a single client node can t be trusted, a consensus between few random nodes can be trustworthy enough to provide good cheating prevention. A few not affiliated client nodes are chosen as monitoring nodes and are responsible for cheating detection for a certain number of players. If inconsistencies are detected, a majority vote is taken in order to determine the correct action. [1] discusses the problems stemming from P2P-based cheating detection and proposes a plausible implementation. The third option for cheating detection is a hybrid between previous two proposals. Such approaches try to minimize the cheating risks that stem from a decentralized detection system, while still maintaining low server computational and traffic requirements. Log Auditing[4] is one such proposal. This implementation outsources the game state to the client machines in order to maintain good scalability. However the cheating detection mechanism remains on the server. In order to reduce traffic and computational server requirements, the cheating detection is not computed in real time. Instead, the different game state changes are recorded and analysed at a later time. This reduces the computational power pressure because the server can use periods of time with lower demand in order to check for cheating. Although there is a delay between the cheat and the cheat detection, with good logging the game can easily be rolled back to revert the damage done by the cheater. Fig. 2. P2P-based game architecture a number of game clients (with enough resources) are chosen in order to maintain the game state(b). The game space is divided into subareas and each subarea has a responsible node. Other players(c,d) in this subarea are communicating with their responsible node instead of the server. Thus the local state of a sub-area is held at the responsible node and the whole game state can be seen as the sum of the game states of each of these subareas. III. CHEATING DETECTION ARCHITECTURES There are three possible approaches to implement cheating detection and prevention mechanisms. The first approach is to detect cheating on the server side. In this case the developing company provides a big server (or server farms) that makes sure no cheating is taking place. A possible approach [3] is the symbolic execution on the IV. TYPES OF CHEATING In order to better understand and defend against the different cheating possibilities, a classification of those cheating attempts is needed. In this Section we review the different categories of cheating according to the target of the attack. First we review cheats that are possible in multiplayer games in general. Every multiplayer game needs to deal with those cheating possibilities (or at least part of them) regardless of the types of architecture the game uses. After that we review cheating that stems from the use of a P2P-based architecture. A game client can exploit the fact that the system is decentralized to get an advantage over other player or players. Here we discuss what can be exploited and show examples of different cheating attempts. A. Categories of cheating Almost all multiplayer games suffer from cheating attempts regardless of the number of players and the type of game architecture. Although most games are not played for financial 2

28 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES 3 or other gain, but only for entertainment instead, there are still a lot of people that try to gain an illegal advantage over their fellow players. This can frustrate a lot of people and thus the game can lose its appeal. In this Subsection we are categorizing the types of cheating that can take place in multiplayer games in general, including P2P-Based MMOGs. To better illustrate the problems, there are examples for each of those categories. 1) Authentication Cheating: This is one of the most frequently seen security problems in network applications in general. In almost all multiplayer games the server provides some kind of an authentication system with which the player can identify himself (usually by providing user-name and password or something similar). A cheater can exploit weaknesses in this authentication system in order to gain access to somebody else s account and/or virtual assets. One possibility is to exploit the fact that a lot of players use weak passwords that can easily be cracked with a dictionary attack or in some cases even by a brute force approach. Another possibility is to exploit weaknesses in the implementation of the authentication system itself. For example some games use a regular telnet connection (where the username and the password are transmitted as plain text between the client and the authentication server). A cheater can snoop this connection in order to get access to the login information of another player s account. In some cases (if the server cannot authenticate himself to the client) a hacker can get access to hundreds of accounts by simulating the authentication server. In this case the clients are unwillingly sending their account information to the cheater instead of the real authentication system. Although this kind of cheating can never be completely prevented due to the possibility of human error, most of this kind of cheating attempts can be evaded through good authentication server design. The server needs to authenticate itself to the client to prevent server impersonation and all traffic between the client and the server (especially the password) needs to be encrypted - this way we can prevent account information snooping. In addition the server can require the players to register with a longer and more complicated password (for example containing at least one number and at least one special character). Thus we can prevent password guessing success with high probability. 2) Client Modification Cheating: This cheating possibility arises when too much trust is put into the client. A cheater can modify his game client or machine in order to perform illegal actions or get access to information he is not supposed to. For example there are the so called "wall hacks" in the game "Counter Strike"[cs]. In this case the cheater exploits the fact that his client receives information about the position of all other players regardless of who the player can actually see in the game. With a slight client modification the cheater can see all enemies (through the walls), although he is not supposed to. This problem comes from the fact that the server trusts every client with all player positions instead of only those visible from the player s current position. The cheater can then exploit this knowledge to gain advantage over the other players. There are a few ways to prevent modification cheating. The easiest way is to restrain the trust put on the client. For most online games the actions of the player and the results of those actions can be checked in the server against the current game state to see if they are valid. With peer-to-peer MMOGs however this becomes more complicated because a lot of the game state management is outsourced to the clients themselves - usually through the use of responsible nodes or a similar approach. This problem can be solved by the use of monitoring nodes that make sure all the players are playing fair. Another way to prevent this type of cheating is to introduce additional software that prevents any client modification. Every client needs to install this additional software before playing the game. If a cheater then attempts to modify his game client or use some kind of helping tools, this additional protection software can detect and prevent that. Although this approach has already been implemented and shows promising results, this piece of software is still on the client machine so it is theoretically possible to hack it as well. 3) Outside Information Cheating: One of the biggest problems in multiplayer games is the fact that the server cannot refrain a client from accessing information outside the game architecture. In this type of cheating a player can gain advantage over the other clients by using access to information outside of the game. For example, a chess player can use an advanced computer program to calculate his next move. This way his opponent stands no chance since even the best chess players often lose against those advanced chess programs. That way the cheater gains a huge advantage by using outside information. For another example let s look at a four-person game of poker. If three of the players are talking to each other over the telephone and giving each other information about what cards they have, then the forth person will definitely lose his money sooner or later no matter how skilled he is, or how much luck he has. In this case the three cheaters are exploiting an outside line of communication to gain an advantage over the unsuspecting forth player and thus win the game. There is no plausible way to completely prevent this type of cheating without invading user privacy. The only way to reduce the risk of this type of cheating is to design the game in a way to prevent it. For example, lets consider again the four-person poker game. If the players in a game are chosen randomly then it will be hard for three cheaters to collaborate against the forth, because the odds are that they are all going to play in different games (on different tables). This kind of solution is however game specific and has its limitations both in terms of success and in terms of reduction of game flexibility. 4) Server Attack Cheating: In some rare cases a hacker can gain direct access to the server of a game if it is not well protected. One possibility is a direct attack. Although rare, in some cases it is possible for a cheater to gain access to the server by exploiting a security weakness on the target machine. Another, more common possibility, happens when the cheater has direct physical access to the server - for example 28

29 4 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES if he is working for the company that makes the game. If this happens the cheater can not only gain an advantage, but basically decide everything in the game. In games with a client-server architecture the hacker can directly change the game state to do whatever he wants. Even in very decentralized peer-to-peer games where the current game state is held mostly at the clients, the cheater can still change the game state because the server always has the authoritative say. Server attacks can be prevented through good server security design. If there are no major security flaws in the server then an outside attacker will not be able to gain unrestricted access. Good company policies against inside cheating can prevent server attacks on the internal level as well. With peer-to-peer approaches this problem becomes even less dangerous, because most of the work is outsourced to the clients. The server itself has less functionality and is therefore less bug-prone because of the lower code complexity. 5) Client Attack Cheating: A cheater can directly attack another player s computer in order to gain advantage in the game. Although rare, sometimes a hacker can use vulnerabilities on a target client machine to gain access to it. In most of the cases the hacker uses a trojan horse or a worm in order to control other people s computers. With this access the cheater has complete control over the other player and can easily beat him in the game. Another possibility is to attempt a Denial of Service attack. This is especially dangerous in peer-to-peer oriented architectures. The cheater can flood the enemy player with packets, thus slowing down his connection. This way the cheater gains an advantage because he can stop the enemy player in key moments or at least slow down his reactions because of the slower connection. A special case of client attacking is the use of social engineering methods to obtain certain information about another player. (or to achieve a certain goal). For example the cheater can ask a victim to see one of his items and then after that not return it. Or in some extreme cases even obtain the victim s login and password by sending an pretending to work at the company that created the game. In the normal client-server architecture this is not a big problem, because most clients are secure enough for these types of attacks. The cheater doesn t have direct access to the target computer and unless the target has been somehow infected with malicious software, the chances of attack success are relatively small. This problem however becomes a lot more complicated with peer-to-peer MMOGs. This approach introduces the possibility of responsible and monitoring nodes sending misleading packets to each other, to other clients or to the server. There isn t much to be done about the special case of social engineering cheating attempts. The risk can be reduced by warning all players about that possibility. However in the end human error is always a factor, so a complete prevention of social engineering attacks is not plausible. 6) Game Architecture Exploitation: In some games a cheater can exploit general problems with the implementation of a game. A player can use (known or unknown to the developer) game features to gain an advantage over the rest of the players. For example, if there is a bug in a certain game that allows the player to become immortal in very specific circumstances, then a cheater can exploit that bug and gain unintended by the developers advantage against the other players. Some of those game architecture exploitation cheats are not even bugs, but actually exist because of bad game design. For example the ranking system of some multiplayer games is calculated according to number of victories only. Two cheaters can then collaborate to cheat the system by starting and immediately ending hundreds of games. By taking turns they can both record hundreds of victory points and thus go to the top of the ranking lists without playing a single game. That way the cheater is not exploiting a bug in the program, but is taking an advantage of the badly designed ranking system. This type of cheating can be circumvent by better software quality control. Better project management and more testing can reduce the chances of bugs in the game. Better game design can prevent unintended abuse of the available game features. B. Cheating in P2P based MMOGs It is a lot more complicated to prevent cheating that stems directly from the use of a peer-to-peer game architecture. The main problem is that with this approach the server loses most of the information about the moves of the players. Even if the server makes extensive checking of the validity of a certain move, cheating is still possible because the server trusts the information coming from a certain responsible node. This information can contain a valid move but that doesn t make sure that this was the actual move the player made. In this Subsection of the paper we review detection and prevention strategies and discuss their limitations in terms of success and performance. 1) Timing Cheating: In a MMOGs with a peer-to-peer architecture most of the information transfer happens directly between the players. However there is always a time delay between the actions of the different players. Thus a cheater can try to exploit the delay in order to gain an unfair advantage against the others. The most famous example of timing exploitation is the Look-Ahead cheating. A cheater can try to delay his actions until he knows what his opponents are going to play. Thus the attacker can decide his next move by using this information and thus gain an unfair advantage against the rest of the players. To prevent Look-Ahead cheating the Lock-Step protocol can be implemented. The way this protocol works is to require from all players to send only the hash of the move they are going to make. The responsible node does this as well. In the end of the timeslot the actual moves are sent and the hash-codes are recalculated and compared. That way the responsible node knows only the hashes of the other player s moves when generating its own hash. When the actual moves become known to the responsible node it is too late for it to change its move, because the hash was already generated and 29

30 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES 5 sent. The use of monitoring nodes can prevent the responsible node from completely dropping certain packets. 2) Authority Exploitation: In most peer-to-peer games a certain number of nodes have more responsibility than the others. Those responsible nodes usually take care of a number of child nodes by coordinating them. If a responsible node is a cheater he can try to exploit this authority he has over all child nodes. For example, the cheater can delay or completely drop certain packets received from a child node. On the other hand it is possible to fabricate completely certain information in order to lie to the rest of the nodes about what a certain victim player did. In most cases those responsible nodes need to report to the server about the game state. A cheater can exploit this authority in order to lie to the server about what somebody s actions were. To prevent authority exploitation, we can use a certain number of nodes, which check whether a responsible node is attempting to cheat or not. These nodes (also called monitoring nodes) can either be chosen from the rest of the responsible nodes, or more common directly from the normal players. The player attempting to make a move sends the information both to his responsible node and to the monitoring nodes assigned to it. That way if the responsible node attempts to modify, delay or completely drop certain packets, the rest of the monitoring nodes can detect and prevent that by making a majority vote and executing the action regardless of what the responsible node did. However this approach introduces traffic overhead for all players and especially for the monitoring nodes. Big computation overhead is also possible if the monitoring nodes need to check the validity of the move. 3) Lack of Central Control Exploitation: Even if the cheater is not a responsible node but a regular node instead, he can still attempt to exploit the decentralization of the game state management. For example, the cheater can try making an illegal move. On normal client-server architectures the validity of the move can be calculated on the server. In a peer-to-peer system however the resources on the responsible node are somewhat limited, so a complete calculation of the possibility of each move for every child node becomes implausible. This becomes even more problematic if there are also monitoring nodes involved, because each of them need to calculate the validity as well. To fight against this kind of cheating we need to make sure that the moves attempted by all players are actually valid. This can be done on the server, however by doing that we lose the scalability advantage that a peer-to-peer system offers. A possible way to deal with this problem is to only log all the moves and make those checks later when the load on the server is smaller. If cheating is detected then the server can roll-back to the last secure point of the game. This solution however introduces a delay between the cheating attempt and the checking and thus the rolling back can be frustrating to players that didn t cheat but needed to lose hours of play anyway because of somebody else. A better possibility is to make those checks at the responsible (and the monitoring) nodes. Although this introduces a significant performance overhead for those nodes that make the validity checking, this solution is still a lot more scalable than using a big server. A middle-ground solution is also possible, where only the responsible node calculates the validity of the move. The server then checks a random limited number of the moves to make sure that the responsible node is not lying. Although this solution has limited ability to prevent cheating it is a good trade-off between cheating prevention and performance. 4) Collusion Cheating: A few cheaters can collaborate to exploit a security weakness, which is only possible when the cheater is not acting alone. Most peer-to-peer architectures depend on some kind of monitoring nodes, which make sure that neither the responsible node, nor the player himself is falsifying information. They can then take a vote in order to make sure that cheating attempts are prevented. However if enough monitoring nodes are actually on the cheater side then they can win the majority vote and thus go around the cheating prevention system. Collusion cheating can never be completely prevented without complete checks by the server, which would make the use of peer-to-peer architecture meaningless. However the chances of collusion cheating success can be reduced with good game architecture design. For example if the monitoring nodes are chosen randomly (instead of choosing only people located in the surrounding area) it will be a lot harder for the cheaters to succeed having the majority of the monitoring nodes. Increased number of monitoring nodes makes collusion cheating even less probable, although it introduces considerate overhead both for the monitoring nodes and for the normal players. In addition if the monitoring nodes are changed frequently we can make sure that even if the cheaters have the luck to gain the majority vote, that they will not have the control for a long period of time. Crosschecking between the different groups of monitoring nodes can also detect cheating attempts, though it introduces significant overhead as well. V. RELATED WORK The paper "A Systematic Classification of Cheating in Online Games" by Jeff Yann and Brian Randell offers a classification of the different cheating approaches that bares similarities to the ones presented in this paper. The authors classify all cheating attempts in multiplayer games into fifteen categories and review each of them. Although the paper doesn t concentrate exactly on peer-to-peer architecture approaches, the information presented there is useful to better understand the different types of cheats we see in online games. Takoto Izaiku and his team concentrate more on cheat prevention in peer-to-peer games in the paper "Cheat Detection for MMORPG on P2P Environments" that stem directly from 30

31 6 CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES the decentralization of the system. In the paper the authors propose a method for cheat detection and prevention in Massive Online RPG games that uses strategies similar to the ones proposed in this paper. In the paper "Server-side Verification of Client Behavior in Online Games" the author Darrell Bethea and his colleagues propose a method for validity checking in normal server-client frameworks. Although the work doesn t concentrate on the peer-to-peer approach, the paper proposes a good system for validity checking that can be restructured to work with some peer-to-peer MMOGs. VI. CONCLUSION Although the prevention of cheating in the peer-to-peer architecture approach to the development of MMOGs is a lot more complicated than in the normal client-server approaches, it still provides the traffic scalability needed for the huge number of people playing the game simultaneously. As discussed in the paper most of the problems that arise from the decentralization of the system are quite manageable. Although there probably are more undiscovered ways to attack this kind of systems, most of the cheaters don t have the expertise to attempt something that complicated. On the other hand there is also a number of administrators that watch for anomalies in the game state, so a person suddenly gaining enormous amounts of something valuable can easily be spotted and stopped. This, together with the ease with which the game can be rolled-back to a previous stable state, makes the problem manageable. Thus at the moment the advantages of using a peer-to-peer architecture outweigh the potential risks of revenue losses due to cheating. However, this kind of games are becoming more and more popular and the number of people playing is increasing. Thus in the future we will also see an increase in the number of cheating attempts and the complexity of the cheating approaches. The increase of the number of people playing will also make it harder for the administrators to manually detect cheating attempts. However this increase in player numbers will also make the peer-to-peer approaches even more valuable because of the scalability issues with the normal client-server architectures. Because of the importance of cheating prevention more work in this field will be needed in order to ensure the fair gameplay in the future. REFERENCES [1] Takato Izaiku and Shinya Yamamoto and Yoshihiro Murata and Naoki Shibata and Keiichi Yasumoto and Minoru Ito. Cheat detection for MMORPG on P2P Environments. ACM Workshop on Network and System Support for Games, [2] Jeff Yan and Brian Randell A Systematic Classification of Cheating in Online Games. ACM Workshop on Network and System Support for Games, [3] Darrell Bethea and Robert Cochran and Michael Reiter Server-side Verification of Client Behavior in Online Games. University of North Carolina at Chapel Hill, [4] Patric Kabus and Wesley W. Terpstra and Mariano Cilia and Alejandro P. Buchmann Addressing Cheating in Distributed MMOGs. Darmstadt University of Technology, Germany,

54 TRAFFIC ANALYSIS OF P2P APPLICATIONS 1 Traffic Analysis of p2p Applications The An Binh Nguyen Abstract The popularity of P2P applications is continued to grow. Parallel to this growth, P2P protocols are getting more complex. Nowadays the problem of Quality of Service is often in question of P2P research field. A peer node has to store data, receives queries from other peer nodes, and distributes its content for other peers. Such processing peer node can generate bulky traffic to the network. Also for each node we have to reserve enough resources for this peer node to function. P2P is not only used in many legal applications, but also finds its place for illegal doing e.g., DDoS attack. The need of P2P application analysis and traffic monitoring therefore have become mandatory. P2P traffic needs to be analyzed in order to optimize load of P2P traffic. When P2P node consumes too much resources, we need to monitor P2P traffic and detect this problem in runtime, in order to perform load balancing in right time and prevent corruption of P2P networks. Monitoring P2P traffic also helps prevent malicious attempt, for instance DDoS attack based on P2P. There have been many works for P2P traffic analysis. This paper considers some of them, describes their approaches and tries to address advantages and disadvantages of each method. We analyzed the approaches and believe that each approach can be useful for a particular interest. Also machine learning would be more important in the future for P2P traffic analysis. Monitoring P2P traffic is still a challenge due to dynamic properties of P2P networks, a great number of new P2P applications and the big scale of the network. Monitoring of P2P is often decentralized. We tend to believe hybrid approach (combination of both centralized and decentralized) would be a good solution for P2P monitoring, which compromise advantages of both centralized and distributed monitoring scheme. I. INTRODUCTION P2P is a network architecture, where a group of computer users can communicate with each other and directly access files from other s hard drive in a decentralized manner. P2P introduces some advantages compared to other classic architectures such as decentralized organizing systems, high scalability. Therefore P2P has been widely used in many applications for file sharing, content distribution (BitTorrent, EMule etc.), chat, Voice over Internet protocol (VoIP) e.g. Skype and also for malicious attempts, for instance malware distribution (botnet) or DDoS. The growth of P2P implies a lot of consequences. Basher et al. [4] analyzed network traffic, which were generated from classic web applications and from P2P applications. They found out that compared to web traffic, P2P traffic contributes many large-sized and many small-sized packets. P2P flows also last longer, inter-arrival time between two P2P flows is longer than web traffic, packet size of P2P is often larger [1]. These findings indicate, that a large amount of network traffic is contributed by P2P traffic. This result is confirmed in [2], [8], [10], [14], [18]. Due to decentralized manner, P2P might be deployed not only to share illegal file contents, but also to attempt DDoS attacks [], [22]. Because of its complexity and widely used, it has become mandatory to analyze P2P traffic. Torres et al. [19] discussed three reasons based on domain knowledge, why it is necessary for P2P traffic analysis. First of all for network operators, a large distributed amount of traffic from P2P may reduce the performance of the whole network, which is why network operators want to analyze and monitor behaviors of such applications, in order to adjust network under different circumstances.. Second of all, for P2P application designers, it s important for them to evaluate their implementation and do improvements, so comes the role of P2P traffic analysis. For end users it might be interesting to control incoming and outgoing traffic of their systems, to be able to detect suspicious attempts of P2P applications and also be able to balance load in their local machine. In summary the quality of service, load balancing, P2P based attack prevention and detection encourage the need of P2P analysis and monitoring. In the early day, monitoring was often done in centralized manner, where a centralized monitoring entity exists to monitor the network. The scale of monitoring has now become larger. For a big scale P2P network, a centralized scheme is inefficient. Usually a decentralized or hybrid monitoring scheme is preferred in P2P applications. Some approaches were introduced in [12] [20] [1]. To detect particular behaviors of P2P networks, particular metrics should be considered. Some of metrics can be named such as: flow size, flow inter-arrival time, duration, number of destination ports, traffic volume etc. In this paper we will see, how these metrics are used in research works. There have been many contributions in analyzing P2P traffic. In this paper some methods will be considered and reviewed to see the developments of P2P traffic analysis methods and their future. In order to analyze P2P traffic the first thing needs to be done is distinguish P2P traffic from the other traffic. The first generation of P2P applications was not so complex, they often used default ports and default protocols, thus it was able to look into payload to determine P2P traffic. This so-called payload based technique was mentioned in [18] [13] [14] [2]. Through time P2P application got more complex. They can even disguise themselves as usual traffic by randomizing port or use default ports of other traffic. P2P applications can also encrypt their transmitted content, so a fully payload-based technique is not always possible. Using payload-based technique we can detect known P2P traffic, but to discover unknown P2P traffic and overcome many disadvantages of payload-based non-payload-based techniques are necessary. Non-payload techniques or heuristic based techniques are based on common behavior patterns to identify P2P traffic due to nature of P2P. Common characteristics of P2P traffic are, for instance the use of both TCP/UDP, same number of distinct ports and destinations connect to host [13], [14], peer node acts in both roles as client and server [6]. Other approach based on machine learning to learn the behavior of P2P traffic is applied in [8], but it is still in development and in 54

55 2 TRAFFIC ANALYSIS OF P2P APPLICATIONS some cases inefficient. But use of machine learning to extract traffic patterns of P2P can be further improved and would get more efficient in the future. The rest of the paper is structured as follows. The second section will summarize analysis methods. This section contains of three main parts, how P2P traffic can be identified, how can we monitor P2P traffic and how P2P traffic were analyzed in research papers. The third section will discuss the summaries from this paper. The last section is the conclusion. A. P2P Traffic Identification II. ANALYSIS METHODS Although P2P applications are heterogeneous in term of specification of their protocols, they still have many things in common. The nature of P2P is equality among peers. In file sharing P2P applications, each peer gets a part of wanted data from other peers, and offers a part of this data for other peers as well. It implies the roles of server and client. A peer must therefore satisfy the function of both roles. This nature indicates some common characteristics of P2P applications. These characteristics can be made used for identifying P2P traffic, especially when it comes to unknown P2P protocols. Some of the most used characteristics of P2P traffic can be listed as followed: C1: Nowadays P2P applications use both TCP/UDP to exchange control message and data. UDP is often used for queries, control messages or responses, while TCP is often used for transmission. Because of that IP pairs which use both TCP/UDP should be the first candidate of P2P traffic network. This characteristic is widely used in almost every heuristic based P2P identifying methods. C2: In many P2P applications the number of distinct ports is equal to the number of distinct destinations, since peer node often choses an arbitrary port to connect to other nodes, which implies another heuristic for identifying P2P flows. C3: Many P2P applications can disguise their used ports as default ports from other web traffic. Still the difference is web traffic tends to open many parallel connections to host. On the contrary P2P data transmission consists of many consecutive connections, there is at most one connection at one time. Based on this heuristic it is able to separate disguised P2P from web traffic C4: P2P is in major used for file sharing, P2P traffic often contains many large sized flow or long duration flow. C5: In P2P file sharing, the file is divided in many smaller chunks. Therefore if source and destination peers use fixed ports for data transfer, it should exist many identical flows with similar flow identities <SourceIp, SourcePort, DestIp, DestPort, protocol, etc.> C6: A set of classic P2P applications often use fixed ports to transfer data. This heuristic is despite of its simplicity quite useful to identify the well-known P2P traffic in the first step. Besides the use of P2P for file sharing, chat, P2P is also used for streaming data. The characteristics of these kinds are quite different to P2P file sharing applications, especially for overlay characteristics. These kinds are for the time being outside scope of this paper, and should be considered in future papers. For an overview of overlay characteristics of P2P streaming applications refer in [21]. In order to identify P2P traffic, two main approaches are possible. The paper will introduce 6 methods which will be called MI1, MI1, MI2 to MI5 (stand for Method for Identification). Methods can be categorized as payload-based, non-payload-based (or heuristic-based) and machine learning technique. Payload-based technique is applied to identify traffic, where it is possible to look into the content of network traffic. Non-payload-based technique or heuristic-based technique makes use of common characteristic to identify P2P traffic. A classification of introduced methods and their category can be found in Figure 1. MI1 and MI1 are payload-based technique. MI2 to MI4 are heuristic-based technique. The last introduced method MI5 is machine learning technique. For further details of each method, refer in next coming text. MI1: Karagiannis and Broido [13] proposed a payloadbased method to identify P2P traffic, using C6. The method consists of three steps. The first step is to compare source port and destination port of a flow to a table of well-known P2P applications. This step is quite common since it is quite simple to perform this step, and these well-known P2P applications are often well-documented. With this all known P2P applications with fixed ports are identified. The second step is to look into the payload of each packet in a flow and compare these strings against a table of known protocols. In case of a match we can identify the flow to the corresponding known P2P applications. The third step considers the host IPs which were identified as P2P flows from step two, and classifies all flows that contains one of these identified IP addresses as possible P2P. In this step all known services such as , DNS, FTP are excluded to reduce the false positive rate. MI1 is simple but exposes many drawbacks. MI1 can only identify well-know P2P applications, unknown P2P traffic are still not to be identified. Payload matching is still difficult since the limit size of capturing packets doesn t allow to fully look into payload. In case applications encrypt the payload, it will be impossible to look into the true content. Another problem of this approach is privacy issue. There is privacy law, which often forbids researcher to look into real content of network traffic. MI1 : Technique of MI1 was improved in [14]. MI1 holds the first two steps as in MI1 with two additional steps to improve step three. In MI1 step three will consider UDP flows and step four will consider TCP flows. As in MI1, in step three all source and destination IPs of UDP flow will be hashed in a table, and all the flows, which contain IP address from this table will be considered as possible. Step four does the same thing as in step three for all TCP flows, to retrieve the second IP address tables. For these two steps the exclusion of web traffic as in MI1 still remains to reduce the false rate. As for advantage MI1 uses not only C6 but also 55

56 TRAFFIC ANALYSIS OF P2P APPLICATIONS 3 Fig. 1. Classification of P2P Identification Methods C1. Step three and step four help to partially overcome limit packet size problem and a better upper bound for identified P2P traffic. Still for general the upper bound of these payload-based technique is still too great, and fully overcome the problem of encryption is still far from possible. MI2: As seen from these two payload-based techniques, there are still many drawbacks with such techniques. Fully looking into a packet is due to privacy issue usually forbidden, and the need of identifying new P2P traffic became greater. Therefore the creation of non-payloadbased techniques was necessary. In [13] the authors, besides payload-based approach, also contributed a nonpayload based technique (MI2) of identifying P2P traffic, using heuristics based on characteristics C1 and C2. Based on C1 all IP sources and destinations which concurrently use both TCP/UPD during a time t will be considered as P2P. All well-known other services like NETBIOS, IRC, DNS, which have similar behaviors will be excluded. For C2 all flows which have the difference of numbers of distinct connected IPs and distinct used ports larger than a threshold (in this paper 10) will considered P2P flows. This technique compared to MI1 and MI1 provides a new way to efficiently identify new kind of P2P traffic. But still the false positive problem is an opened question. The first heuristic of this method depends on viewed time t, the ratio of UPD and TCP in a P2P application may vary. For the second heuristic if threshold is chosen too big or too small, it can affect the result, thus it may still generate false determination of non-p2p traffic. MI3: Constantinous and Mavrommatis [6] used the same idea as MI2, which is based mainly on C1 and C2 to discover new P2P traffic ports. Their implementation is a little different to MI2. MI3 introduced term diameter. Diameter is used to measure the interaction rate between peers. Each host is assigned a level, the level means the time when host receives first connection from another, or first time to be touched. A host is assigned one level greater than its parents. For the classification, the number of hosts that acts in both roles server and client at a port should exceed a threshold thus satisfies C1, network diameter should greater than two, and number of host, which are present in network should also exceed a threshold. Advantages and disadvantages of MI3 is similar to MI2, since it uses the same characteristics and quite the same idea. MI4: Perenyi et al. [18] used all mentioned characteristics to identify P2P traffic. In preparation MI4 tries to exclude all web traffic that have the same behaviors with TCP/UPD based on their default ports. The first step is identify flow with characteristic C1. The second step tries to refine separation from web traffic and P2P traffic which disguise as web traffic using C3. Some of flows can be identified using default ports(c6). C5 is then applied to identify identical flows which might belong to P2P applications. The next step is empirical experience of the authors. They found out, that if an IP uses TCP/UPD port more than 5 times in a period time, this IP,port indicate P2P traffic. The last step chooses flow where flow size is larger than 1MB or flow duration is longer than 10 minutes. Advantage of this technique, like other heuristicbased technique is to be able to discover unknown traffic, but also introduces less accurate results, however because of its consistencies, it is still suitable for P2P traffic analysis. MI5: Another approach should be mentioned is machine learning based technique. An example of such approach 56

57 4 TRAFFIC ANALYSIS OF P2P APPLICATIONS TABLE I CHARACTERISTICS VERSUS P2P IDENTIFICATION METHODS Method Identification MI1/MI1 MI2 x x MI3 x x Characteristics C1 C2 C3 C4 C5 C6 x MI4 x x x x x x MI5 x can be found in [8]. MI5 uses clustering technique, defines cluster with interesting metrics, such as flow size etc. MI5 only needs statistic of unidirectional flow. With the help of training data, which were achieved from both payload-based and non-payload-based techniques. For each flow it can determine to which class (P2P, or other web traffic) the flow should belong. MI5 is also useful to learn the new behaviors of P2P traffic, as well as classify them. MI5 is still in development, since MI5 concentrated mainly on TCP and lets UDP out of concern. Through empirical experiments MI5 works better for better for server-to-client statistic. The result from server-toclient direction often has higher accuracy. In the future work, the authors intended to extend their technique, so that it will be able to classify UDP traffic and also work better with client-to-server direction. For the end of this section, a table for an overview which characteristics were used by which methods, is provided in Table I. For recall MI1 and MI1 are payload-based technique. They used the port-based characteristic and content of the traffic to identify P2P traffic. C1 and C2 are the most common used characteristics in heuristic-based methods. The machine learning based method MI5 often uses the statistic of large flow size to identify P2P. B. P2P Traffic Monitoring Monitoring is an important task not only for P2P traffic analysis, but also for administration purpose. Monitoring scheme in general can be classified in three categories, centralized scheme, decentralized scheme (distributed scheme) and hybrid scheme [16]. Normally for monitoring purpose, monitoring agent is needed. The centralized monitoring scheme results accurate information. But centralized scheme is often not scalable, since a central entity has to take responsible to monitor the whole network. Decentralized or distributed scheme can overcome the problem of scalability, but introduces other problems. In such scheme peers are responsible for monitoring each other. This can be a problem, if one peer provides false information, it can affects the global conclusion for the state of the network. Also a peer can attempt malicious doing, such as injecting malicious code etc. A better solution for monitoring problem would be a hybrid scheme, where we should use centralized scheme if possible, and decentralized if not. The combination of two major monitoring schemes might overcome disadvantages of each of them. The current state of P2P monitoring is still not perfect. The risk of false positives is still high. Use of arbitrary address in P2P applications makes it difficult to identify peer and cause misidentification, especially in case P2P is behind NAT. In case P2P applications use tracker like BitTorrent, the behaviors of monitoring agent (crawl and monitor all) is likely to be identified as attempt of denial of service attack and would be blocked. The risk of exposing P2P agent is therefore high, which implies task for designing such monitoring agents, is to assign these agents multiple IP addresses. The monitoring scheme in [5] can be classified as a hybrid scheme. The authors proposed monitoring approach for chord based protocols. In this approach the overlay of P2P network is divided in many subparts. Each subpart is monitored and measured as desire. Data are sent back to a central collecting point. One distributed monitoring scheme was P2PML, which can be deployed not only in P2P monitoring, but also in monitoring web services as well. This idea of distributed monitoring was introduced in [1]. The monitor system itself is a P2P network that coexists with monitored P2P network. Each peer can be member of monitoring and monitored network. The system uses a declaration subscription language, P2PML to describe monitoring tasks. Monitoring tasks are described using P2PML, a description language based on XML. Thus is easy to implement and adapt, since XML is a widely-used standard. Peers in monitored P2P system observe activities, publish information stream. A peer may host alerter, which intercepts inbound and outbound and detects changes, stream processor which does operation on streams, publisher which publishes stream generated from stream operation. When a user is interested in a specific monitoring task, he can subscribe to a channel, which will publish the stream. The filter bases on Atomic Event Set Algorithm and YFilter Algorithm to match pattern. By defining condition the desired information can be filtered. A subscriber, who is interested in a part of network can subscribe to a channel, which was published by monitoring peers. Although this idea is interesting for monitoring task not only for P2P systems, but also for web services call, it still has drawbacks. Alerters have to be implemented for each type of monitored system. Furthermore for analysis purpose the use of another P2P system as monitoring system may introduce confusion. As stated in introduction for P2P monitoring task, distributed and hybrid schemes are often applied. Other distributed monitoring scheme can be found in [9], [11], [15] For the end of this section, a list of common used metrics are provided. In section of traffic analysis we will see, how these metrics are differently considered in each different work. Traffic volume or throughput (traff_vol): The whole P2P traffic volume, which was captured. flow size (flow_size): Size of P2P flow flow duration (flow_duration): Time begins when one P2P flow started, until this flow ends. flow inter-arrival time (flow_inter_arr_time): Time between each arrival of two consecutive P2P flows. packet size (pkt_size): size of a packet, which belongs to P2P traffic. Live connection or number of TCP connections from a host (live_conn): Number of TCP connections, which belong to P2P traffic in a period of time Geographical distribution of peer (geo_distr): how peers 5

58 TRAFFIC ANALYSIS OF P2P APPLICATIONS 5 are geographically distributed. Bit rate (bit_rate) P2P population or number of peers (peers_popu): Number of P2P peers. Popularity distribution (how traffic is distributed among IP address) (poplr_distr): the number of distinct IP addresses among peers. C. P2P Traffic Analysis Traffic analysis generally consists of identification, choice of interesting metrics (filter of them from the identified traffic) and the analysis result based on the metrics. In the following the methods will be called as MA (method of analysis) MA1: Karagiannis et al. [14] used MI1 to identify P2P traffics and collect P2P traffic traces. The traces were collected by monitoring traffic of two commercial backbone links San Jose - Seattle in US. The authors collected the traces and learned P2P traffic characteristics, by measuring the following metrics: bitrate of P2P traffic, population of P2P traffic (number of distinct IP mapped to Autonomous systems), traffic volumes of P2P traffic relative to all traffic columns. With their results the authors also concluded that P2P trend changed but never died. Since MI1 is payload-based technique, as described above, it can not identify all P2P traffic, but the identifiable P2P protocols were in time the most traffic contributed. This means for the purpose of the paper, the method was sufficient. MA2: Louis et al. [1] contributed an early analysis work in field of P2P traffic analysis. MA2 used only characteristic C6, compared flow ports with famous applications default ports, to identify P2P traffic. Although it was restricted only to some famous P2P applications, but these application in time contributed most P2P traffic to the Internet. Furthermore MA2 only wanted to analyze the most famous protocols. MA2 captures all TCP packets between BAS 1 and the IP Backbone. MA2 analyzed and also compared some famous P2P protocols such as edonkey, BitTorrent, FastTrack, WinMX. These protocols are compared with regards to the following metrics: traffic volumes, connection duration, geographical distribution of peers, termination of connections, whether the connection ended normally, connectivity of peers (number of local peers and non-local peers) and from this result described the different behaviors of each application type. MA1 still had many restrictions, w.r.t. P2P identification. With the growth of P2P network nowadays, MA2 is not really efficient anymore. Nevertheless MA2 gave us many interesting behaviors of P2P traffic in early time, which is also contribution for P2P traffic analysis. MA3: Baset et al. analyzed the most famous P2P VOIP Skype in [3]. Since Skype is not open-sourced, its protocol is not clear. Skype s used port can be altered, so it is impossible to use approach like in MA1 or in MA2. Instead of monitoring to capture traffic of skype, 1 Broadband Access Server MA3 uses shared library and system call redirection technique to overload shared library functions. With the overloaded share functions, when Skype client calls a function from shared library (this is applied for Linux OS) the called function can redirect the input parameter to output. Thus it is able to get interesting information from Client behaviors, targeted modify calls and then analyze interesting results/behaviors from called parameters. In this work the authors are interested in protocol aspect of Skype client. One common viewed metric is also analyzed here, namely geographical distribution. MA3 is an efficient approach if using Linux as OS for analysis purpose, since the manipulation of called share library is nature part of Linux OS. But with approach like MA3, other measurements like flow size, flow duration etc. will not be considered. Only behaviors of peer client is analyzed. The characteristic of overlay network in this case is missed. MA4: In [18] data for analysis were collected from two Cisco routers at one large Internet provider in Hungary. MA4 used NetFlow to collect traffic flow information and also some packet-level information. The method MI4 was applied to identify P2P traffic. MA4 focused on comparison between P2P and non-p2p traffics. Therefore following metrics were considered: P2P traffic volume compared to total traffic, number of P2P users/total active users, and in order to reduce error MA4 associated an individual IP address to a user, flow size and flow duration, packet size, thus to analyze the properties of P2P traffic in data transmission and the differences between P2P protocols, and popularity distribution. MA4 used MI4 which is easy to implement, like other heuristicbased techniques, MI4 might introduce false positives. The author proposed a solution by assigning individual IP address to a user, which might reduce accuracy. But for interest of Internet Provider, and the whole purpose for comparison P2P and non-p2p traffic, this less-accuracy can be tolerated. MA5: Basher et al. [4] dedicated their work to compare P2P traffic and network traffic. The traces were collected by using lindump, which monitors ports and captures all TCP/IP packets from the commercial Internet link of the university Calgary. For identification of P2P flows/applications MA5 uses port-based and payload signature-based technique. MA5 considered flow size, flow duration, flow inter-arrival time, maximum number of TCP flows from a single host, transfer volume and geographic distribution. As other methods the less-accuracy problem of signature-based technique is not a non-tolerated problem. The traces in MA5 were not collected continuously, thus might not cover all abnormal behaviors of traffics, but either way the most common characteristics of P2P are already covered. MA6: Torres et al. [19] focused on analyzing and finding undesirable behavior from P2P traffic. All TCP and UDP traces were collected by using Tstat at a MiniPoP router, where all traffics go into Internet backbone. Tstat is a 58

59 6 TRAFFIC ANALYSIS OF P2P APPLICATIONS TABLE II COMMON USED METRICS VERSUS ANALYSIS METHODS MA1 MA2 MA3 MA4 MA5 MA6 traff_vol x x x x x flow_size x x flow_duration x x x flow_inter_arr_time x x pkt_size x x live_conn x x geo_distr x x bit_rate x x peers_popu x poplr_distr x x tool, which can capture flows and perform Deep Packet Inspection, thus enables users to identify known P2P traffics based on payload. MA6 focused on EMule, Kad, and KadU (a modified version of Kad). These 3 application contribute the most traffic to the monitored network. Signatures of these application were already mentioned in other works, therefore classification of these three were not a problem. MA6 applied a machine learning approach, density based algorithm to divide the data set in subsets (clusters), in which the data have similarity. Normally noise region, which was generated after the last step would be considered interesting. However in this case the authors of MA6 chose to select interesting regions based on domain knowledge of network operator, P2P developer and P2P users. MA6 considered metrics as dependent from flow initiator and independent from flow initiator. Metrics dependent from flow initiator are flow average duration, number of active flows, ratio of outside connections to total numbers, bit rate, average packet size, ratio of byte sent and byte received. Metrics dependent of flow initiator are total connection attempts, ratio of flows to the number of distinct destinations, number of peers, number of destination ports, also number of destination ports which are under 1024 was considered. Using signature-based technique for identification, MA6 limited it s work only with three P2P protocols. MA6 analyzed traffic based on domain knowledge, which is better for classification of behaviors at host level, and the way MA6 chose interesting region can be applied in other works as well. Table II is a summary of corresponding metrics in each analysis methods. We can recognize from the table, that the use of each metric differentiates in each work. The reason is, each work has it s own focus on a particular direction. Of all metrics, the metric traffic volume of P2P was the most considered one. It is also a sign, that P2P traffic is getting larger over time and this naturally raises concern of P2P network administrator and researcher. III. DISCUSSION As we have already seen, the common template of P2P traffic analyzing is identify P2P traffic from other traffics, filter them, chose the appropriate metrics, which should be interesting with regard to each particular work, evaluate the worked results from the collected data. There have been many works for P2P traffic identification, they can be general categorized as payload-based, non-payload based and machine learning based methods. Non-payload based has advantage, that it might be able to discover new P2P traffic, which is also a concerned question for analysis. But non-payload based techniques introduce false-positives. In fact four from six described methods chose payload-based techniques, because they only concerned about particular well-know protocols. Payload-based can not discover new P2P traffics, but it can guarantee the correctness of those identified. Therefore the choice of identification method must primarily base on purpose of each research. In this case payload-based is better, but in other case the use of non-payload based it recommended. Early works in P2P analysis focused on comparison between P2P traffic and web traffic, in order to determine the trend of P2P. Especially the traffic volume at the beginning was concerned, as for Internet Provider it would be critical to keep their network at good performance. Then the concentration moved to learn the characteristic and behavior patterns of P2P traffic. From this point on P2P protocols get more complex, as for the trend of network analysis this paper found the idea based on domain knowledge a good approach for future work. For network operator, it is mandatory to be able to monitor P2P traffics, to optimize P2P networks and prevent P2P networks from corruption. Monitor of P2P network is still a big challenge due to large scale of network and dynamic properties of P2P protocols. We have seen some solutions for this problem, but it still has to be developed. A general monitoring approach for all P2P traffic is still a big challenge. Hybrid monitoring scheme would be the solution for monitoring P2P networks. To learn the complex behaviors of P2P traffic machine learning is a good approach. The quality of machine learning process is dependent from the quality of the samples, i.e. a sample set from payload-based identified traffic can be fed in order to learn the behaviors pattern of these particular protocols, or sample set of both payload- and non-payloadtechniques can be fed to learning process. The training data can be used to detect and learn behaviors. By using machine learning process it is also able to learn about undesired behaviors of P2P traffic by choosing suspicious cluster. With this notice we tend to believe that further works in P2P analysis should use machine learning more, as P2P is getting more complex. IV. CONCLUSION This paper considered the problem of P2P traffic analysis and summarized some methods. For a better understanding, the methods were viewed as for identification, monitor/filter and analysis tasks. We reviewed the identification methods in two major approaches, payload-based and heuristic-based methods. Furthermore one approach for identification based on machine learning was reviewed. We stated the classification of monitoring scheme, named the problems and difficulties of P2P monitoring. Afterwards we listed the most common concerned metrics, which can be used for monitoring tasks as well as analysis purposes. We also summarized how these metrics were used in analysis researches. We showed that for 59

70 HARVESTING SENSOR NETWORKS 1 Harvesting Sensor Networks Andreas Straninger Abstract Battery powered Wireless Sensor Networks only have a limited lifetime and have to be replaced if the battery drops to zero. Using renewable energy sources to recharge batteries allows sensor nodes theoretically to attain indefinite lifetime. Thus, the focus moves from maximizing the lifetime to maximizing the usage of harvestable energy. This affects the sensors energy saving strategies, rate adaption, the establishment of routes, compression and the use of error correcting codes. This Seminar work aims to give an overview on algorithms, which maximize the efficiency of harvesting sensor nodes. I. INTRODUCTION Sensors are widely used for gathering information about the environment. One task for a sensor network is field monitoring, where sensors are deployed at an area and information is routed to one or more base stations (see e.g. [2]). Sensors regularly collect information, e.g. temparature or humidity, at a constant rate. The maximum sensing rate for each sensor would be of interest. Another task, which could be performed by sensor nodes deployed over a field is event monitoring. In constrast to field monitoring, only a selected set of events is transmitted, e.g. detected smoke by a fire sensor. Currently, most sensors are supplied by a battery and have to be exchanged, when the sensor node gets out of energy. Algorithms for maximizing the lifetime in sensor networks with batteries are used. Recent works propose the usage of renewable energy sources for sensors in combination with rechargable batteries. If the battery is low, a sensor can shut down components to reduce energy consumption and reload the battery, when energy is available and can be harvested. A harvesting sensor can theoretically work forever. Energy sources, which can be used in harvesting sensor networks (e.g. [6]) are solar, mechanical and thermal energy. Solar energy can be harvested outdoors from the sun or indoors from artificial lights with solar panels. Mechanical energy occurs as vibrational or kinetic energy. Vibrations are harvested by using a piezoelectric capacitator, kinetic energies can be harvested with generators. Thermal energy in terms of temperature differences can also be harvested. The transmission range of sensors usually is limited. Each Sensor collects informations, initiates the transmission of collected informations and routes information to the sink. Compared to a peer to peer network, connections cannot be established arbitrarily. Only connections to locally near sensor nodes are possible. Sensors buffer the information collected and send it to neighbour nodes. In harvestin sensor networks, optimal routes do not necessarily follow the shortest paths with the least possible number of hops. Instead, a routing algorithm would prefer nodes with the highest possible harvesting opportunities. Maximization of energy usage from the environment is one of the task which emerges from the usage of harvesting sensor nodes. The paper is structured as follows. Section II explains the properties of harvesting sensor nodes and introduces the terminology used. In Section III, algorithms for optimizing the energy available for a node are explained. Section IV introduces algorithms, which address sensor network specific problems. Harvesting specific algorithms for rate adaption, routing and compression are depicted. Finally in Section V, a conclusion is drawn and ideas for future research are given. II. BASICS The authors in [2] suggest 3 kinds of energy storage, harvesting systems with no energy storage, harvesting systems with ideal energy buffer and harvesting systems with non-ideal energy buffer. In harvesting systems with no energy storage, for each point in time only the energy harvested can be used. A harvesting systems with ideal energy buffer is able to store and restore all the energy harvested without any losses. Harvesting systems with non-ideal energy buffers have a limited storage capacity, a charging efficiency < 100% and also have a leakage, i.e. a loss of energy over time. In the following it is assumed if not explicitly mentioned, that sensors use batteries as a non-ideal energy buffer. In practice, ultra capacitators and rechargable batteries are used as energy buffers. Ultra capacitators have a high charging efficiency but also a high leakage and a low energy density, i.e. storage capacity per volume. They can be used if high power is available over small time intervals of about a second or less. Rechargable batteries usually have a higher energy density and are suitable for energy that is available for longer periods of time. Sensor nodes use algorithms to control the energy consumption and adjust the duty cycle. The duty cycle is the fraction of time, where the sensor is busy. Sensors are either in active mode or consume a small amout of energy in sleep mode. Empty batteries should be avoided because sensors regularly have to switch to active mode to sense information. A sensor which harvests the same amount energy which it consumes over the time it is deployed, without getting out of battery energy, works at energy neutral operation. If a sensor consumes more energy than harvested before, the battery level may drop to zero and the sensor may be interrupted. On the other hand, if a sensor consumes less energy than possible, the battery may be fully loaded and thus not able to store surplus energy harvested. Hence, an algorithm that optimizes the duty cycle has to estimate the future harvesting opportunities, so that energy neutral operation is possible, and no energy is wasted. Sensors usually provide a sleep mode, where a minimum amount of energy is consumed. In active mode, a sensor 0

71 2 HARVESTING SENSOR NETWORKS may reduce the energy consumption by switching off parts of the hardware e.g. the sensing module or the communication module. Besides, a sensor needs energy for each transmission of data. Thus, an optimized sensing rate and optimal routes for a minimized amout of energy needed for transmission is searched. To measure the current energy produced in an interval, [2] recommend to monitor the energy production of the harvesting source rather than monitoring the battery level because there is only a small change in change of voltage at the battery, compared to the change of voltage in the harvesting module. Algorithms operate either on global knowledge or on local knowledge. Algorithms with global knowledge have information about the state of each deployed sensor node. They can run on a node with high computation power. However, the collection of sensor node states leads to additional transmission overhead and delays. The transmission overhead will be to high to be neglected and delays can cause nodes to make necessary adjustments too late and operate with suboptimal parameters. Algorithms which directly operate on a sensor node with local knowledge only have information about the state of the sensor node and can determine the state of neighboring nodes. Since computation power of sensor nodes is limited, low complexity solutions are required. With the ability to adapt the duty cycle, the energy wastage can be minimized. The following section addresses the issue of optimizing the duty cycle with the use of the state of the sensor node and its sourrounding. III. ENERGY PREDICTION AND USAGE In this section, algorithms for energy prediction and energy usage are presented. The algorithms either schedule the duty cycles on the basis of energy observations or learn how to optimally adapt the duty cycle on the basis of the current sensor state. In the following, one scheduling algorithm and two algorithm that work on current sensor states are presented. A. Scheduling duty cycles The authors in [2] present an algorithm that maximizes the duty cycle over the time, where the sensor is deployed. The algorithm is designed for solar harvesting sensors, therefore it is postulated, that energy patterns reoccure periodically. The period, a day for solar harvesting sensors, is divided into N W time slots. For each time slot i, the power harvested P s (i), the power consumed P c (i) and the duty cycle D(i) are considered to be constant. The maximization of duty cycles is expressed as max N W i=1 D(i) An optimization problem is formulated that takes the power harvested, the power consumed, the battery level and properties of the battery into account. The problem can be solved with high computational power and knowledge about future harvesting opportunities. Since the optimization problem is too complex to be solved on sensor nodes, the authors propose a local low complexity solution. Furthermore, future harvesting opportunities are not known in advance. The algorithm proposed makes predictions about future harvesting opportunities in a first step and then in a second step determines the optimal duty cycle. The duty cycle is readjusted in a third step, if the energy harvested deviates from the energy predicted. In the first step, the algorithm predicts the energy available with an Exponentially Weightetd Moving-Average. The predicted value x(i) at time i is: x(i) = αx(i 1) + (1 α)x(i) where x(i) is the energy harvested at time i. Several values for α have been tested and a value of α = 0.5 is suggested. In experiments, an initial training for 2 hours has been performed before the usage of the sensor nodes. Predictions for each slot x(i) are refreshed after the energy energy yield at slot i has been determined. A window size of 24 hours is chosen, consisting of N W time slots x W. In experiments, N W = 48 time slots have been chosen with a size of 30 minutes each. The algorithm distinguishes sun duty cyles S = {i P s (i) P c 0} where more energy is harvested than consumed and dark duty cycles D = {i P s (i) P c 0} where more energy is consumed than harvested. The optimization problem is reformulated as: N W i=1 P s (i) = i D D(i)[ P c η + P s(i)(1 1 η )] + P c D(i) i S In the second step, the minimum admissible duty cycle is assigned for time slots, where more energy is consumed than harvested and the maximum admissible duty cycle is assigned for time slots, where less energy is consumed than harvested. Then two cases may occure, either there is still energy available or too much energy is assigned to the duty cycles. In the first case, the maximum duty cycle is assigned to additional slots in D, dependent on their harvesting opportunities. Otherwise, the duty cycle of all slots in S is reduced uniformly by a modifier δ. After each time slot, the algorithm corrects in the third step the duty cycle assigned. If less energy is harvested than predicted, the duty cycle of some future time slots is reduced to the minimum duty cycle. Otherwise duty cycles with the lowest duty cycles are increased. In evaluation the authors compared their low complexity algorithm with local knowledge to an optimal solution, which is calculated with global knowledge. They used the same energy prediction method for both algorithms and achieved a good result for the low complexity variant. A drawback of the algorithm is that harvesting predictions are only usable after 2 hours. Thus, the sensor would have to work initially on a reduced duty cycle. B. Learning adaption rules The Idea of the algorithm introduced by Vigorito [] is to minimize the usage of the battery. This is done on the one hand to minimize the losses which occure when charging or discharging batteries. Then, if the battery is full, energy which 1

72 HARVESTING SENSOR NETWORKS 3 cannot be used is wasted and if the batterie is empty, the node gets out of energy. Finally, most types of batteries like NiMH and Li-Ion Batteries have a longer lifetime if they are not completely discharged. The algorithm aims to minimize the quadratic deviation of the battery level B t from the desired level B. In other words, the algorithm tries to minimize the equation lim N t=1 N (B t B ). To achieve this, the algorithm makes use of control theory. The Battery Level at time B t + 1 can be expressed as B t+1 = ab t + bu t + cw t + w t+1 where u t is the utility of the sensor, and w t is some noise. a, b and c are unknown constants. It is mentioned in [], that the optimal control law for u t is u t = B (a + c)b t + cb b The constants a, b, c are calculated via fixpoint iteration. Thus, θ = (a + c, b, c) T and φ t = (B t, u t, B ) T are defined with φ T t θ = y. θ is calculated with fixpoint-iteration. Using fixpoint iteration has the advantage, that a, b and c do not necessarily have to be constant but may change over time. Update rule is given by ˆθ t+1 = ˆθ t + µ φ T t φ t φ t (B t+1 φ T t ˆθ t ) The authors also provide a way to reduce the variance of the duty cycle. Therefore, u t is not used directly, instead, the smoothened duty parameter p t is calculated: u t + 1 = ū t + α(u ū) It is an exponentially weighted utility with old values of u with α < 1. Then, p t+1 = βu t + (1 β)ū t with 0 β 1 is calculated. Experimental results have been made with µ = and different values for α and β. Best results could be achieved with α = 10 4 and β = 0.25 with time steps of 1 minute. The authors compared their solution to the algorithm proposed in [2] and claim to achieve better results with their algorithm. At evaluation, a higher uptime, lower variance of the battery level, and a higher duty cycle was measured. The evaluation was done as a simulation, where measured data of sensors have been used. C. Probabilistic duty cycle adaption Duty cycle adaption algorithms specify the fraction of time, where the sensor is in the wake state or in the sleep state. If a sensor is set to a specific duty cycle, it is not clear, at which parts of the sensors are active and at which intervals they are active. A probabilistic approach for adapting the energy usage of sensor nodes is presented in [4]. Only two states for sensor nodes are assumed, an active mode and a sleep mode. Transations between the states are determined by strategies which are based on properties of the sensor, the battery state or the queue for outgoing messages, or properties of the sourrounding, the channel quality or the solar radiation. Hybrid strategies which use more than one properties are also mentioned. For example, a strategy which is based only on the message queue of size 10 containing x messages and can be formulated in the following way: P active sleep (x) = 0.8 x 4 P active sleep (x) = 0.3 x > 4 P sleep active (x) = 0.3 x 3 P sleep active (x) = 0. x > 3 The authors analyzed the influence of different strategies on the package drop rate respectively the package blocking rate. This was done by modeling the arrival of packages at a node as a batch markovian arrival process, where states are defined for each of the properties and for the state of the sensor node S wake, sleep. A. Maximum flow IV. ROUTING AND NETWORK [2] suggest an approach for maximizing the throughput and determining a constant sensing rate which is equally assigned at all sensor nodes. The energy consumption of a node is given by P (i, j) = r[α 1 + α 2 d(i, j) 2 ] where d(i, j) is the distance between nodes i and j, r is the data rate and α 1 and α 2 are radio [frequency] dependent constants. Given the duty cycle for node i at time t, problem can be formulated as a maximal flow problem where the duty cycle determines the maximal flow through a sensor node and the power P (i, j) determines the actual costs for sending a message from node i to node j. After assigning the flow, the maximum sensing rate can be computed. The algorithm still does not allow the adjustment of sensing rates based on local knowledge. Besides, the approach does not allow sensing rates to be readjusted if the energy harvested varies. B. Rate adaption An approach, which calculates the throughput for a network with fixed routes is presented in [1]. The optimal throughput can be calculated centrally by solving a liniear programming problem. This is done by formulating the necessary constraints for energy consumption of the sensor node, energy needed for routing, and properties of energy neutral operation dependent on the sensing rate. A local solution for the problem is constructed in two steps. First, the maximum sensing rate is calculated for each sensor node. If the battery would drop to zero after a time interval, the 2

73 4 HARVESTING SENSOR NETWORKS sensing rate is adapted. In a second step, each node initiates a request for the sensing rate. The desired rate initially is set to the maximum rate. If a node between the initiator and the sink is not capable of assigning the requested rate for the initiator, all existing assignments are adapted in a fair way and updates are sent. The authors collected harvesting profiles and sensing rates on from a sensor environment and evaluated the algorithm in a simulator. A high running time of the algorithm occured due to frequent rate adaptions. The authors also mention, that higher rates could be assigned more homogeneously among sensor nodes if alternate routes would be possible. C. Greedy Routing A quite simple routing approach is presented in [8]. The algorithm selects the most promising node for next hops dependent on the euclidean distance between the current node and the receiver node, the link state quality, as well as the battery level and the energy production and consumption rates. Informations can be sent between any two sensor nodes in the network. This approach balances the load so that overload situations of nodes are prevented. However, the energy aware greedy routing approach is not the best choice for the monitoring tasks of sensors. Firstly, each sensor node usually only routes its information to one sink. Arbitrary routes are not required and may lead to unneccessary computational overhead. Secondly, no routing tables are used, and thus greedy routing may not be able to find a route in some cases. D. Harvesting aware Routing Tables Routing tables can be used to determine routes between two sensor nodes. For event monitoring and field monitoring, each sensor node has to be able to establish a route only to a collecting node, but not between each other. In a sensor network, where each sensor node has enough energy, a node would keep track about the minimum number of hops to reach a collecting node. Routes would be established to minimize the number of hops. Hence, in harvesting sensor networks, the throughput is limited by the amount of energy harvestable. Thus a higher node availability and thus a higher throughput is expected, if nodes with higher harvesting opportunities are preferred. In [3], five algorithms for harvesting sensor networks are presented and evaluated in a simulation environment. For each sensor node, the average harvesting capabilities are known. The minimum path ( MP ) algorithm selects the shortest path based on the minimum number of hops. For the other four algorithms, nodes randomly make a selection of their next hops. In the randomized weighted minimum path (R-WMP) algorithm, the probability for selecting a node for the next hop is inversely proportional to the package energy, and to minimum number of hops from the next hop node to the sink. The package energy is the energy necessary to transmit the message from the current node to the next hop node. Fig. 1. Comparison of routes calculated with MP, MF and R-MPRT. Dark areas correspond to low harvesting opportunities, bright areas correspond to high harvesting oppor. Source: [3] The randomized minimum path energy (R-MPE) algorithm, computes the minimum path energy, i.e. the energy, which is necessary to route a package from the current node to the sink over a selected next hop neighbor. The probability for choosing a node as the next hop neighbor is inversely proportional to the minimum path energy. The randomized minimum path recovery time (R-MPRT) algorithm is similar to R-MPE. Instead of the link energy, the path recovery time is used, i.e. the time needed to harvest the link energy at the sender node. Finally, with the randomized maxflow (R-MF) algorithm, the optimal flow for each node is centrally calculated. The propability for selecting a node for the next hop are proportional to its optimal flow. Since the algorithm cannot operate on local knowledge, but also uses random node selection, it is only introduced for comparison purposes. The authors showed, that the energy aware algorithms, R- WMP, R-MPE and R-MPRT, perform better than the MP algorithm. Though, compared to the optimal flow, R-MPE and R-MPRT have a performance of about 10% to 40%. In evaluation, the routes were chosen individually for each message. Nevertheless, establishing static routes and reestablishing them regularly is possible to use the rate adaption algorithm presented in this section. Variations of the algorithm R-MPRT can be of use. Firstly, the duty cycle can be used for creating the routing tables instead of the minimum path energy. Then, the authors only address route selection for field monitoring. If routes for event monitoring are required, the maximum delay can be used instead of the minimum path energy. E. Compression Properties about static routes are also discussed in [5]. The authors propose to aggregate and compress data and in this way save energy and reduce the number of messages sent. The authors state, that individual routes, which are established for each message arouse data collisions. Additionally, sensor nodes can aggregate and compress data with the same destination to reduce the amount of transferred data and thus save energy. The method presented divides the area, where sensor nodes are deployed into regions. For each region, a node is chosen which is denoted border node. A border node in harvesting sensor networks should be close to the sink and have high 3

Version: 00; Status: E Seite: 1/6 This document is drawn to show the functions of the project portal developed by Ingenics AG. To use the portal enter the following URL in your Browser: https://projectportal.ingenics.de

p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for

Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Prediction Market, 28th July 2012 Information and Instructions S. 1 Welcome, and thanks for your participation Sensational prices are waiting for you 1000 Euro in amazon vouchers: The winner has the chance

Exercise (Part II) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Support Technologies based on Bi-Modal Network Analysis H. Agenda 1. Network analysis short introduction 2. Supporting the development of virtual organizations 3. Supporting the development of compentences

Exercise (Part XI) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Delivering services in a user-focussed way - The new DFN-CERT Portal - 29th TF-CSIRT Meeting in Hamburg 25. January 2010 Marcus Pattloch (cert@dfn.de) How do we deal with the ever growing workload? 29th

IoT Scopes and Criticisms Rajkumar K Kulandaivelu S 1 What is IoT? Interconnection of multiple devices over internet medium 2 IoT Scope IoT brings lots of scope for development of applications that are

Inequality Utilitarian and Capabilities Perspectives (and what they may imply for public health) 1 Utilitarian Perspectives on Inequality 2 Inequalities matter most in terms of their impact onthelivesthatpeopleseektoliveandthethings,

Possible Solutions for Development of Multilevel Pension System in the Republic of Azerbaijan by Prof. Dr. Heinz-Dietrich Steinmeyer Introduction Multi-level pension systems Different approaches Different

Labour law and Consumer protection principles usage in non-state pension system by Prof. Dr. Heinz-Dietrich Steinmeyer General Remarks In private non state pensions systems usually three actors Employer

I IA Sensors and Communication - Process Analytics - Karlsruhe, Germany Page 6 of 10 Out Baking Of The MicroSAM Analytical Modules Preparatory Works The pre-adjustments and the following operations are

This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Exercise (Part I) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

USBASIC SAFETY IN NUMBERS #1.Current Normalisation Ropes Courses and Ropes Course Elements can conform to one or more of the following European Norms: -EN 362 Carabiner Norm -EN 795B Connector Norm -EN

The Single Point Entry Computer for the Dry End The master computer system was developed to optimize the production process of a corrugator. All entries are made at the master computer thus error sources

1 The zip archives available at http://www.econ.utah.edu/ ~ ehrbar/l2co.zip or http: //marx.econ.utah.edu/das-kapital/ec5080.zip compiled August 26, 2010 have the following content. (they differ in their

UNIVERSITÄT JOHANNES KEPLER LINZ JKU Technisch-Naturwissenschaftliche Fakultät Working Sets for the Principle of Least Privilege in Role Based Access Control (RBAC) and Desktop Operating Systems DISSERTATION

English Version 1 UNIGRAZONLINE With UNIGRAZonline you can organise your studies at Graz University. Please go to the following link: https://online.uni-graz.at You can choose between a German and an English

Abstract The thesis on hand deals with customer satisfaction at the example of a building subcontractor. Due to the problems in the building branch, it is nowadays necessary to act customer oriented. Customer

First European i2b2 Academic User Meeting IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database The IDRT Team (in alphabetical order): Christian Bauer (presenter), Benjamin

Virtual PBX and SMS-Server Software solutions for more mobility and comfort * The software is delivered by e-mail and does not include the boxes 1 2007 com.sat GmbH Kommunikationssysteme Schwetzinger Str.