P 2 P proxy / cache Bc

Internet as we know it nowadays is full of suboptimal behavior, widely used protocols are not optimized for factors not concerning the end users. This factors ultimately affect the whole Internet, a great example of such is the Peer-to-Peer (P2P) traffic problem. P2P traffic currently represents 50-90 percent [1][2][7] of whole Internet traffic, with the expectation to grow by 400+ percent in the next 5 years [2]. Most Internet Service Providers (ISP) try to minimize this traffic using some form of restrictive counter measures, like traffic shaping, Fair Use Policies (FUP) or similar techniques. This approaches restrict the end user experience, limit the possibilities in which they are able to use their Internet connection just to save ISP resources or delay the need to invest into new infrastructure, thus artificially slowing down the growth of Internet which in fact as this study will show is not necessary. 1 PERR-TO-PEER PROTOCOLS P2P networks are based on the idea of decentralization, sharing of resources across large number of hosts/users. This decentralization enables the network to perform in ways that can not be compared to any other file/content providing technology. In all of the parameters as total download amounts, speeds, availability, scalability, costs P2P superiority is unmatched. There are many P2P implementations currently available, the most used is the BitTorrent protocol with 60-90 percent of total P2P traffic [1]. BitTorrent is a very flexible protocol that can be used to deliver any kind of content. For example it is the ideal way for distributing content like Videoon-demand (VOD) and/or other high bandwidth applications. Because of the mentioned we will focus on BitTorrent in this study. The main motivation is that the clear benefits and possibilities of this technology can not to be fully exploited without prior solving the negative effects of decentralization. The biggest issue is that the data flows are mostly not controlled, that means the whole network communication is not effective and creates a lot overhead. For example the total P2P traffic is by more than 75 percent redundant [3]. 2 BITTORRENT ARCHITECTURE The BitTorrent protocol became over the years of its existence pretty complicated, in this paper we wont try to describe the full architecture with all the extensions that currently exist. We will focus on the key element of this technology and that is the client-tracker communication. Tracker is a dedicated server that coordinates the clients, it does not hold any content itself. Clients download the metafile (.torrent) from the tracker resp. from other sources, open it via their BitTorrent client software which then reads the information contained in the metafile Figure 1: Protocol Type Distribution Germany 2007, P2P represents 73.79 % Figure 2: P2P Protocol Distribution by Volume Germany 2007, BitTorrent represents 66.7 % as torrent information (date created, comment etc.) file information (name, length, hash) and tracker information (hostname, port). The client software then connects to the specified tracker and requests the torrent content using a hash generated from the informations contained in the metafile, this hash is called infohash and is used in the whole BitTorrent protocol to identify the torrent's content. Tracker replies with a list of other clients that are downloading the same content (leechers) or already finished the download but are still uploading (seeders). The client software then starts the negotiation with other clients, but keeps updating the tracker in regular intervals. The tracker is updated when the download is completed too. The updates consist of informations like: action (started, stopped, completed), bytes received, bytes left, bytes uploaded etc. 3 PEER-TO-PEER PROXY/CACHE By evaluating the architecture of the BitTorrent protocol, we were able to detect an attack vector using which it is possible to perform an Man-in-the-Middle attack on the client-tracker communication. By intercepting the client requests and tracker responses, we were able to create a transparent BitTorrent proxy/cache server. This device gives us the full control over the user downloads in the network segment behind the proxy. It is possible to collect detailed statistical information on all downloads and based on this select content to be cached and then transparently served to other users requesting the same content thus eliminating redundancy of data being downloaded. Benefits of such approach:  absolutely no uplink from clients in the given segment  no redundant data outside of segment, massively reducing amounts of data downloaded  if content is already in cache clients download the content at full speed of their Internet connection (link) from the very first byte to the end, this is in contrast to classic P2P behavior where downloads start very slow and then by negotiating with more users gain speed  if content is not yet cached and there is a high possibility more users will be interested in the same content the Figure 3: The Problem with Publishing: More customers require more bandwidth Figure 4: The BitTorrent solution: Users cooperate in the distribution Figure 5: A graphical explanaition of the BitTorrent protocol architecture from HowStuffWorks.com proxy actively supports the client download thus greatly enhances the client download speeds while parallel caching the content  because of the full control over client downloads it is possible to optimize the network traffic  specific content can be kept accessible longer than on classic P2P networks Because the device is completely transparent it can be placed on different layers of the ISP network creating a hierarchical structure that maximizes mentioned benefits even more. Using proxies a hybrid P2P network can be created, hybrid because the content is no longer completely decentralized, the data flows are no longer uncontrolled, the negative sideeffects of P2P are solved. The final effect of proxying depends on fine tuning the "all data stored data" ratio. More TB disk space will enable more data being served from local cache. Even that the clients wont upload any data (effectively freeing the last mile uplink) the P2P network from global perspective is not affected as the cache itself is keeping uploading the content. It is important to mention that because of the transparency of this solution neither the client software nor any other part of the currently used technology has to be changed. This technology can be used not only in standard wired or wireless ISP's networks but it also opens new possibilities for satellite Internet providers. Great majority of Earth's population has no access to broadband Internet, the latest generation of satellites is able to provide download speeds of up to 155Mbps with 6Mbps upload per user with relatively small dish size diameter of 45 centimeters [4]. The problem with this kind of Internet connection is the extremely slow latency generally about 500-900ms [5] (for comparison dial-up has latency around 150-200ms). The only way around this problem is to use on-orbit caching, thus reducing the latency for content provided from the cache to theoretical limit of 233ms (for the orbit height of 70,000 km). As shown with the use of extensive multi-protocol caching it would be possible to reduce the latency to dial-up levels for almost all non-realtime traffic. 3.1 Intercepting Tracker HTTP/HTTPS protocol Tracker requests are plain HTTP requests with a specific message format, this could be called the completely weakest point of the whole technology. For example some traffic filtering techniques use tracker responses which contain a clear text list of peers with their specific IP addresses and ports to deny just the Peer wire protocol communication (interclient communication). As a reaction, some trackers started to encrypt this part of the response. Our proxy attacks the requests, it recognizes them and intercepts them, then the actual man-in-the-middle (MiTM) attack begins. Most trackers still use HTTP or at least support Figure 6: An example P2P proxy/cache topology Figure 7: An example of a Hierarchical P2P proxy/cache toplogy it for compatibility reasons 1 , however we are able to intercept HTTPS in most cases too. This is because many trackers use self-signed certificates which are vulnerable to MiTM, when this is not the case then MiTM on HTTPS can be still successful because majority of BitTorrent clients does not verify the server certificate. Further, it is a de-facto standard to use always more than one tracker multiplying the chance of interception. The only case in which this interception mechanism would not work would require that only one tracker is specified and that uses a CA signed certificate (or all specified trackers use HTTPS and have a CA signed certificate) simultaneously the BitTorrent client verifies the certificate and then actively refuses the connection because it detects a MiTM attack. As of the date of writing this paper the author is not aware of any BitTorrent client that would act as mentioned. 3.2 The logic behind The next phase after we intercepted the request is to decide if we already have the content cached, if yes, simply respond to the client as the original tracker providing the IP address of our proxy as the only peer who has the content, and the port number on which the content can be downloaded. If we do not have the content, we have to decide if it is "interesting" content i.e. it is viable to download it. This can be decided using the number of requests from the network served, for example if there will be more than x requests on this specific content then we cache it. Or we can use public search engines, look how many people already downloaded it, if it is popular in the last x hours then it is highly probable there will be more than one request for that file from our segment and it is a good idea to cache it. While we cant s