Secure Networking for Virtual Machines in the Cloud

Secure Networking for Virtual Machines in the Cloud Miika Komu, Mohit Sethi, Ramasivakarthik Mallavarapu, Heikki Oirola and Rasib Khan Aalto University, Department of Computer Science and Engineering [email protected]

Abstract—Cloud computing improves utilization and flexibility of allocating computing resources while reducing the infrastructural costs. However, cloud technology is still proprietary in many cases and is tainted by security issues rooted in the multi-tenant environment of the cloud. For instance, the virtual machines of two competing companies could be served by the same underlying host machine in an Infrastructure as a Service (IaaS) type of cloud and this represents a security threat to be addressed. As a solution to this multi-tenancy problem, the Host Identity Protocol (HIP) offers a standardized way to authenticate and protect data flows between tenants belonging to the same security domain. In this paper, we have experimented with HIP in order to address the multi-tenant challenges for public and hybrid IaaS clouds. In our design, developers and administrators can access cloud services directly over HIP, whereas consumers access the cloud without HIP using a reverse HTTP proxy. The proxy also acts as a load balancer for a distributed test service deployed both in an EC2 public cloud and a private cloud. The performance of the system offers efficiency comparable to SSL and essentially utilizes the same cryptographic algorithms with similar processing costs. Consequently, this implies that the proposed scheme is a viable alternative to mitigate some of the privacy issues related to multi-tenancy within a single data center and to secure communications between two clouds in the case of a hybrid cloud.

I. I NTRODUCTION In cloud networking, multi-tenancy is problematic, especially with public clouds. For instance, co-locating two competing companies in the same physical host can raise some privacy concerns unless tenants are properly isolated from each other. As another security challenge, hybrid clouds introduce inter-cloud communications that has to be properly authenticated and protected to avoid abuse. In this paper, we propose an architecture to improve security for multi-tenant and hybrid clouds. Our architecture is based on the standardized Host Identity Protocol (HIP) but instead of its typical end-to-end deployment model, we propose it to be used in an end-to-middle manner to avoid unnecessary deployment hurdles at the consumer side. To be more precise, we employ HIP only for inner-cloud or intra-cloud communications to tackle the security challenges related to multi-tenancy and hybrid clouds. The proposed approach can be incrementally deployed by the tenants independently of the cloud provider, for instance in commercial clouds such as Amazon EC2. Further, the use of HIP facilitates topology-independent access control, VM

Sasu Tarkoma University of Helsinki [email protected]

migration, NAT traversal, IPv6 interoperability and limited protection against DoS attacks. Our main contributions of this paper are a novel application of HIP in cloud environment, design analysis and empirical performance measurement to understand the scalability limits of the approach. As practical results, we show that it is feasible to use HIP inside an IaaS cloud using a reverse HTTP proxy. Further, the HIP-based approach offers comparable performance to TLS when securing web and database transactions. Finally, our measurements indicate that NAT traversal based on HIP and Teredo offers reasonable performance for cloud developers and administrators. The paper is organized as follows: Section II offers background information on cloud computing, data center networks and identity-locator split; Section III examines some security issues and risks that exist in cloud deployments to date; application of HIP to cloud computing is discussed in Section IV; Section V describes the design and performance results from our experimental test deployment; Section VI compares our work with related approaches; and Section VII presents future work. II. BACKGROUND In the cloud computing paradigm, computational resources, software services and storage are served and paid for as a utility, scaling dynamically according to the needs of the customer. Outsourcing of computing and other resources to the remote server farms of a cloud provider allows enterprises to reduce the costs of infrastructure, energy and maintenance work. Cloud service models [1] can be categorized into Software-as-a-Service (SaaS), Platform-asa-Service (PaaS) and Infrastructure-as-a-Service (IaaS) of which we focus on the last one in the context of this paper. In addition, four main deployment models exist: public, community, private, and hybrid clouds. Our proposed approach improves multi-tenant security in public and especially hybrid clouds. Another paradigm for the Internet architecture is identitylocator split, which offers a number of benefits and solutions to the challenges of the Internet architecture. Host Identity Protocol (HIP) is one of the realizations of this split and the foundation of our design. This section provides a brief overview of cloud computing, id-loc split split and HIP.

A. Data Center Networks Virtualization is technology that facilitates sharing of the common infrastructure and resources of a physical machine (e.g., CPU, storage and network interfaces) between several Virtual Machines (VM), each hosting an entire software stack, including the operating system and applications. VMs are controlled by a layer of software called a hypervisor, which resides between the hardware platform and the VMs. The hypervisor supports creating, migrating and terminating virtual machine instances. It is also a very critical component in virtualization environments; when breached, all of the attached virtual machines are compromised. With the introduction of virtualization technology, physical servers are now capable of hosting tens or hundreds of virtual servers and massive data centers. The number of servers is no longer limited by, e.g., the number of ports in switching devices. Data center networks can be divided into four main categories from the view point of deployment. Public clouds offer their services via the Internet to everyone, whereas private clouds are internally operated and used by a single organization. Private clouds offer increased reliability, control, and security, because access to the services may be limited to the internal network of a company. A community cloud can be deployed by two or more organizations with similar service requirements. A hybrid cloud is a set of separate, possibly different types of cloud instances interconnected with each other. B. Host Identity Protocol In the current Internet architecture, hosts are both identified and located by their IP addresses. When a host moves from one network to another, its IP address changes to correspond to the new local topology. Consequently, any ongoing sessions based on TCP break because vanilla TCP is tightly coupled with IP addresses. While this may not have a large impact on short-lived HTTP transactions, it can be problematic with long-lived multimedia streams and other protocols such as Secure Shell (SSH). As an architectural solution for such mobility-related problems, Identity-locator split separates the dual role of IP addresses. It proposes a separate namespace for the upper layers in the networking stack, isolating transport and application layers from the underlying topological changes to facilitate IP-address mobility. Host Identity Protocol (HIP) [2] has been standardized by the Internet Engineering Task Force (IETF) and it implements the identity-locator split at layer 3.5, that is, at a shim layer between transport and network layers. HIP employs cryptographic identities to avoid impersonation attacks. The physical representation of an identity in HIP is called the Host Identifier (HI) and it is essentially the public-key component of a private-public key pair. To have a more compact representation of the HI for HIP control messages and API calls, the specifications define

a Host Identity Tag (HIT) which is a 128-bit hash of the public key with a special IPv6 prefix. Local-Scope Identifier (LSI) is a locally assigned IPv4 address that corresponds to a certain HI. With HIP, application and transport-layer protocols use HITs instead of IP addresses. The HIP layer is responsible for translating HITs into IP addresses and vice versa. The HITs of remote hosts can be preconfigured statically or, alternatively, they can be looked up dynamically from the DNS [3] or from a distributed hash tables [4]. HIP facilitates IPv4-IPv6 interoperability at two different layers. At the application layer, IPv6 applications can use HITs and IPv4 applications can use LSIs [5]. The two can be mixed so that an IPv4-based end-host can communicate with an IPv6-based end-host. Similarly, HIP is also addressfamily agnostic at the network layer: HIP packet flows can be either based on IPv4 or IPv6, independently of what the application uses. It should be noted that it is also possible to switch between the two on the fly [6]. When an application delivers data using a pair of LSIs or HITs, the HIP layer intercepts the data flow and requires the two communicating hosts first to authenticate each other using the HIP Base EXchange (BEX) [7] procedure. The BEX itself and all subsequent HIP control messages are always signed with the public keys (HIs). The BEX also includes a computational puzzle that the server can use to delay clients when it is under heavy load. During a BEX, two hosts also create symmetric keys to protect the actual application data. By default, BEX establishes a bi-directional, secure IPsec tunnel between the two hosts. Minimally, the IPsec tunnel authenticates and protects the integrity of the packets but typically also ensures the confidentiality for the packets. The default IPsec mode in HIP is called bound end-to-end tunnel (BEET) ESP [8] mode which is more bandwidth-efficient than the tunnel mode. The details of security are configurable and also IPsec can be replaced with other schemes [9]. When a HIP-capable host changes its location, it informs all of its connected peers about its new whereabouts in order to sustain connectivity. To avoid replay attacks, the message includes a random nonce which a peer must send back [10]. If two communicating hosts relocate simultaneously, a rendezvous server [11] can optionally be used to improve reachability. As an alternative to rendezvous, DNS with small time-to-live values for HIP-related records can be used for re-contact [12]. When a host is behind a NAT device, HIP can be used for automatized NAT penetration instead of opening ports manually. HIP has its own extensions for the penetration procedures [13]. However, Teredo [14] offers IPv6-overIPv4 tunneling that can also be combined with HIP [15] as well. In both cases, the use of statistically unique identities of HIP simplifies naming of the hosts in the overlapping private address realms as introduced by NATs.

III. S ECURITY I SSUES IN C LOUD N ETWORKS Many issues still exist that hinder the adoption of cloud services and may lead to a failure of the cloud model [16]. As cloud computing largely consists of existing technologies (e.g., service-oriented architecture, virtualization and utility computing), many of the related security issues are wellknown problems. However, the distinct multi-tenant environment of the cloud complicates the issues more than in the traditional context. Cloud networks face security threats from both inside and outside the cloud. Security problems are significant especially in public clouds [17]. Organizations tend to be hesitant towards migration to the cloud because of the associated security risks. This section presents some of the general security challenges in cloud computing technologies. The set of challenges presented here is not inclusive; only some of the most relevant challenges from the viewpoint of multi-tenancy are discussed. A. Protection of Data Flows In cloud infrastructures, VMs of different customers may reside in the same physical network [18] through which data traffic generated by the VMs is transported. This causes considerable concern especially for enterprises, for which it is necessary to protect the confidentiality and integrity of their business-critical data. In many data center applications, the amount of internal traffic between servers residing inside the data center outweighs the external traffic [19, 20]. Hence, data traffic also needs to be protected internally between servers (i.e., between virtual machines). A VM image may contain proprietary software and confidential data that has to be protected. Cloud service providers need to secure their systems from threats related to communication, monitoring, modification and migration of VMs. As the cloud deployments are multi-tenant environments, they have a risk of leaking information to outsiders if the (virtual) resources of different customers are not perfectly isolated. This affects particularly the IaaS delivery model, because it serves as the foundation for all other delivery models [21]. The VM hypervisor represents another attack surface because it exposes its management interfaces and communications to the network. In addition, the cloud system administrator may have access to the data of customer VMs, which represents an inherent security risk [22]. The strength of private clouds is that control of the physical infrastructure is retained, and the cloud owner has direct control of security policies and governance. The situation is different in hybrid or public clouds, since the cloud subscriber loses control of both the physical and logical aspects of the system [17]. The data is out of the control of the data owner, and thus, sufficient protection features (e.g., encryption) are required.

B. Isolation of Subscriber Resources A major security issue is to isolate computing resources and networks of individual cloud subscribers. Existing cloud deployments are mainly public systems that are exposed to more attacks when compared to private in-house IT environments [23]. The same cloud infrastructure can be shared with different, possibly competing organizations. The high degree of multi-tenancy in a public cloud exposes it to attacks originating from inside the cloud. In the IaaS service model, the attacks can include, e.g., Distributed Denial of Service (DDoS), man-in-the-middle attacks and IP spoofing. The cloud subscriber should be concerned about information theft and possible attacks by other cloud users. To overcome this problem, techniques such as network and host virtualization can be used to isolate users from each other. For example, Virtual Local Area Networks (VLAN) offer logical network segmentation. VLAN partitioning segregates and isolates traffic between different user groups or subnets. A management layer must guarantee that a cloud subscriber is unable to snoop the network packets of another subscriber or access the memory of another subscriber’s VMs [24]. C. Outsourcing Private Data Most organizations are not willing to store their data and applications on systems outside their own physical security perimeter [25]. Usually, the cloud subscriber has no control over the cloud provider’s infrastructure or the changes the provider applies over time. As a result, data stored in the cloud is out of the control of its owner, and it is important for the cloud vendor to take responsibility for providing a secure cloud infrastructure. Hence, a strong trust relationship between the cloud provider and the subscriber is needed, agreeing on which security measures to use. The information handled by an outsourced service may be vulnerable to unauthorized access, data leakage, modification, or loss of data. Making things worse, the cloud provider may not provide sufficient monitoring capabilities to its customers because of the possibility of information leaks on other customers residing inside the same cloud deployment. For example, a customer of a cloud provider may not necessarily have direct access to its security audit logs. If this is the case, some security incidents might remain unnoticed. To ensure privacy, computation over encrypted data can be implemented utilizing fully homomorphic encryption (FHE) [26]. However, it fails to accommodate situations where multiple clients are interested to utilize services over the same data, residing in the cloud provider’s server, provided the confidentiality is preserved [27]. The lack of access control within the encrypted content limits the computational feasibility for multi-client access and operation in the cloud using FHE and similar cryptographic approaches. However, Popa et al. in [28] have presented CryptDB, a

generic proxy server for databases. It applies an onions of encryption scheme on the objects. Additionally, CryptDB includes encryption keys chained to user passwords, and each object can only be accessed with a chain of keys. The keys chain is applied against the access control policies on the data objects, and hence allows individual users and user groups to run SQL queries over the encrypted data. D. Security in Hybrid Clouds Contrary to the public cloud deployment model, the aim of private cloud deployments is not to sell computing capacity over the Internet utilizing publicly accessible interfaces, but rather to give local subscribers a scalable and private infrastructure to run service workloads within their own administrative domain. Private clouds can also employ a hybrid cloud model where the local infrastructure is backed up by leased computing power from an external public cloud. This allows handling of occasional peak loads and maintaining availability during temporary service outages or maintenance breaks. One of the greatest challenges for security in such hybrid environments is the cooperation of different security mechanisms. Adaptation of one security mechanism with another sometimes provides a point of leverage for attackers. Consequently, solutions for separate security federations need to be introduced, such that providers can utilize a unified security mechanism. IV. D ESIGN A NALYSIS In this section, we provide high-level argumentation how HIP meets the challenges related multi-tenancy and hybrid clouds. Then we also discuss the other benefits to cloud environments and conclude with insight on deployment perspective. A. On Multi-tenancy and Hybrid Cloud Security A VM serves as the abstract unit of deployment in the cloud [16]. This seems to match with HIP architecture because it is essentially a host-based solution. HIP could be used in the cloud in the following scenarios: I) Identify virtual hosts with HITs; cryptographically secured VM identities would enable authentication, access control, secure tunneling between virtual hosts and a new way of addressing hosts in a topologically-independent way inside a data center. II) Identify VM hypervisors and network equipment with HITs; this supports easy configurability and secure control of different network equipment (e.g., load balancers, switches and other configurable middleboxes), and a secure channel for migrating VM state between two physical hosts. With HIP, the identification of hosts can be achieved with several means. In scenario I, tenant-to-tenant authentication can be achieved transparently from application by employing access-control mechanisms operating at the system level [5].

For instance, all Linux-based systems support “hosts.allow” and “hosts.deny” files. As an more intrusive alternative, the application can be modified to become HIP aware [29]. For both scenarios, a HIP-based firewall [30] can be used; in the first scenario, the firewall is installed at the end-host and in second scenario, the firewall is installed to middlebox such as the hypervisor. The cloud provider is responsible for securing the cloud infrastructure, and the cloud application developer needs to take care of application security. Thus, mechanisms are needed to ensure strong isolation and secure communications between VMs inside the cloud [16]. If the application consists of many logically separate components that run on different VMs, they usually need to communicate with each other. With HIP, the communicating hosts can be cryptographically authenticated, ruling out the possibility for impersonation attacks. Packet flows between the hosts are protected with secured tunnels established using HIP. Thus, HIP offers a solution to mitigate the security issues related to multi-tenancy. Hybrid clouds are composed of many interconnected components and applications often depend on shared services (e.g., directories, databases and user identity management), which can be located in a private data center. If an organization outsources only parts of its IT environment to a third-party cloud, it should be possible for those components to access securely the components residing in the organization’s private network. In such a case, HIP can authenticate and protect the traffic between private and public clouds, thus offering a security solution for hybrid cloud security. B. On Processing Costs Cloud networking allows distributing the same service to different locations. This protects the cloud against clientside DDoS attacks in a relatively economical way. Assuming HIP were eventually deployed on client-side devices, its computational puzzle mechanism would further enhance the (D)DoS protection of cloud networking. The puzzle mechanism can also be useful against insider attacks in the cloud. However, we did not delve in to this matter in this paper as it has already been studied by others [31–33]. Security based on cryptography introduces additional processing costs that are further amplified by the cloud environment to increase the power consumption of a data center. Similarly as SSL, also HIP minimizes the number of the computationally intensive operations. Only the control plane employs intensive asymmetric key operations during the key exchange or handover procedures, where as the data plane utilizes light-weight symmetric keys. While cryptographic hardware accelerators could be used to optimize the power consumption, we have chosen to use commodity hardware in the experiments later. It should be noted that the latest version of HIP supports also elliptic-curve cryptography [34]

that can curb the processing costs without hardware acceleration. C. Other Benefits for IaaS Clouds As mentioned earlier, HIP facilitates IPv4-IPv6 interoperability at two layers, application and network layers. In cloud networks, IPv4- and IPv6-based services can be seamlessly connected using LSIs and HITs at the application layer. At the network layer, HIP allows IPv4-based applications to communicate over an IPv6 network due to flexible tunneling, and also supports IPv4-IPv6 handovers [15, 35]. This can be useful when migrating a VM from an IPv4-only host to a dual-stack host. VM migration can be important for efficient management of resources or load balancing reasons. Solutions for VM live migration may require that the source and destination hosts reside on the same layer 2 network to avoid changing the IP address of the VM. This can limit the cloud service provider’s ability to design and build data center networks. It can also constrain distribution of load efficiently inside a data center or between data centers in different geographical locations. Furthermore, according to some sources [19, 20], network infrastructure and IP addressing hierarchies limit the ability to dynamically reassign servers for the applications running in a data center. As described earlier, HIP is agnostic regarding the address family and supports even NATted topologies. Further, moving a VM image over the network incurs a security risk [21] which can be mitigated with HIP. However, VM migration will not be in the focus of our experiments as VM migration with HIP has already been studied by others [36]. D. Deploying HIP to the Cloud In general, adopting a new protocol is challenging if it requires changes to applications, network stacks or infrastructure. HIP does not mandate changes in applications and the protocol changes required for network stacks are available for all major platforms 1 . Infrastructural changes are related to new DNS records which are already supported in Bind, a popular DNS server software. Despite all the efforts, HIP has not yet been widely deployed. Particularly, deploying it to millions of clients is challenging as servers do not support it yet and this effectively results in a chicken and egg problem. However, one success case is the HIP deployment at a Boeing factory [37]. One could argue that a key to their success was that they were in control of the facility and HIP was used just internally. To repeat Boeing’s success, we believe that HIP should be deployed primarily inside the cloud or between two clouds. Depending on the cloud model, the visibility of HIP to the cloud subscribers varies: in SaaS it is completely invisible, in PaaS it is semi-visible, and 1 OpenHIP, HIP for inter.net and HIP for Linux cover BSD, OS-X, Windows and Linux platforms

in IaaS it is fully visible. Since IaaS seems to be the most challenging deployment scenario, we choose it as our experimental model for the paper. To the actual users of the cloud service, HIP can remain completely invisible if it is hidden behind server-side proxies. A common way to design scalable web services is to use HTTP or TCP load balancers at the server side. In our deployment scenario, HTTP load balancers translate nonHIP traffic into HIP-based traffic inside the cloud. While HIP inside the cloud is our primary deployment target, our secondary targets are special groups of people. HIP could be adopted by “power” users, i.e., cloud application developers and administrators who access and manage VMs and hypervisors, and will be protected using public key authentication. As IPv4 addresses are becoming a scarce resource, the power users could access the machines in the cloud flexibly either over IPv6 or with HIP-over-Teredo in the case of a NATted network. V. E XPERIMENTATION From the view point of traffic volumes, it is not uncommon that the sheer traffic volumes inside the data center exceeds the external traffic. Therefore, we measured the performance of our approach to understand the scalability aspects. We created an experimental testbed to simulate a latency-critical multi-tier web service, in order to study the scalability implications of employing secure protocols for inter-VM communication. Rubis 2 , Rice University Bidding System is an online auction site prototype that we used as a multi-tier web service deployed in a cloud environment. Rubis was modeled after ebay to study and understand the application design patterns and performance bottlenecks. We also collected some throughput measurements in order to understand the effects of these security protocols on HTTP downloads. A. Configuration and Test Set-up We configured a high-performance server as a reverse proxy (load balancer) to distribute the load between multiple VMs deployed in a virtualized cloud environment. The load balancer was located outside the cloud environment. In order to simulate a realistic deployment scenario of a multi-tier web service, we connected multiple lightweight web servers to a high performance database server. Figure 1 depicts the architecture of our test setup. We carried out the public IaaS cloud deployment experiment with Amazon EC2. The Ubuntu 10.10 server edition was the operating system used for all the VMs in the experiment. The web servers connected to a single large database server in order to read or write data. In Amazon EC2, we used 3 EBS (Elastic Block Store) backed micro instances (613 MB of memory and up to 2 RUBiS,

an auction site prototype, available: http://rubis.ow2.org/

B. Performance Results

Client 2

B a l a n c e r

Client 3

Client n

Figure 1.

Public/Private IaaS cloud architecture

2 EC2 compute units of processing) as web servers and an EBS-backed large instance (7.5 GB of memory and 4 EC2 compute units of processing) running MySQL server (version 5.1) 3 as the database server. EBS provides block level off-instance and persistent storage for Amazon EC2 instances 4 . HAProxy (version 1.3.22) 5 was used as the load balancer to distribute incoming requests to the virtualized web servers deployed in the cloud. A simple round robin algorithm was employed to distribute the incoming load to the web servers for processing. In our experiments with Rubis, we used jmeter (version 2.3.4) 6 and httperf (version 0.9.0) 7 for workload generation and periodic monitoring of the response times. The main focus of the experiment was to test the performance implications of using HIP in a multi-tenant public IaaS cloud environment. Although enough care was taken to conduct all the experiments in the amazon EC2 simulataneously, public clouds by nature are multi-tenant and only provide VM-level access control to the users. Hence we decided to repeat the experiments in a private cloud based on OpenNebula (version 3.0) 8 , in order to cross-check the validity of the results. Consequently, the results from the private cloud experiment were very much aligned with the public cloud experiment results. VM instances in all experiments were deployed in the EU region in the availability zone eu-west-1a. HIP and SSL connectivity was restricted to virtual machines deployed in the IaaS cloud environment. One of the popular alternatives, OpenVPN uses OpenSSL and hence SSL was used as an alternative to compare the performance of HIP. Unless separately mentioned, we used IPv4-based networking for all measurements.

3 http://dev.mysql.com/downloads/mysql/5.1.html 4 Amazon

EC2 Instance Types, available: http://aws.amazon.com/ec2/

5 http://haproxy.1wt.eu/ 6 Jmeter,

available: http://jakarta.apache.org/jmeter/ available: http://www.hpl.hp.com/research/linux/httperf/ 8 OpenNebula, available: http://opennebula.org/ 7 Httperf,

We evaluated the performance of the Rubis software that was distributed across multiple VMs. In order to have a point of comparison, we performed tests with both HIP and SSL. We also tested the performance without any security (referred to as “basic scenario” henceforth) to better understand the impact of security. We generated requests with several concurrent clients continuously generating random HTTP GET requests that resulted in queries to the database server. Then we calculated the average throughput (the number of successful requests served per second), for the three scenarios. Database caching was not employed for this experiment. Figure 2 shows the throughput of the basic, HIP and SSL scenarios. The basic scenario has the least amount of overhead when compared to the other two scenarios. In almost all of the cases, the performance of HIP was comparable to that of SSL. With the increase in the number of concurrent clients, the difference in the throughput of the basic and other scenarios is clearly visible. In the experiment with 50 concurrent clients, the performance of HIP was only slightly lower in comparison with SSL. We attribute this to the fact that the HIP experiments were carried out with LSIs which incur a bit more performance penalty due to some extra translations. As the number of concurrent clients grows, the throughput increases until it reaches a threshold beyond which the overall performance suffers. With 50 concurrent clients, the throughput of HIP and SSL was beginning to decline, while the throughput of the basic case surged ahead with a significant difference. Basic HIP SSL

250

200

Throughput

L o a d

Private/Public IaaS

Client 1

150

100

50

0 2

Figure 2. Rubis

3

4

6 10 Concurrent Clients

20

30

50

Basic, HIP and SSL throughput comparison in Amazon with

The second set of experiments were conducted using httperf in a public IaaS cloud environment. The experiments involved testing the performance of a single web server connected to a database server, where we used the httperf client to generate requests at a high rate (120 request/sec). The performance was measured for the basic, HIP and

SSL scenarios. This experiment did not have a distributed web server tier, so there was no need for a load balancer. However, it was still a multi-tier web service with the web server connected to the database server and the requests almost always required a database connection. As the request rate was extremely high, MySQL query caching was enabled for this particular experiment to reduce the possibility of the database being a bottleneck. The mean response times for Basic, HIP and SSL cases were 116.4 ms, 132.2 ms and 128.3 ms respectively. The response times and standard deviations were largely comparable. All the experiments involving HIP were carried out with LSIs that require a few extra translations incurring some penalty in terms of the overall performance. The performance degradation of HIP in comparison with SSL was largely due to the LSIs, used mainly for legacy compatibility. Figure 3 shows average response times for ICMP for 20 requests in Amazon. LSI translation is slower than with HITs due to some extra processing overhead, while Teredo has the worst latency. Figure 3 shows results of the raw TCP performance (without HTTP) as measured with iperf (version 2.0.5) 9 . The TCP window size was 85.3 Kilobyte. The experiments were conducted between two VMs inside Amazon EC2 in order to measure inter-machine network throughput using HIT, LSI, Teredo and plain IPv4-based connectivity. It should be noted that EC2 does not support native IPv6-based connectivity. TCP window sizes for iperf server and client were 85.3 KB and 16 KB respectively. Increased TCP window size and prolonged measurements did not have a significant effect on the throughput measurements. 150

2

1

50 0.5

0

0 LSI(Ipv4)

Figure 3.

Teredo

Ipv4

HIT(Ipv4) HIT(Teredo)LSI(Teredo)

Iperf and RTT measurements in Amazon EC2

VI. R ELATED W ORK In this section, we compare our work to 802.1q VLAN tagging, a number of virtualization approaches in the IETF and secure multiparty communication. 9 Iperf,

available: http://iperf.sourceforge.net/

The IEEE 802.1Q specification for Virtual LAN (VLAN) is a method of creating independent logical networks within a single physical network. A single broadcast domain is split into multiple smaller broadcast domains, each of which constitutes a separate VLAN. A VLAN Identifier (VID) is used by switches to determine the VLAN to which a frame belongs. Cloud computing systems, such as Eucalyptus, support assigning Virtual Machines to different VLANs. The default policy is to block all traffic among VMs in different VLANs to provide security. Mukhtarov [38] describe some VLAN-related vulnerabilities for IaaS clouds and Popa et al [39] further reason that VLAN is too inflexible for virtualized environments as it was originally designed to secure physical environments. In contrast, HIP avoids these threats utilizing a hostcentric security paradigm in the cloud. HIP can achieve a similar goal of securing communication between VMs as it creates secure tunnels to protect application-layer traffic. HIP also ensures authenticity of the VMs, since each VM is now identified by a public key. However, VLAN restricts subscribers to locate other VMs in other VLAN segments, as it separates the physical network into logical segments. Additionally, security in VLANs needs to be realized from a hardware-oriented perspective, with traffic engineering configurations on physical devices. In contrast, HIP is diversified in this notion of separation. Instead of having a group of VMs in a VLAN, VMs now form pairs. Any VM eavesdropping in between cannot decrypt the packets. Additionally, HIP has a substantially larger namespace, in the order of 2100 , thus making it suitable for such a security mechanism in the upper layer. B. Multi-tenancy Solutions

1.5 100 RTT (ms)

Iperf Bandwidth Measurement in Mbits

Iperf RTT

A. VLAN Tagging

Netlord [40] proposes a security solution for multitenancy in IaaS clouds. The idea relies on VLAN tagging and tunneling between modified hypervisors. Netlord reduces also ARP flooding in the data center; our approach does not solve this problem directly but could be solved by employing NATs in hypervisors and routers. Also, our approach does not require support from the cloud vendor but rather can be adopted by individual tenants in an incremental fashion. Similarly, CloudPolice [39] proposes hypervisor-based approach where modified hypervisors communicate security policies to each others in a distributed fashion. The approach does not utilize cryptography to protect its control plane to reduce processing overhead and hybrid cloud applicability is not discussed. We believe HIP could be used to secure the control plane in this scenario and further integrated with the approach o facilitate DoS protection and secure access control.

C. Secure Multiparty Communication Our work assumes that the cloud operator is trusted. Further, we assume that the attacker is another subscriber in the same cloud or an external host outside the cloud. While our proposal addresses communications privacy, more drastic means for computational privacy have been proposed. Cryptographic schemes designed for computational privacy, such as FHE [26], might be applicable for cloud services to operate on encrypted data, and hence, process and output information without understanding its real content. Unfortunately, Van Dijk et al. [27] explain that even such schemes are not a “holy grail” for computational privacy in multiparty computing, with cloud services running over client data, primarily in SaaS and PaaS clouds. In contrast, our work focuses on secured network communications between hosts. Our purpose was to secure all network communications with HIP in IaaS clouds. For secured multiparty communication, we have taken a less CPU intensive approach because IPsec encryption operates with symmetric-key encryption. Our approach is easier to deploy as it does not require any changes to existing services in clouds. In addition, an extra protocol for managing mobility is unnecessary as HIP has built-in support for it. VII. F UTURE W ORK Advocating HIP for cloud-based architectures and application deployment still requires a deeper inspection into the performance impact of HIP especially in a productionquality cloud. In our small-scale and proof-of-concept experiment, we did not make extensive use of DNS despite the used HIPL implementation has extensive support for DNS interaction. This includes a DNS proxy to translate HIP records from DNS to HITs or LSIs, a tool for converting Host Identifiers to a suitable format for DNS servers (Bind9 and TinyDNS are supported) and HIP-specific extensions support dynamic DNS [12]. In a production-scale environment, automated DNS support fortified with DNSSEC support would appear useful. We argue that HIP, besides being a strong contender for cloud architectures, is also relevant at the client side. Wider adoption of HIP on the client side, especially for cloud-based services, could solve several security issues. For example, the Chromium operating system 10 and Amazon Silk Web Browser 11 could make use of HIP at the client side because both the client and server side is controlled by a single operator. HIP has its own native version of NAT traversal [13]. However, we used Teredo in this paper because the native support was not available in any of the implementations yet. It should also be noted that Teredo has more free infrastructure available. 10 Chromium 11 Amazon

Operating System, available: http://www.chromium.org/ Silk, available: http://amazonsilk.wordpress.com/

Our straw-man analysis on the processing costs and power consumption should be considered preliminary, and further work is needed to understand the large-scale implications to data centers. Based on our small-scale measurements, it can be argued that HIP and SSL have a very similar performance footprint as they are essentially based on the same algorithms. However, the individual capabilities are different as argued earlier. VIII. C ONCLUSION Cloud architectures face some security and privacy issues rooted in their multi-tenant architecture. Different cloud subscribers must be isolated from each other to prevent information leakage. Our proposed solution based on Host Identity Protocol improves multi-tenant security in public and hybrid IaaS clouds. As HIP is not widely deployed, it easier to deploy only inside a single cloud or between two IaaS clouds. Individual tenants can incrementally deploy HIP in their virtual machines, albeit support publishing for HIP records in the DNS would be a convenient service from the cloud provider. In our experiments, end-users did not have to install HIP at all because the IaaS clouds employed a reverse HTTP proxy to terminate HIP connectivity and to facilitate load balancing in general. In contrast, power users, such as developers or administrators, can install HIP software on their workstations and bypass the proxy and access the individual virtual machines directly using HIP. We experimented with HIP to understand its potential for securing multi-tenant cloud infrastructures and the scalability implications. In our experiments, we measured the performance of a multi-tier bidding test system with three web servers and one database server. This system was set up both for a private and public cloud (Amazon EC2). HIP was used to secure internal connectivity in the clouds and a load balancer terminated HIP tunnels towards end-users. We measured parameters such as application throughput, network throughput, latency and RTT both in a public and private IaaS cloud deployment. While the bottleneck of the web service was the database rather than security, we observed the performance of HIP was comparable to that of SSL with the bidding service. Further, it could be argued that the power consumption in a data center is similar with HIP and SSL as they both employ the same cryptographic algorithms, meaning that a HIP is a viable alternative to secure communication internally and especially across data centers in hybrid clouds. IX. ACKNOWLEDGMENTS The authors wish to thank Jukka Ylitalo, Zhonghong Ou, Amit Soni, Koushik Annapureddy, Teemu Kiviniemi, Timo Kiravuo and Thomas Henderson on their input for this topic. The work was supported by Tekes (the Finnish Funding Agency for Technology and Innovation, www.

tekes.fi) as a part of the Cloud Software Program (www. cloudsoftwareprogram.org) of Tivit (Strategic Centre for Science, Technology and Innovation in the Field of ICT, www.tivit.fi), and also by the Academy of Finland, grant numbers 255932 and 135230.

[22] [23]

R EFERENCES [1] P. Mell and T. Grance, “The NIST Definition of Cloud Computing,” National Institute of Standards and Technology, Tech. Rep., January 2011. [2] R. Moskowitz and P. Nikander, “Host Identity Protocol (HIP) Architecture,” RFC 4423 (Informational), IETF, May 2006. [3] P. Nikander and J. Laganier, “Host Identity Protocol (HIP) Domain Name System (DNS) Extensions,” RFC 5205 (Experimental), IETF, Apr. 2008. [4] J. Ahrenholz, “Host Identity Protocol Distributed Hash Table Interface,” RFC6537 (Experimental), IETF, Tech. Rep., February 2011. [5] T. Henderson, P. Nikander, and M. Komu, “Using the Host Identity Protocol with Legacy Applications,” RFC 5338 (Experimental), IETF, Sep. 2008. [6] P. Nikander, A. Gurtov, and T. Henderson, “Host Identity Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over IPv4 and IPv6 Networks,” Communications Surveys Tutorials, IEEE, vol. 12, no. 2, pp. 186 –204, 2010. [7] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson, “Host Identity Protocol,” RFC 5201 (Experimental), IETF, Apr. 2008. [8] P. Jokela, R. Moskowitz, and P. Nikander, “Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP),” RFC 5202 (Experimental), IETF, Apr. 2008. [9] H. Tschofenig, M. Shanmugam, and F. Muenz, “Using SRTP transport format with HIP,” IETF, Expired Internet Draft, October 2006. [10] P. Nikander, T. Henderson, C. Vogt, and J. Arkko, “End-Host Mobility and Multihoming with the Host Identity Protocol,” RFC 5206 (Experimental), IETF, Apr. 2008. [11] J. Laganier and L. Eggert, “Host Identity Protocol (HIP) Rendezvous Extension,” RFC 5204 (Experimental), IETF, Apr. 2008. [12] O. Ponomarev and A. Gurtov, “Embedding Host Identity Tags Data in DNS,” IETF, Expired Internet Draft, July 2009. [13] A. Keränen and J. Melen, “Native NAT Traversal Mode for the Host Identity Protocol,” Jun. 2012, work in progress. [14] C. Huitema, “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” RFC 4380 (Proposed Standard), IETF, Feb. 2006, updated by RFCs 5991, 6081. [15] S. Varjonen, M. Komu, and A. Gurtov, “Secure and Efficient IPv4/v6 Handovers Using Host-Based Identifier-Location Split,” Journal of Communications Software and Systems, vol. 6, no. 1, 2010. [16] H. Takabi, J. Joshi, and G. Ahn, “Security and Privacy Challenges in Cloud Computing Environments,” Security Privacy, IEEE, vol. 8, no. 6, pp. 24 –31, November-December 2010. [17] W. Jansen and T. Grance, “Guidelines on Security and Privacy in Public Cloud Computing,” National Institute of Standards and Technology, Tech. Rep., January 2011. [18] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage, “Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds,” in Proceedings of the 16th ACM conference on Computer and communications security, ser. CCS ’09. New York, NY, USA: ACM, 2009, pp. 199–212. [19] A. Greenberg, J. R. Hamilton, N. Jain, S. Kandula, C. Kim, P. Lahiri, D. A. Maltz, P. Patel, and S. Sengupta, “Vl2: a scalable and flexible data center network,” in Proceedings of the ACM SIGCOMM 2009 conference on Data communication, ser. SIGCOMM ’09. New York, NY, USA: ACM, 2009, pp. 51–62. [20] A. Greenberg, P. Lahiri, D. A. Maltz, P. Patel, and S. Sengupta, “Towards a next generation data center architecture: scalability and commoditization,” in Proceedings of the ACM workshop on Programmable routers for extensible services of tomorrow, ser. PRESTO ’08. New York, NY, USA: ACM, 2008, pp. 57–62. [21] W. Dawoud, I. Takouna, and C. Meinel, “Infrastructure as a service security: Challenges and solutions,” in Informatics and Systems (IN-

[24] [25] [26]

[27] [28]

[29] [30]

[31] [32] [33] [34]

[35]

[36] [37] [38]

[39]

[40]

FOS), 2010 The 7th International Conference on, March 2010, pp. 1–8. W. A. Jansen, “Cloud hooks: Security and privacy issues in cloud computing,” in System Sciences (HICSS), 2011 44th Hawaii International Conference on, January 2011, pp. 1–10. M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “Above the clouds: A berkeley view of cloud computing,” EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2009-28, Feb 2009. V. Soundararajan and K. Govil, “Challenges in building scalable virtualized datacenter management,” SIGOPS Oper. Syst. Rev., vol. 44, pp. 95–102, December 2010. Y. Chen, V. Paxson, and R. H. Katz, “What’s new about cloud computing security?” EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2010-5, January 2010. C. Gentry, “Fully homomorphic encryption using ideal lattices,” in Proceedings of the 41st annual ACM symposium on Theory of computing, ser. STOC ’09. New York, NY, USA: ACM, 2009, pp. 169–178. M. van Dijk and A. Juels, “On the impossibility of cryptography alone for privacy-preserving cloud computing,” Cryptology ePrint Archive, Report 2010/305, 2010. R. A. Popa, C. M. S. Redfield, N. Zeldovich, and H. Balakrishnan, “CryptDB: Protecting Confidentiality with Encrypted Query Processing,” Symposium on Operating System Principles, Tech. Rep., October 2011. M. Komu and T. Henderson, “Basic Socket Interface Extensions for the Host Identity Protocol (HIP),” RFC 6317 (Experimental), IETF, Jul. 2011. J. Lindqvist, E. Vehmersalo, J. Manner, and M. Komu, “Enterprise network packet filtering for mobile cryptographic identities,” in Journal of Handheld Computing Research (IJHCR). 701 E. Chocolate Avenue, Hershey, PA 17033, USA: IGI Global (IGI, 2009. T. Aura, P. Nikander, and J. Leiwo, “DOS-resistant authentication with client puzzles,” in 8th International Workshop on Security Protocols, Apr. 2001, pp. 170–177. J. Beal and T. Shepard, Deamplification of DoS Attacks via Puzzles, Oct. 2004. S. T. Miika Komu and A. Lukyanenko, “Mitigation of unsolicited traffic across domains with host identities and puzzles,” ser. Springer Lecture Notes in Computer Science. Springer, 2010. O. Ponomarev, A. Khurri, and A. Gurtov, “Elliptic curve cryptography (ecc) for host identity protocol (hip),” in Proceedings of the 2010 Ninth International Conference on Networks, ser. ICN ’10. Washington, DC, USA: IEEE Computer Society, 2010, pp. 215–219. P. Jokela, P. Nikander, J. Melen, J. Ylitalo, and J. Wall, “Host identity protocol: Achieving IPv4 - IPv6 handovers without tunneling,” in In Proc. of Evolute workshop 2003: Beyond 3G Evolution of Systems and Services, 2003. S. Herborn, A. Huber, R. Boreli, and A. Seneviratne, “Secure host identity delegation for mobility.” in COMSWARE. IEEE, 2007. R. H. Paine, Beyond HIP: The End to Hacking As We Know It. BookSurge Publishing, 2009. M. Mukhtarov, N. Miloslavskaya, and A. Tolstoy, “Network security threats and cloud infrastructure services monitoring,” in The Seventh International Conference on Networking and Services, ICNS 2011. IARIA, May 2011, pp. 141–145. L. Popa, M. Yu, S. Y. Ko, S. Ratnasamy, and I. Stoica, “Cloudpolice: taking access control out of the network,” in Proceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks, ser. Hotnets ’10. New York, NY, USA: ACM, 2010, pp. 7:1–7:6. J. Mudigonda, P. Yalagandula, J. Mogul, B. Stiekes, and Y. Pouffary, “Netlord: a scalable multi-tenant network architecture for virtualized datacenters,” SIGCOMM Comput. Commun. Rev., vol. 41, no. 4, pp. 62–73, Aug. 2011.