Classification Based IP Geolocation Approach to Locate Data in the Cloud Datacenters

Transcription

1 Classification Based IP Geolocation Approach to Locate Data in the Cloud Datacenters Biswajit Biswal College of Engineering Tennessee State University, Nashville, TN, USA Sachin Shetty College of Engineering Tennessee State University, Nashville, TN, USA Tamara Rogers Computer Science Tennessee State University, Nashville, TN, USA ABSTRACT Cloud subscribers would like to verify the location of outsourced data in the cloud datacenters to ensure that the availability of data satisfies the Service Level Agreement. Cloud users may not have access to their outsourced data in the event of operational failures in datacenters or occurrence of natural disasters and/or power outages. Recently, IP geolocation techniques have been proposed to locate data files in cloud datacenters. However these techniques exploit relationships between Internet delays and distance and are not extensible to incorporate different network measurements, which may be used along with Internet delay to improve accuracy. Also, most of the existing techniques have only been validated with one cloud provider (Amazon Web Services). In this paper, we propose a classification based IP geolocation algorithm, which incorporates multiple network measurements to improve the accuracy of geolocating data files in datacenters in four commercial cloud providers. To demonstrate the accuracy of our approach, we evaluate the performance on Amazon Web Services, Microsoft Azure, Google App Engine and Rackspace. Our experimental results demonstrate that our approach is geolocating data files accurately and more closely to the true location. I INTRODUCTION Cloud data owners wish to audit how their data is being handled at the cloud and, in particular, ensure that their data is available all the time without being affected by cloud outage. There is no such formal auditing tool available to cloud users to verify the location of data in cloud data centers. Recently, there have been numerous instances wherein cloud outage rendered business services inaccessible to cloud users for a significant period of time. For instance, on Dec 24, 22, Netflix services, hosted on Amazon Web Services (AWS), were unavailable to customers for more than 2 hours [4]. Similar data outages were reported by Dropbox users [5] and Xbox live users [6]. Cloud users files on Dropbox are stored on Amazon s Simple Storage Service (S3) in multiple data centers located across the United States. Xbox live users data and saved games are accessible through Windows Azure storage service. Hence, there is a increasing interest among cloud users for an auditing tool to geolocate cloud data to ascertain the availability of outsourced data. Typically, cloud users specify the QoS requirements of their outsourced data in a Service Level Agreement (SLA). In addition to common QoS requirements (bandwidth, delay, etc), cloud SLA also specify the geographic region of a service at various granularities (county, city, state, country). Cloud users can benefit from an auditing tool which can ensure that the location restrictions on the services are not violated. Availability of outsourced data is one of the critical QoS requirements. The auditing tool can verify if the availability of data is in accordance with the SLA, especially in situations like natural disasters and /or power outages and more over most of the cloud datacenters located in cities which are most vulnerable to natural disasters. The availability can be verified by geolocating cloud user data in datacenters. Recently, few efforts have been proposed for geolocation of cloud data. Gondree et al. [4] proposed the constraint-based data geolocation(cbdg) approach to geolocate data hosted on Amazon S3. Benson et al. [] developed a model to verify how many copies of their data are present in cloud datacenters. CBDG extends CBG geolocation technique, whose average accuracy is less as compared to Enhanced Classifier approach [2]. Benson s model does not focus on geolocating data on multiple cloud datacenters and has been verified on only one service on AWS. In this paper, we present an approach based on a machine learning framework, which improves the average accuracy of geolocating datacenters as compared to prior measurement-based approaches. We verify the accuracy of the approach by evaluating the geolocation results of cloud user data for multiple services in datacenters across multiple commercial ASE 24 ISBN:

2 cloud providers. We extend our enhanced classifier [2] called Classification Based IP Geolocation (CBIG) to geolocate Internet nodes to geolocate cloud data. To the best of our knowledge, this is the first effort to verify the location of cloud data for storage and web services on multiple cloud datacenters: AWS [6], Microsoft Azure [7], Rackspace [9] and Google AppEngine [8]. learning Naive Bayes framework to geolocate internet hosts. All the delay-based geolocation schemes assume that network delay is well correlated with geographic distance but this assumption is voilated when network traffic takes indirect route between hosts. This results low accuracy. Improved accuracy is obtained by combining delay with other network measurements. The rest of the paper is organized as follows. In Section II we provide an overview of the state-of-the-art Recent reported instances of cloud outages affecting availability of cloud services have increased the interest active cloud data geolocation schemes. In Section III in cloud data file geolocation. For example, we present our approach based on the CBIG. In Section IV we present the experimental setup. In Section V, experimental results of verifying our approach on in the past year, there have been instances when cloud users were not able to access services offered by online movie streaming provider Netflix and storage multiple cloud datacenters is presented. We finally provider DropBox. Similar outages have been conclude in Section VI. reported by several small and large scale businesses who use the cloud to offer services to customers for their business and were compensated by the cloud II BACKGROUND AND RELATED WORK providers. K.Benson et al. [] proposed a method to verify how many copies of data files are stored in Several geolocation schemes have studied for finding various geographic granularity such as latitude tive linear relationship between latency and the dis- the cloud. They mentioned that there exists a posi- and longitude, street address, zipcode and city or tance from a computer node to the location of the county of a given IP address. IP geolocation have actual datacenter whereas no positive linear relationship exists with other locations. In their model, Plan- approached through either Database query (passive method) or active network measuments to geolocate etlab [5] nodes are forced to download data from IP addresses. There are available public database a particular cloud datacenter located in a city by such as ARIN [24] and proprietary databases such as changing the DNS server of that city on all PlanetLab nodes. Their prediction of storage is best if Maxmind [25] and Neustar(formerly Quova) [26]. Informations obtained from database query sometime distances between PlanetLab nodes and cloud datacenters are under 5km (32.5 mi). However, to are not to our expectation and may be not suitable for security-sensitive applications. detect the new location of data the distance should Active network measurements have adapted in many research geolocation algorithms. Topology based geolocation scheme proposed by E.Katz-Bassett et al. implements traceroute measurements (i.e. hops and RTT between hops along the path to the destination). The accuracy of the solution is not reliable due to network dynamics. More accurate and real time delaybased geolocation algorithms are studied for geolocation such as CBG, Statistical and Learning-based. CBG [2] uses known landmarks to measure latency to a target, a bestline method for conversion of latency to distance and multilateration technique to geolocate the target. However, CBG has geolocation errors when monitoring landmarks are far from target. Also this method fails to consider the statistical variations in network delay measurements. Statistical geolocation [2] employs a joint probability desnsity function of network latency and geographic distance to geolocate target. Learning-base [3] uses network delay and hop measurements as input to a machine be more than 3km between Planetlab nodes and data origin. Their focus is to find diversity rather exact locations of the data. M.Gondree et al. [4] proposed a framework based on Constrained-based Geolocation(CBG) algorithm to geolocate cloud data storage. Their framework uses a combination of latency-based geolocation technique and probabilistic proof of data possession(pdp) scheme, with an average error distance of 626km. Unfortunately, the IP geolocation algorithms reported in the literature have larger average error distances as compared to CBIG approach [2]. Albeshri et al. [] proposed GeoProof, a method for geolocation assurance. GeoProof combines the proof of storage (POS) scheme and distance-bounding protocol []. In their architecture, to geolocate data a GPS enabled device is placed at provider to access position information but the idea is not feasible enough when data moves and also position information can be easily manipulated. Moreover this scheme was evaluated on a ASE 24 ISBN:

3 university network rather than a real world cloud environment. Watson et al. [2] presented the Location Based Storage (LoST) to geolocate the location of files in cloud. Their method includes a geolocation scheme and proof of location scheme. The geolocation scheme is combination of a time-distance function which translates times to distance using best-fit lines and geometric trilateration. The average geolocation error distance, however, is km. None of the papers discussed above mention geolocating other web services rather than Amazon S3. Most of the papers have geolocated results on Amazon S3 only and never experimented their geolocation scheme with other cloud providers. Paladi et al. [9] presented a survey of IP geolocation techniques used for locating cloud storage nodes. Measurement-based and topology based IP geolocation algorithm have been proposed to geolocate Internet nodes [2 23]. III APPROACH We extend our CBIG approach [2] to geolocate data files in cloud datacenters for various cloud services. CBIG approach trains a Naive Bayes classifier by using network measurements as features to geolocate Internet nodes. We extend this approach by evaluating the accuracy of the classifier on network measurements (average delay, standard deviation delay, mean & median delay, hop count) and societal characteristics (population density) features collected between cloud users (PlanetLab nodes) and data centers from four commercial cloud providers. Fig. illustrates the system model. The system model describes the process of how cloud users access various services in multiple datacenters managed by cloud providers. Each cloud user uses their accounts with multiple providers to upload data and access available services. In our system model, we have restricted the services to storage and content delivery network (CDN). PlanetLab nodes, distributed across multiple locations in United States, act as landmarks and are involved in the collection of network measurements. To geolocate storage service, network measurements between PlanetLab nodes and cloud storage datacenters are collected. To geolocate CDN service, network measurements between PlanetLab nodes and cloud CDN servers are collected. The CBIG model is trained and tested with the network measurement data. The classifier s predicted city output is compared with the true cloud datacenter location and error distance is calculated to verify the accuracy. We now present an overview of the CBIG and the extension of the approach to geolocate data files in cloud datacenters. OVERVIEW OF CLASSIFICATION BASED IP GEOLOCATION CBIG approach adopts a machine learning based technique by training a model using network measurements and societal characteristic features. The network measurements are collected between landmark and target nodes. The landmark nodes are selected PlanetLab computers in the United States. The target nodes are Internet routers discovered by conducting a mesh traceroute between groups of PlanetLab computers. The CBIG employs a Naive Bayes framework to convert network measurements between the landmark and target nodes to distances. Let the network measurements from landmarks to single target be set M = {m, m 2,..., m j }, where m j = {m jk } and k =, 2, 3, 4, 5, 6 (where the total number of measurements to the target IP address is given by M = 6j). A set of non-negative estimation weights {λ k } is introduced for each feature to reflect the importance and contribution of that feature in the overall classification process [3]. Another set of estimation weights {γ k } is introduced to order the landmarks. A landmark with the smallest feature measurement values weighs most and informs the classifier more accurately than a landmark with the largest values. The weight parameter values will be chosen by the least squares parameter estimation method. The method minimized the sum of squared distance errors between the training set of IP addresses known locations and the estimated locations. Using Naive Bayes framework, the CBIG estimates the county (ĉ) of the target IP addresses as: λ k j= ĉ = arg max( c C 5 k= J exp( j.γ k )log p(m jk ) + λ 6 log p(c)) where J is the total number of measurements from landmarks to the target IP. 2 CBIG TO GEOLOCATE CLOUD USER DATA IN DATA CENTERS We present the implementation of the CBIG approach to geolocate cloud user data ASE 24 ISBN:

4 24 ASE BIGDATA/SOCIALCOM/CYBERSECURITY Conference, Stanford University, May 27-3, 24 Figure : Experimental setup Setup Cloud User Accounts: Multiple cloud user accounts were setup for two categories of services (storage and web services) in four cloud providers (AWS, Google AppEngine, Rackspace and Microsoft Azure). The storage service on each account allowed use to upload user data files of various sizes. Similarly, the web services allowed hosting web pages on each of the four accounts. Cloud Users: Automated scripts were setup on PlanetLab nodes in various cities in the United States were selected to download web pages and user data files from the four cloud providers. The scripts were setup to mimic the activity of cloud users who wish to access the two cloud services from each of the four cloud provider accounts.the scripts accessed the cloud services at random points in time throughout each day for 2 months. Landmark nodes: PlanetLab servers will be chosen to serve as landmark nodes. We have chosen responsive PlanetLab nodes since the landmark nodes need to be stationary and reachable from each other. Cloud Users to Datacenter Network Measurements: Network measurements between clouser users and cloud datacenters will be generated when each cloud user downloads web pages or user data files while accessing either of the two ASE 24 cloud services. As the cloud user accesses the cloud services, we record the Internet protocol (IP) addresses, average latency and hop count. The IP address changes on every subsequent download request from the cloud user. Landmark nodes to Datacenter Measurements: The IP addresses of datacenters collected from the download activities of cloud users were used to generate similar network measurements are collected between landmark nodes and datacenters. Training dataset: We identify the network characteristic features (average, standard deviation, median and mode of network delay and hop count) and societal characteristic feature (population density) from the MaxMind database. The training dataset is extracted from network measurements between landmark nodes and Internet routers which were discovered by performing a full mesh traceroute between groups of PlanetLab nodes in United States. As the location of the Internet routers encompass all the cities where data centers for the cloud providers reside, our training dataset will be sufficient to estimate the location of user data in cloud datacenter. Classifier Training: CBIG approach based on the Naive Bayes framework is implemented as described in and the classifier is trained using ISBN:

5 IV the training set generated in the previous step. Classifier Evaluation: Finally, we evaluate the accuracy of the classifier by using a 5-Fold Cross Validation approach. EXPERIMENTAL SETUP To assess the accuracy of the CBIG approach, we evaluate the classifier on a real-world environment involving commercial cloud providers such as Amazon Web Services [6], Microsoft Azure [7], Google App Engine [8] and Rackspace [9]) and PlanetLab [5]. In our experiments, we only considered CDN services on AWS and Azure and storage services on AWS, Rackspace, and Google AppEngine. CLOUD SERVICE PROVIDERS by repeatedly downloading data files from cloud datacenter. For example, one of the website URLs provided by Amazon CDN service was d36j3gdmlvl6k. cloudfront.net. Every web page download from the website resulted in a different IP address associated with the URL. Datacenter location information can be obtained by ICMP echo (Ping) requests to datacenter IP. The ICMP reply message includes datacenter location (i.e. server name) information. The data center location information contains the city airport code where it is located. For instance, a reply from Microsoft Azure has server name cds9.iad9.msecn.net ( ), iad airport is in Dulles, Virginia and another from Amazon AWS has server jfk6.r.cloudfront.net ( ), jfk is in New York, NY. We employed not only domain name resolution to verify the location information is correct [] but also checked if the provider has a datacenter the same city. Cloud users have several commercial cloud providers to choose from depending on the type of service. In our experimental setup, we chose four popular commercial cloud providers: Amazon Web Services, Rackspace, Google App Engine and Microsoft Azure. To emulate various cloud services, we created cloud data stores on each of the cloud providers and uploaded different size of data files and used content delivery network to host data over the internet. 2 LANDMARK NODES To evaluate the accuracy of our approach from geographically disparate and diverse locations, we download cloud data files from reliable and suitable landmarks. We chose the landmark nodes from Planet- Lab, a group of computers available at different parts of world for computer networking and distributed systems research. PlanetLab is a live test-bed and currently has 72 nodes available worldwide [6]. There are 45 PlanetLab nodes available in the United States. Out of the 45 nodes, we used 9 alive and responsive nodes for landmarks. We tested the alive and responsiveness of the landmarks based on ICMP echo responses. 3 CLOUD DATACENTER IP DISCOVERY Datacenter IP addresses are critical to our approach because all network measurements (i.e. used as features) are carried between PlanetLab nodes and datacenter IPs. We gather unique datacenter IP addresses 4 GENERATING TRAINING DATASET To generate the training dataset, we collect instantaneous delay and hop count measurements from each of the 23,843 routers to the 67 landmarks [2]. For the instantaneous delay data, we send 4 ICMP echo request from each landmark to all the routers. Based on the instantaneous delay measurements, we calculate the average, standard deviation, mode and median of delay for each router from each landmark, which results in 67 23, = 6, 389, 924 measurements. Using traceroute to collect hop count measurements causes excessive overhead on the core routers. To avoid this overhead we send a single ICMP echo request from each landmark to all targets. We then use this request to calculate the hop count of the reverse path [3, 8]. V EXPERIMENTAL RESULTS The trained CBIG was evaluated by test datasets generated with measurements obtained from different cloud providers. Prior knowledge of datacenter location helps to verify more accurately the predicted location of the test cloud datacenter from where a test dataset (network measurements) is obtained. To show our model s flexibility, we extend our verification process to two cloud services, such as storage and content delivery network (CDN). ASE 24 ISBN:

6 ,Std,Hop ,Std,Hop (a) (b) Figure 2: Geolocation accuracy of cloud CDN Servers. (a) Amazon Web Services and (b) Microsoft Azure ,Std,Hop ,Std,Hop (a) (b) (c),std,hop Figure 3: Geolocation accuracy of cloud Storage. (a) Amazon S3, (b) Rackspace and (c) AppEngine GEOLOCATING CLOUD CDN SERVERS Content Delivery (CDN) servers are usually large distributed infrastructure deployed in multiple cloud datacenters. Cloud content delivery networks such as Amazon s CloudFront and Azure s CDN are used to distribute content (data) across internet. In cloud CDN service, client s data gets distributed across the servers in the cloud network. As the location of these servers spans the world, there is a possibility of cloud users data being stored in cities which are more prone to natural disasters and power outages. Fig. 2 illustrates the cumulative distribution of the error distance. Cumulative distribution function (CDF) is used to map values to their percentile rank in a distribution. For each IP address, an error distance between the predicted location and actual location is calculated using haversine distance formula [7] (latitude and longitude of datacenter locations are used as input in the haversine formula). Based on error distance of each IP address, these are sorted first and then assigned with cumulative probability values. Table shows the impact of combination of features on classification accuracy for Amazon AWS and Microsoft Azure. It is clear that combination of features ASE 24 ISBN:

7 Cloud Service Provider Table : Classification Accuracy IP Addresses Ave Ave Std Hop Amazon Web 35 6% 75% Services Microsoft Azure 43, 63% 85% Figure 4: Distribution of PlanetLab Nodes in USA such as average () delay, standard deviation (Std) delay and hop count (Hop) has more classification significance over feature Average () alone. For Amazon AWS, out of 35 IP addresses, 6% of IPs reported less than 2 miles error distance only with one feature (average delay) and 75% of IPs reported less than 2 miles error distance with combination of three features (average, standard deviation delay and hop count). For Microsoft Azure, out of 43, IP addresses, 63% of IPs reported less than 2 miles error distance only with one feature (average delay) and 85% of IPs reported less than 2 miles error distance with combination of three features (average, standard deviation delay and hop count). 2 GEOLOCATING CLOUD STORAGES Online storage providers like Dropbox, SkyDrive and Google Drive use cloud storage to store files. To geolocate cloud storages we have considered Amazon S3, Rackspace and Google App Engine. In the verification process of cloud storages, for each cloud provider s storage IP address, the error distance is calculated between the predicted datacenter location and nearest datacenter of that cloud provider using haversine distance formula [7]. The total number of Table 2: IP Geolocation errors Average Error (mi) AWS Ashburn, VA New York, NY Dallas, TX Miami, FL 264 Jacksonville, FL 5 Los Angeles, CA 9 San Jose, CA 2 Newark, NJ Palo Alto, CA 64 Seattle, WA 669 Rackspace Grapevine, TX Ashburn, VA Chicago, IL 5 Azure Los Angelees, CA Fairfax, VA San Antonio, TX 63 Chicago, TX 9 Ap- Google pengine Cloud Provider Datacenter Location Lenoir, NC 38 Douglas County, GA Mayes County, OK 4 The Dalles, OR 23 Council Bluffs, IA 375 storage IPs verified for Amazon S3 is 9, Rackspace is 9 and Google App Engine is 7. Fig. 3 compares the geolocation accuracy for Amazon S3, Rackspace and Google App Engine respectively. 3 GEOLOCATION ACCURACY OF CLOUD DATACENTER CITIES Fig. 4 shows the distribution of PlanetLab nodes in United States (source /image/-s2.-s gr5.jpg). To show the impact of PlanetLab nodes distribution on the accuracy of datacenter geolocation, we present the geolocation of cloud datacenters at the city level granularity. Table 2 presents the average error distance across different cloud datacenter cities. Rich concentration of PlanetLab nodes in cities produce low error distance when compare to cities with very few PlanetLab nodes. ASE 24 ISBN:

8 VI CONCLUSION We presented CBIG, a classification based IP Geolocation approach to locate cloud user data in cloud data centers to verify availability. CBIG is based on a Naive Bayes machine learning framework and utilizes six features from network measurements and societal characteristic. CBIG appears promising in geolocating datacenters for the four commercial cloud providers. The experimental evaluations demonstrate that high classification accuracy is obtained by utilizing only three features (average delay, standard deviation delay and hop count). The remaining three features do not pose a significant increase in geolocation accuracy. For future work, we would like to investigate in features which can further improve the geolocation accuracy. We also plan to enhance CBIG to detect violation of location restrictions in SLA. In this paper, we presented an approach to accurately geolocate cloud datacenters on the base of city level granularity. The approach assumes that the network measurements are not tampered or maninpulated and the experiments were only conducted on available cloud datacenters located in United States. For future work, we will evaluate the accuracy of the proposed approach geolocate cloud data centers in presence of network measurements which have been deliberately modified by adversaries external or internal to the cloud provider. ACKNOWLEDGMENT This work was partially supported by National Science Foundation (NSF) Grant HRD-37466, NSF HBCU-UP Targeted Infusion Grant HRD-37544, AFOSR grant FA , Department of Homeland Security(DHS) SLA grant 2-ST-62-4, 2-ST It is also based upon work supported by the AFRL/RI Information Institute VFRP No. R7379. References [] K. Benson, R. Dowsley and H. Shacham, Do You Know Where Your Cloud Files Are?, In Proceedings of CCSW 2. ACM Press, Oct. 2. [2] H. Maziku, S. Shetty, K. Han and T. Rogers Enhancing the Classification Accuracy of IP Geolocation, MILITARY COMMUNICA- TIONS CONFERENCE, 22 - MILCOM 22. [3] B. Eriksson, P. Barford, J. Sommers, and R. Nowak, A learning-based approach for IP geolocation, Passive and Active Measurement Workshop, 2. [4] Gondree, Mark and Peterson, Zachary N.J., Geolocation of data in cloud, CODASPY 3 Proceedings of the third ACM conference on Data and application security and privacy, 23. [5] A. Bavier, M. Bowman, B. Chun, D. Culler, S. Karlin, S. Muir, L. Peterson, T. Roscoe, T. Spalink, and M. Wawrzoniak, Operating System Support for Planetary-Scale Network Services, in USENIX NSDI 4, March 24. [6] Amazon Web Services,Cloud Computing(AWS) [7] Microsoft Windows Azure [8] Google App Engine [9] Rackspace [] Albeshri, Aiiad Ahmad, Boyd, Colin, & Gonzalez Nieto, Juan M., Geoproof : proofs of geographic location for cloud computing environment, 3rd International Workshop on Security and Privacy in Cloud Computing (Part of the 32nd International Conference on Distributed Computing Systems Workshops (ICDCS 22). [] G. Hancke and M. Kuhn. A RFID distance bounding protocol. In IEEE/Create-Net SecureComm, pages IEEE Computer Society Press, 25. [2] Watson, Gaven J. and Safavi-Naini, Reihaneh and Alimomeni, Mohsen and Locasto, Michael E. and Narayan, Shivaramakrishnan, LoST: Location Based Geolocation, CCSW 2 Proceedings of the 22 ACM Workshop on Cloud computing security workshop. [3] U.S. Census Bureau [4] Online 24/amazon-aws-takes-down-netflix-onchristmas-eve/ [5] Online ASE 24 ISBN:

9 [6] Online to-refund-windows-azure-customers-hit-by-2- hour-outage-that-disrupted-xbox-live/ [7] Haversine Distance formula [8] H. Wang, C. Jin, and K. Shin, Defense against spoofed IP traffic using hop-count filtering, IEEE/ACM Transactions on Networking, 27. [9] N. Paladi, C. Gehrmann and F. Morenius, State of The Art and Hot Aspects in Cloud Data Storage Security, SICS technical report, March 23. [2] I. Youn, B. Mark, and D. Richards, Statistical geolocation of Internet hosts, International Conference on Computer Communications and Networks, 29. [2] B. Gueye, A. Zivian, M. Crovella, and S. Fdida, Constraint-based geolocation of Internet hosts, IEEE/ACM Transactions on Networking, 26. [22] S. Laki, P. Matray, P. Haga, T. Sebok, I. Csabai, G. Vattay, Spotter: a model based active geolocation service, IEEE INFOCOM, 2. [23] P. Gill, Y. Ganjali, B. Wong, and D. Lie, Dude, where s that IP? Circumventing measurementbased IP geolocation, USENIX Security Symposium, 2. [24] American Registry for Internet Numbers (ARIN) [25] MaxMind - IP Geolocation and Online Fraud Prevention [26] Neustar - IP Intelligence & IP Geolocation Service (formerly Quova) ASE 24 ISBN: