Cache Attacks On Blockchain Based Information Centric Networks: An .

Cache Attacks on Blockchain Based Information Centric Networks: An Experimental Evaluationto designing ICNs have moved towards using blockchains to enhance their privacy and security [13, 23, 25, 33]. This is because,blockchains inherently provide strong integrity checking. Moreover, blockchain is decentralized and automatically fits into the ICNparadigm.In [23], the authors designed a secured cache scheme for ICNbased wireless sensor networks (WSNs). They employed both public key infrastructure (PKI) and blockchains to enable safe gatheringof data, and cross-verified the sensed data to be stored. However,their ICN was vulnerable to cache attacks since there was no mechanism to stop an insider malicious node to request unpopular butvalid sensing data from the other nodes. Furthermore, the use ofFIFO replacement strategy for caches have been found to be themost vulnerable– which we discuss later in section 4. In [25], theauthors proposed the use of ICNs, instead of conventional transmission control protocol/Internet protocol (TCP/IP) and permissionedblockchains that allow for the dynamic control of the source reliability, and the integrity and validity of the information exchanged. Theblockchain usage in the ICN prevents the DoS attack that involvesflooding the network with arbitrary request packets. However, theICN did not have the protection against malicious nodes that requestvery unpopular but valid contents from the network. In [33], theauthors designed a blockchain system over a named data network(NDN). With the caches located at the NDN routers, the systemwas vulnerable to cache attacks. In [13], the authors designed amodel for collaborative blockchain based video delivery relyingon advanced network services chains. Again in their model, thecaches that were part of their content delivery network, were notprotected against the attacks performed in this work.2.3The user request is sent as query to the server, which then is servedby a nearby cache or the web server based on content availability.The basic steps in the methodology are:(1) Implement caching networks over nodes.(2) Implement querying for documents over the networks.(3) Assume one or more nodes are compromised, implementthe attack and evaluate the change in performance of thenetworks.Each node in the ICN contains a hash table to direct a query tothe next hop to serve the user’s request. We create a network with4 and 11 with two different topologies: linear and mesh. Detaileddescription of these topologies are given in the next section. In thereal world (e.g., videos from YouTube), some documents (files in ourcase) have much higher popularity over others. For example, somevideos in YouTube are very popular and have been viewed over amillion times, while there are others with less than 10 views. It iswell known that web content request popularity follows a Zipfianlike distribution [6, 11, 16–18]. Therefore, we assume that the filepopularity follows the same Zipfian distribution. The commonvalues for α considered in the Zipfian distribution are usually liebetween 0.65 and 0.85. Since the change in α has the same differenceratio, α 0.65 has been used throughout this experiment. Thecaches of all the nodes are empty in the initial phase, and thus awarm-up test was carried out to fill the caches before experimentalresults were obtained. The parameters that were used to measurethe performance are:(1) Increase in average number of hops for queries.(2) Average delay for each request in the network.For each user’s request, Dijkstra’s algorithm [15] is used to findthe shortest path to the custodian which could be either the cacheof an intermediate node in case of a popular file, or the web server(if the file is not found in the cache of any intermediate nodes inthe path). The cache sizes considered are 10 MB and 40 MB. Forexperimental purposes, the ICN with 4 nodes is considered as a‘small’ network and the ICN with 11 nodes is considered a ‘midsized’ network. In this work, the effect of the cache attack on boththese ICNs with the real network traffic with the firewall in place,is compared to the results obtained in [12] for networks of samesizes via simulations.Cache attacksThe cache memory is the temporary memory shared by multipleprocesses. The cache is accessible by the user and the attacker. Thistemporary memory is used to store the content invoked by the userfor any requests to improve the efficiency for the future requests.Thereby if the user requests such content, it will be fetched directlyfrom the cache itself or by the nearby hosts without reaching theweb server to fetch the user data. A caching attack is defined asfilling of the cache with some random data.Although simulation results are available that compare the performance of a caching attack in ICN [12], there are no experimentalresults that evaluate the performance of cache attack on real ICNs.Moreover, testing the effects of a DoS attack on the caches of areal ICN is currently missing from the literature and is an openproblem– which motivates this work.33.2Blockchain Implementation usingHyperledger FabricApart from a regular ICN, we also investigate the suitability ofHyperledger fabric for ICNs. Hyperledger fabric is one of the wellknown frameworks for implementing a private blockchain [1]. Hyperledger is a collaborative project started by the Linux Foundationand developed by many companies including IBM, Intel, Cisco,Hitachi, and so on. It is a private and permissioned implementation which is widely used by enterprises. It uses a pluggablemethod of consensus which is defined based on specific applicationrequirements. Its most common method of consensus is PracticalByzantine Fault Tolerance. Unlike bitcoin and ethereum whichare public blockchains, this private blockchain framework attainsconsensus within hundreds of milliseconds [27]. Such low latencyis crucial for building blockchain based ICNs. Being permissioned,the blockchain is controlled by a specific organization which allowsIMPLEMENTATION OF ICN ANDBLOCKCHAINSWe implemented cache attacks over real information centric networking systems. As for blockchains, we use the hyperledger fabricframework. In this section, we presnt the experimental setups indetail and discuss the results in the next.3.1ICDCN 2019, Bangalore, IndiaICN ImplementationThe ICN was set up with the cache and web servers in our lab. Thissetup allows the user to access or fetch data from the web server.136

S. Roy et al.ICDCN 2019, Bangalore, Indiaspecific nodes to join the blockchain, access to the database, andparticipate in the consensus protocol. This framework supportschaincode designed in the Go language which is a special versionof smart contracts.In our implementation, we isolated the network from the campus backbone network. Such restricted access to the public bringsdata integrity for exchanged information and source reliability. Weimplemented the hyperledger fabric platform with 11 nodes whichexchange information. In this implementation, the exchanged information is controlled and validated by 2 peers in the framework.These peers are responsible for validating and performing the requests by the nodes within the network. The validation of newblocks is also the responsibility of these peers. There is anotherentity in this implementation called the orderer which receives allthe valid invoke requests called transaction from nodes and make ablock out of these transactions and send them to peers to be verifiedand added to their copies of the ledger. These invoke requests arefirstly verified and accomplished by one or more number of corresponding peers which are dedicated according to the defined policyin the chaincode. Thereafter, these requests are sent to orderer forfurther process.We implement two types of requests by nodes to be sent to peers:query and invoke. Query is getting to know the current state of theledger like asking the current value of a variable assigned to a node.Invoke is requesting a change in the ledger like changing the valueof a variable assigned to a node. As for the performance metrics,we consider three types of delays: query delay, invoke delay, andupdate delay.Operating SystemGnome Ubuntu 16.04ProcessorIntel Core 2 Quad Q9300 2.5 GHz x4OS Type64 bitMemory Size3.7 GBDisk Size28.2 GBTable 1: Hardware Configuration3.4Hardware and Software SpecificationsLinux flavor Ubuntu 14.0 AMI was mounted on the workstations.Java JDK version 1.7 was installed, along with Python 2.6. The firewall was configured using Linux IPtable. Squid open source proxywas installed on every node (including the web server). Squid configuration file was configured in each node to specify the node andthe next hop, thereby implementing the linear and mesh topologies.The other system parameters for all the caches/nodes are shown inTable 1.3.5Topology UsedAs mentioned earlier, we considered two topologies for our implementation so as to compare with the simulation results obtainedin [12]. For the linear topology, the caches were built on each workstation (node) along with the web server. In this topology, the userrequest and the attacker request are generated at random. Thenetwork was full duplex. Fig. 2 and Fig. 3 show the representationof the mesh topologies with 4 and 11 nodes respectively.(1) Query delay is the time it takes that a node receive theresult of a query.(2) Invoke delay is the spent time to make a change in thecopy of the ledger of the validating peer.(3) Update delay is the total spent time since initiating theinvoke request by a node until updating all copies of ledgerin the network.3.3Performed Cache AttacksThe goal of the attacker is to feed caches of all nodes in the ICNwith extremely unpopular content (files in this case) and thereforerender every user’s request unavailable in the cache forcing it hoptill the web server. Hence the time taken for each request (query)will be more, increasing the average response time for query for theICN, and reducing its efficiency. The assumption is the attacker hascontrol over one or more nodes in the ICN from which the attackergenerates queries for extremely unpopular contents periodicallyin order to fill in the caches of the intermediate nodes with theseunpopular contents. The node(s) controlled by the attacker is (are)called compromised node(s).This cache attack is performed on the both the ICNs (with 4 and11 nodes) with one compromised node. Then the same attack isrepeated with two compromised nodes for both the ICNs, and alsowith four and eight compromised nodes for the ICN with 11 nodes.To recall, according to [12], in the large network, the impact ofcache attack was less whereas in the smaller network, the impactwas higher.Figure 2: Partial Mesh Topology with 4 NodesIn the partial mesh topology, each node has at least two neighbors [30]. An exception to that has been made in Fig. 2, where theweb server is connected to only one node. Each user request usesthe Dijkstra’s algorithm [15] to find the shortest path to fetch thefile either from the cache of another node (including its own), orfrom the web server in case the cache of any intermediate nodedoes not contain the requested file.137

Cache Attacks on Blockchain Based Information Centric Networks: An Experimental EvaluationICDCN 2019, Bangalore, IndiaParameterPolicy#nodesCache sizeFile size#files% of unpopular files#attackersValuesLRU, Random, FIFO4, 1110MB, 40MB1MB400120%0, 1, 2, 4, 8Table 2: Parameters for Linear and Mesh ICNs48 popular files. The total number of files used in the experimentswas 400.Figure 3: Mesh Topology with 11 Nodes44EVALUATION AND RESULTSResponse Time [S]In [12], the researchers found in a simulation environment thatcache attack was considerably more effective with FIFO replacement policy over LRU and Random. In this research therefore LRU,Random, and FIFO policies have been used to compare the resultswith [12]. There were a fixed number of files with a fixed sizefor each experimental scenario. The popularity of each file wasassigned based on a Zipfian distribution with a Zipfian α value of0.65. This α is the most common Zipfian value. Another commonvalue of α, (0.85) has been used in [12] for very large networks ofmore than 100 nodes, which were not considered in this research(due to lack of resources).It is to be noted, since the value of α remains constant throughoutthe set of experiments, the same set experiments performed witha different values of α will only change the absolute values of thenumerical results, but not the trend or overall conclusions obtainedfrom the experiments. The results of using a different value for αwill thus be numerically but not qualitatively different, although afixed value of α 0.65 has been used in these experiments.4.12 Attackers1 Attacker0 Attackers321001020304050Cache Size [MB]Figure 4: Linear ICN with 4 Nodes with LRUIn Fig. 4, the effect of cache attack in the linear ICN with 4 nodesis illustrated. All result sets were obtained after the initial warm-upthat fills the cache with random data. As exhibited in Fig. 4, it isfound that the impact of the cache attack increases with the increasein the number of attackers, since the response time for requestsincreases with the increase in the number of attackers. This resultis consistent with [12] for the same parameters thus validating thisattack on a real ICN. Fig. 5 shows the results for the linear ICN with11 nodes.Evaluation ScenariosOnce the popularities of the files were set with the given Zipfiandistribution, the effectiveness of the attack and the average timetaken for the ICN to respond to a request without and in presenceof attacker(s) was measured. For the experiments, cache sizes of10 MB and 40 MB were chosen. The various parameters used forboth linear and mesh topologies are given in Table 2. In both thescenarios, the rate of requests from the normal and attacker nodeswere the same.As stated in Table 2, each of the replacement policies LRU, FIFO,and Random were tested in this scenario. The ICN with 4 nodes wastested with 0, 1, and 2 attackers, and that with 11 nodes was testedwith 0, 1, 2, 4, and 8 attackers. Additionally, going by the resultsof [12], the number of unpopular files each attacker can requesthas been fixed at 120% of the cache size in MB. Therefore with acache size of 10MB, the attacker requests at least 12 popular files,and with a cache size of 40MB, the attacker always requests at leastParameterPolicy#nodesCache sizeFile size#files% of unpopular files#attackersValuesLRU1110MB, 40MB1MB400120%0, 1, 2, 4, 8Table 3: Parameters for Linear ICN for 11 Nodes with LRU138

S. Roy et al.ICDCN 2019, Bangalore, IndiaAgain, as exhibited in Fig. 5, it is found that the impact of thecache attack increases with the increase in the number of attackersfor the linear ICN with 11 nodes.656Response Time [S]4Response Time [S]5438 Attackers4 Attackers2 Attackers1 Attacker0 Attackers2138 Attackers4 Attackers2 Attackers1 Attacker0 Attackers21001020304050Cache Size [MB]001020304050Figure 7: Mesh ICN with 11 Nodes with LRUCache Size [MB]the difference in the beginning is due to the fact that no cache wasused during the starting point by [12] for the experimental scenarioof Fig. 8, while caches of size 10 MB were used at the starting pointin this work. This validates the fact that the simulation results couldbe replicated in the real world, and it confirms that this cache attackis a threat to ICNs.Figure 5: Linear ICN with 11 Nodes with LRUIn Fig. 6, the effect of cache attack in the partial mesh ICN with4 nodes is illustrated. Fig. 7 shows the same with the partial meshICN with 11 nodes.5Response Time [S]4322 Attackers1 Attacker0 Attackers1001020304050Cache Size [MB]Figure 8: Simulation on a linear ICN [12]Figure 6: Partial Mesh ICN with 4 Nodes with LRU4.3As shown in Fig. 5, it is found that the impact of the cache attackincreases with the increase in the number of attackers for the linearICN with 11 nodes.4.2Comparison of Trends over DifferentCache Replacement PoliciesNext, the effect of the cache attack has been compared for differentcache policies on both kinds of ICN. In particular, Fig. 9 comparesthe effect of the cache attack on a linear network of 11 nodes withcache replacement policies LRU, FIFO, and Random. For each replacement policy, the percentage increase in the average responsetime for requests with 0 attackers and 8 attackers respectively withcache sizes 10 MB and 40 MB have been reported in the plots. AsComparison with other Simulation ResultsFig. 8 shows the trends of similar experiments conducted in a simulator over a linear ICN with comparable parameters. These trendsare very similar to Fig. 4. Comparing the trends of Fig 8 and Fig 4,139

Cache Attacks on Blockchain Based Information Centric Networks: An Experimental EvaluationICDCN 2019, Bangalore, India% increase in Response Timeobserved from Fig. 9, the effect of the cache attack is the most forFIFO, and the least for LRU replacement policy for the linear ICN.% increase in Response Time25201520151051010540LRU10LRUFIFORandomFigure 10: Mesh ICN with 11 Nodes.Randomaverage delay is calculated using 1 where EW MAt is exponentialweighted moving average at time t, dt is delay at time t and β isdegree of weighting decrease. We have chosen β equal to 0.1818 inour experiments.Figure 9: Linear ICN with 11 Nodes.Fig. 10 compares the effect of the cache attack on the meshnetwork of 11 nodes with cache replacement policies LRU, FIFO,and Random. Again, for each replacement policy, the percentageincrease in the average response time for requests with 0 attackersand 8 attackers respectively with cache sizes 10 MB and 40 MBhave been reported in the plots. As observed from Fig. 10, the effectof the cache attack is again the most for FIFO, and the least forLRU replacement policy for the mesh ICN. However, there is onedifference for cache size of 40. The difference between the policiesis more pronounced in the mesh ICN than the linear ICN. Thisis probably due to the complex topological structure of the meshnetwork over the linear network.LRU has been found to be the best policy for various networksettings (e.g. [3, 5, 31]). Therefore the performance of LRU policyagainst the cache attack is not surprising. In [12], simulation resultsalso revealed LRU as the best replacement policy .EW MAt β dt (1 β) EW MAt 1(1)It should be noted that the invoke request is sent only to the validating peers and these peers after processi

2.1 Information Centric Networks (ICN) An ICN focuses on content objects that can be accessed or cached anywhere in the network rather than solely residing at the end hosts. With the evolution of the Internet from being host-centric to being network-centric, ICN aims to provide in-network caching