Towards full network virtualization in horizontal IaaS federation: security issues
© Nimkar and Ghosh; licensee Springer. 2013
Received: 20 February 2013
Accepted: 15 November 2013
Published: 21 November 2013
KeywordsCloud computing Security Horizontal federation IaaS
The development of cloud computing as conjectured by Celesti et al.  is divided into three stages: i) monolithic cloud, ii) vertical federation, and iii) horizontal federation. In the first stage, the full-fledged cloud services are provided by the cloud provider. All the services are proprietary and hence all the granular services (e.g. a storage service, computing service etc.) needs to be taken from a single cloud provider. In the vertical federation, most of the cloud providers leverage cloud services from another provider. Currently, the second stage is in transition. The future stage will be the horizontal IaaS federation where cloud providers federate to borrow virtual resources (e.g. virtual machines, virtual nodes and virtual links) from another cloud provider to gain economics of scale. The cloud federation may be economically profitable, since the datacenter utilization is only 5% to 20% of its peak time . This under-utilization can be used by another cloud provider in the federation. The cloud federation also solves the problem of service provider lock-in, unavailability of the particular service provider, heterogeneous environment unavailability etc. .
The monolithic IaaS cloud has three limitations namely (a) maximum number of VLANs are limited to 4K because of 12 bits VLAN ID in 802.1Q Ethernet Header , (b) no user-agreed network topology at granular level configured and (c) the router gives connectivity between clouds (i.e. a single route table is used to manage all networks of a user), or cloud and the Internet. We will use the term minimal network virtualization for the three aforementioned limitations in the monolithic IaaS cloud. The IBM’s TVDc is an example of vertical federation which supports minimal network virtualization [5, 6]. In contrast to the minimal network virtualization, the full network virtualization is an environment in which the connectivity of virtual machines is provided using instances of physical network components (e.g. router and switch). It also will facilitate transparent network management of virtual network at a granular level (i.e. virtual switch, virtual router etc.).
Informally, the horizontal IaaS federation provides a federated IaaS cloud service of virtual servers using full network virtualization out of the datacenter. The transparent network virtualization in horizontal IaaS federation facilitates the network isolation, flexibility in network management, user-level network policy control  along with the advantages of cloud federation mentioned earlier. The full network virtualization in horizontal IaaS federation also provides separation of duties (infrastructure provider and service provider etc.), inter-operability between network owners, and portability. Few topology-aware scientific and commercial applications which can be deployed in horizontal IaaS federation are explored in  and .
There are two major challenges in the development of horizontal IaaS federation. First, the datacenters and virtual resources lack full network virtualization required for the horizontal IaaS federation. The second obstacle in the development is the lack of security provision required for the collocation of tenants’ virtual networks on the datacenter. The obstacles demand analysis of the existing network virtualization technologies in different domains for security provision.
In this paper, we have investigated potential areas of network virtualization environment (NVE): a) generic network virtualization, b) the datacenter network virtualization, c) network virtualization in monolithic cloud and d) network virtualization in virtual resources. We use the term generic network virtualization to denote the research projects for testing future generation networks from academia and industry. First, we give a qualitative comparison of monolithic cloud designs, datacenters, network virtualization projects and virtual resources related to security issues. We also give limitations of aforesaid areas to incorporate full network virtualization and security services required for horizontal IaaS federation. Finally, an insight in research directions on security issues is given for the development of horizontal IaaS federation.
The rest of this paper is organized as follows. We first formally re-define horizontal IaaS federation for the inclusion of full server and network virtualization in Section ‘Horizontal IaaS federation’. A hypothetical example of horizontal IaaS federation is also given in Section ‘Horizontal IaaS federation’ to illustrate the reasons for the investigation of network virtualization security. Section ‘Horizontal IaaS federation security issues’ explores the domains for security of horizontal IaaS federation and also gives a list of security requirements for horizontal IaaS federation. Section ‘Monolithic IaaS NVE security’ presents NVE security issues of monolithic cloud and vertical federation. Section ‘Datacenter NVE security’ and ‘Generic NVE security’ give security issues of datacenter and generic NVE respectively. The security issues of virtual resources related to NVE are presented in Section ‘Virtual resources security’. Finally, a discussion on research directions for security in horizontal IaaS federation and concluding remarks are presented in Section ‘Research directions’ and Section ‘Conclusions’ respectively.
Horizontal IaaS federation
In horizontal IaaS federation, the service provider gives service to another cloud called home cloud, and the service borrower takes service from another cloud called foreign cloud. The home cloud borrows virtual resources from the foreign cloud either because of virtualization infrastructure saturation in home cloud, or the economics of scale in cloud federation . The three-phase cross federation [1, 10] and mobile-agent based cloud federation  are examples of the horizontal IaaS federation in which a home cloud rents virtual machines from foreign clouds without considering full network virtualization.
The horizontal IaaS federation should provide full network virtualization to its clients to gain advantages mentioned earlier. The existing work on horizontal IaaS federation [1, 3, 10] incorporates full server virtualization and minimal network virtualization while the application of network virtualization in various domains [11, 12] concentrates on one of the two virtualizations. So, we first investigate the roles in the full server and network virtualization; and then formally re-define it for the inclusion of full server and network virtualization.
The current horizontal IaaS federation ecosystem has three key components: Cloud coordinators, Brokers, and an Exchange . The cloud coordinators handle the datacenters for exporting market-based cloud services. A cloud coordinator can be cloud provider or consumer in the federation. A Cloud Broker is a mediator between cloud providers and cloud consumers for the federation. A cloud exchange performs match making services for the cloud users.
The horizontal IaaS federation with full server and network virtualization must consider at least two roles (viz. network service provider and infrastructure provider) from network virtualization and three roles (viz. a cloud provider, cloud consumer and a broker) from the current horizontal IaaS federation ecosystem. So the horizontal IaaS federation ecosystem must have four roles namely service provider (SeP), infrastructure provider (InP), broker (Br) and user to incorporate full network virtualization. The horizontal IaaS federation can be formally defined as:
Definition: horizontal IaaS federation The federated cloud service of virtual infrastructures of a set of virtual nodes (e.g. virtual switches, virtual routers), virtual links and virtual machines from a set of InPs (a virtual network infrastructure provider) and SePs (a IaaS cloud service provider) with transparent full server and network virtualization.
The virtual nodes and links are created by their respective InPs on receiving request from SePs. The virtual resources are managed by the users of SePs. The double-dot-dash and single-dot-dash line polygons show the boundary of SeP-1 and SeP-2 control respectively. The management of virtual resources is done by their respective users. In a nutshell, the various functions like virtual resource management, control and configuration are cooperatively performed by the three roles of the federation, so it is necessary to consider various security issues for proper functioning of the federation.
Horizontal IaaS federation security issues
To incorporate full network virtualization in federation ecosystem, the security issues of all constituents in the ecosystem must be investigated. The two components, Brokers and an Exchange out of three components of federation system are very similar to any brokered architecture  where the service/resources are leased using some kind of negotiation between service consumer and provider through the Brokers and an Exchange. So, the investigation of these two components are omitted.
Vaquero et al.  surveyed monolithic IaaS security issues related to virtual machines but it did not address the security issues related to network virtualization. In [7, 11], the authors investigated generic network virtualization without security concerns. Bari et al.  reported the survey of datacenter network virtualization without security issues. In a nutshell, none of the existing work have concentrated on the security issues in network virtualization environment. We mainly focus on NVE security issues in monolithic IaaS cloud (Section ‘Monolithic IaaS NVE security’), datacenter network (Section ‘Datacenter NVE security’), generic network virtualization (Section ‘Generic NVE security’) and virtual resources (Section ‘Virtual resources security’) to incorporate full network virtualization in the federation.
A detailed discussion on the security requirements of federation ecosystem is beyond the scope of current investigation. A few security requirements of the federation are already explored in the constituents of federation ecosystem in the literature: (a) cloud security requirements , (b) network virtualization security requirements , (c) cloud security alliance V3.0, and (d) web security survey . So we use following security requirements which are derived and extended from the literature [16–19].
R1 - Layered network architecture in which physical resources are controlled by InPs and virtual resources are transparently controlled by SePs.
R2 - Provide transparent view of virtual network infrastructure with a clear SLA (service level agreement) between SePs, InPs and cloud users.
R3 - Autonomous local identity management for physical resources used by InP.
R4 - Cooperative global identity management for virtual resources used by SeP and cloud users.
R5 - A brokered architecture between Br, InPs, SePs and cloud users for the collaboration of local and global identity management.
R6 - An access control mechanism to create, destroy virtual resources out of physical resources after the negotiation between InPs, SePs and cloud users.
R7 - An access control mechanism to manage and use virtual resources as per SLA between InPs, SePs and cloud users.
R8 - Intra-InP routing protocol with source authentication, operational confidentiality for cloud users within a InP.
R9 - Inter-InP routing protocol with source authentication, operational confidentiality and least information disclosure among InPs.
R10 - Tight collaboration among SePs and InPs in terms of fault handling, configuration, accounting, performance monitoring, trust negotiation and QoS.
Monolithic IaaS NVE security
As monolithic IaaS clouds are proprietary and a few technical documents are publicly available, so only two designs have been selected for the investigation of NVE security. Amazon Elastic Cloud 2 (EC2) [20–22] and GoGrid are the representatives of the most popular and a randomly selected IaaS cloud provider respectively.
The first representative, EC2 provides minimal network virtualization using either a software or hardware gateway to facilitate the communication between VPCs or virtual machines. A software gateway uses route tables as software virtual router while hardware gateway uses hardware router. Cisco integrated service routers and Juniper J-series are examples of software virtual routers. RTX 3000 is an example of hardware router. The EC2 uses security groups to provide the basic security services among the users. A security group acts as a virtual firewall to control the traffic allowed that is allowed into a group of virtual machines instances.
The second representative, GoGrid offers limited network service using a private switch to each private cloud. GoGrid also makes use of hardware firewall to protect the servers of private clouds. Xu et al.  proposed secured wide area network virtualization for virtual private cloud using tunnelling.
Datacenter NVE security
Datacenter network virtualization security
- DPI or IDS)
Dynamic VM migration
FE and CC
Set of distributed FEs
Multi-tenancy network isolation
FE and CC
Set of distributed FEs
VPLS and MPLS
Bandwidth performance isolation
Set of vNIC
Bandwidth guarantees and
Flexible network abstraction
L2 and L3 encapsulation
Assumption - physical
mapping to virtual and
VM migration, automatic
L2 switching using
hierarchical Pseudo MAC
The Diverter provisions network virtualization on the top of customized layer-3 network addressing. Each host has triplet 〈f:s:h 〉 address where f is farm of hosts, s is subnet identifier and h is a particular host. The layer-3 triplet addresses are transparent to the tenants. Each host also runs VNET as distributed router in OS kernel-space. The VNET implements anti-spoofing and visibility filters to provide security services to tenants. The anti-spoofing filter prevents a VM impersonation by another VM. The visibility filter contains all network visibility rules to enforce separation between virtual machines. The tenants can use optional tunnelling for confidentiality.
The SEC2 and VICTOR have some common features. The network infrastructure of SEC2 as well as VICTOR is organized in two levels: a core domain and edge domains. An edge domain consists of physical hosts and switches. The core domain is made of a set of customized layer 2 switch called as Forwarding Element (FE) and Central Controller (CC). Central Controller (CC) controls the operation of FEs. FE performs two functions namely, (a) address lookup and mapping and (b) policy enforcement. The security service of SEC2 is made available through tunnelling or FEs. FEs can implement firewalls, NAT and middleboxes. The remaining seven datacenters proposals have different aims but do not provide any security features as summarized in Table 1.
Generic NVE security
The existence of virtual network on the top of physical network may appear at any layers of OSI reference model. Consequently, there are mainly four types of network virtualization: (a) virtual local area network (VLAN), (b) virtual private network (VPN), (c) active and programmable network, and (d) overlay networks . Some of the surveyed network virtualization projects using aforementioned types are not useful for the investigation of security issues. So we used three filtering criteria for the survey. The first, VLAN and VPN inherently provides security features to network virtualization environment using segmentation, isolation, tunnelling, IPSec and VLAN. Second, the main aim of some network virtualization projects (e.g. AKARI, CABO, 4WARD, Triology, and Clean-slate) is the design of next generation network. They are long-term projects; and are evolving and extending from another network virtualization projects like GENI and VINI. Third, the research in old network virtualization projects namely Genesis (is from Active and programmable network type) has been stopped. So the network virtualization projects for security investigation after applying the three filtering criteria are GENI, PlanetLab, UCLP, VINI and X-bone.
As per the security requirements of full network virtualization in federation given in Section ‘Horizontal IaaS federation’, we surveyed the network virtualization projects by classifying them under five categories: (a) identity management for resources, (b) authentication and trust management, (c) resource access control, (d) routing security issues; and (e) other security issues.
Identity management for resources
The GENI have InPs (called as Aggregates) and SePs (called as research organizations). The users of research organization (i.e., SeP users) are called principal. The principal may be a researcher, principal investigator (which is an administrator) and slice admin. The virtual network instance is called slice and consists of objects. The GENI defines identifiers called GENI Global Identifiers (GGID) for all principal and objects in the system. The GENI uses X.509 certificate to represent GGID for authentication. In federated GENI system, an identity of an object in SeP is a union of identities stored across multiple InPs. The database of identity name-space is stored at the research organization’s site and allows control by the principal.
The PlanetLab has three main roles: an owner, a user and PLC (PlanetLab Consortium). The owner (i.e., InP) supply physical nodes to create VMs. A service is installed on PlanetLab by a researcher (i.e., SeP). The PLC is a centralized entity and has mainly two functions: (a) manages physical resource and (b) maintains trust among owners and researchers. A slice is a collection of VMs. Each slice is uniquely identified by the hierarchical name where each level has the responsibility to manage and control the resources at that level. The PLC acts as slice authority and maintains state of all slices in the system.
The UCLP is the most promising project for federation in which the identities of virtual resources (e.g. LightPath, End2End object) is managed by UCLP Admins (SePs) and the identities of physical resources are managed by network owners (InPs). The UCLP end users cannot control UCLP virtual resources. The UCLP uses decentralized JavaSpace storage for the identities at InPs’ sites. The overlay manager (SeP as well as InP) in X-bone manages the identity of virtual nodes at central repository. The X-bone user cannot control the identity of the virtual resources. The NouVeau is an identity management for a abstract network virtualization model and is similar to UCLP. It is based on three main principles: separation of identity and location, local autonomy, and global identifier space. It also requires special entities called controller and adapters for the managements of identities in SePs and InPs.
Authentication and trust management
A typical identity management has any of the three types of trust relationship between the service provider (SP) and identity provider (IdP) - pairwise, brokered and community trust models [41, 42]. In network virtualization, SeP or InP may play a role as IdP and SP. The identity management may have any of the three trust relationships between SePs and/or InPs in network virtualization depending on the number of InPs and SePs. The PlanetLab, UCLP and X-bone uses PKI infrastructure (i.e., community trust) for authentication and trust management between SePs and InPs.
GENI uses a brokered trust model in which four entities namely clearinghouse, aggregates, research organization and researcher form a bilateral automatic trust negotiation [43–45] between them. The GENI is a decentralized system in which most of the times, a requester may not be from the same security domain (InP) for the authorization of resources. So, it uses attribute-based access control (ABAC) in which a request may be granted based on the characteristic of the requester’s attributes. The negotiator contacts access mediator (i.e., GENI clearinghouse) to start bilateral negotiation (i.e., automatic trust negotiation). The negotiation is a sequence of credential exchange starting from non-sensitive credentials between negotiators. After successful negotiation, the request is granted to access the resource.
Resource access control
The network slices of GENI are created out of physical network of aggregates. The aggregates are strangers to each other, so the GENI uses ABAC in which automatic trust negotiation is performed by exchanging sensitive credentials. ABAC authorizes the access to virtual resources using attribute acknowledgement (ACK) policies and trust-target graph (TTG) protocol. The ACK policy and TTG protocol perform attribute disclosure and resource access decisions respectively using directed graph.
The UCLP satisfies some requirements of R6 and R7 for physical and virtual network resources. The resource access control for UCLP physical resources is either implemented in the UCLP system, or an intermediate system between the UCLP and switch management. The UCLP system may use mandatory access control (MAC) or discretionary access control (DAC) for UCLP virtual resources. The UCLP supports three approaches for access control of UCLP virtual resources. The three approaches are traditional DAC, generic authorization-based distributed DAC and attributed-based distributed DAC. The first method performs all the evaluation of access and enforcement of policy in a centralized manner. The second method stores authorization information in different domains and performs the authorization process in multiple domains. The third method uses certificate-based system for authorization. The traditional DAC cannot make authorization of users in other domains. The second method is difficult to realize while the third approach is the easiest to implement.
X-bone system uses very simple access control mechanism for the authorization using ACL (access control list). It maintains the list of permission on the virtual resources for each user in the system. X-bone first checks the ACL for applicable entry to decide whether the requested operation is authorized based on subject and object identities.
Routing security issues
Routing security issues for horizontal IaaS federation
No. of tenants
Location & identity
NO (Privacy of attributes)
Location & identity
Location & identity
Location & identity
The three variants of BGP namely S-BGP, IRV, and So-BGP provide security services in terms of - PKI, address attestation (a statement of delegation of identity), a special SECURITY message, or IRV–Identity Request Server with no provision for information disclosure. The minimum disclosure routing (MDR), routing on flat label (ROFL) and secure virtual trust routing (SVTR) are the upcoming routing protocols for virtual network in the field of federation. The MDR gives the minimum disclosure and operational confidentiality through the extension of Secure Multi-party Computation (SMC). The SMC reveals secret information among multiple parties using their individual secrets. The nodes of ROFL routing guarantees origin authentication and path validation using self-certification and access control mechanism respectively. SVTR is the only protocol that gives provision for multi-tenant collocation using hop integrity.
Basic security services
Basic security services of network virtualization projects
Virtual resources security
The virtual resources for network virtualization in monolithic cloud are fully or partially implemented as software. We specifically focussed on virtual resources namely virtual routers, virtual switches and virtual links. Sections ‘Virtual routers’, ‘Virtual switches’, ‘Virtual links’ and ‘Virtual resource migration’ gives the detailed survey of virtual resources in monolithic IaaS cloud and generic network virtualization.
The virtualization of software routers called virtual software routers exploits processing power out of physical router or commodity hardware using NICs or NetFPGA. Juniper’s intelligent logical router on the top of M-Series and T-Series routers are examples of virtual software routers . The intelligent logical router supports customized policy control, protocol assignment, configuration but no on-the-fly configuration and administration. It also does not support source authentication. Most of virtual software routers from monolithic cloud including Amazon EC2 use route tables. The route table maintains network filtering policy and are managed by VPC network administrator. The EC2 also uses security groups which offer secured virtual network isolation among cloud users.
Commodity and physical virtual routers’ control plane properties
Commodity-Intel IXP2400 
L3VR and L3/4VR
NetFPGA & TCAM
Software & hardware
The virtual switches can be broadly divided into hypervisor-based or hardware-based depending on the location of the implementation of virtual switches. The hypervisor-based virtual switches are typically written entirely in software. The hardware-based virtual switch is partly implemented on special hardware like NIC, NetFPGA etc. The basis of hypervisor-based virtual switch is Open vSwitch . Open vSwitch resides within the management domain of hypervisor (e.g. Domain-0 in Xen) and provides connectivity between virtual machines and physical interfaces. Open vSwitch uses VLANs and GRE tunnels for secured virtual network and virtual path respectively. It also supports basic ACL.
Hardware-based virtual switch eliminates some limitations (like CPU or memory usage) of software-based virtual switch. Two hardware-based virtual switch implementations are Virtual Ethernet Port Aggregator (VEPA)  and VNTag . The Virtual Ethernet Port Aggregator (VEPA) is a standardization led by HP Extreme, IBM, Brocade and Juniper etc. The VEPA allows traffic of VM to exit and re-enter the same port to enable switching among VMs. The VEPA has MACSec scheme to provision a secure connection between VEPA and bridges.
Tseng et al.  proposed the integration of open-source hypervisor with software-based virtual switch and aims at secure network environment among VMs. Luo et al.  proposed hardware-based virtual switch using special NIC to provide network connectivity among VMs in the datacenter.
The virtual links can be created using either signalling protocol or encapsulation. The virtual link setup protocol (VLSP) is an example of signalling protocol to create the virtual links. The encapsulation-based virtual link creation in the literature are Virtual Tunnel (VTun), Layer Two Tunnelling Protocol - V3 (L2TPV3), Generic Routing Encapsulation (GRE) and IP in IP Tunnelling (IIP).
Roland Bless et al.  proposed VLSP to create authenticated and secured virtual link using NSIS authorization  and secured signalling  protocols. It also provides QoS as per user’s requirement for link creation. The L2TPV3  encapsulation protocol creates tunnel between nodes at layer 2. It does not inherently provide authentication and encryption but IPSec can be used for security provision. The VTun is a virtual link implementation over various kinds of tunnels (e.g. Ethernet, serial tunnel, pipe tunnel) and; provides security services like authentication, compression and encryption etc. . The GRE  encapsulation protocol is used to create a virtual link between two nodes using an additional header in the packet called delivery header without any security features. The IIP  link creation protocol has a packet format consisting of the outer header, security header, original header and IP payload. The security header adds optional security services using IPSec.
Virtual resource migration
As network virtualization is new emerging field, there is few literature on some important field like the migration of virtual router and link etc. Chen et al. uses VROOM  router architecture to provide energy-saving IP-WDM network architecture  by the process of virtual router migration. All the router architecture proposals and their migration methods using the combination of data and control plane proposed by Pisa et al. concentrates on performance in terms of delay . The full virtual network migration including virtual machines is proposed by Keller et al. All the literature concentrate on virtual resource migration without any security concerns. The virtual link migration suggested by Pisa et al does not provide any security services.
All domains surveyed in the paper lacks network virtualization and/or its security provision. Most of network virtualization projects are meant for scientific purpose where the performance is major concern so the focus of the projects are collocation of SePs’ networks on InPs’ physical network without any security concerns. Similarly, datacenters do not exploit full network virtualization and facilitates minimum security services in terms of VLAN or VPN technology. The virtual resources lack very basic level of security services. As a result of aforementioned shortcomings, we will discuss NVE security issues for federation and give few research directions. The research directions are classified as: (a) router architecture (b) datacenter NVE security, (c) resource identity management, (d) resource access control and (e) intra-InP and inter-InP routing.
All the router architectures using the combination of data and control plane concentrates on performance in terms of delay. The control plane as well as data plane virtualization allows best-effort memory utilization but may promote confidentiality threat due to the collocation of multiple SePs’ virtual routers on the same physical router. The software virtual routers on commodity as well as physical router lacks source authentication, remote configuration using SeP’s access control as shown in Table 6. The source authentication, remote configuration and access control mechanism are basic requirements (R6-R10) to perform inter-InP and intra-InP routing by the software virtual routers. By adding the above functionality, we pose few research questions like: What will be the impact on router performance in terms of packet-delay? What is the maximum number of tenants’ virtual software routers that can coexist on a physical router without degrading the performance? How the router virtualization handles intra-InP and inter-InP routing by considering the collocation of tenants’ virtual networks? How the virtual router migration be handle by this architecture?
Datacenter NVE security
The most promising datacenter network virtualization architecture for the federation is SEC2  which supports basic security services like source authentication, transparent network management etc., but does not support full network virtualization (requirements R1 and R2). The network isolation among customers of CloudNAS can be compromised if hypervisors, switches, or middleboxes are compromised . The customized devices like FEs or CCs may expose MAC address of host and VM . No datacenter supports federation of virtual resources (requirement R10), full NVE (requirements R1-R2) and resource access control (requirements R6 and R7). All datacenter network virtualization projects support minimum security services using VLAN, L2/L3 addressing or special routing devices (e.g. FE, CC etc.) as shown in Table 1. The datacenter also do not permit transparent network management (requirement R2), user-level policy control and resource access control (requirements R6 and R7) required for the federation.
Resource identity management
Table 2 shows that there is no identity management which provides the feature of multiple InPs and SePs (requirement R5), user’s control over identities (requirement R4) and decentralized storage. We used the generic term user control to mean various operations on virtual resources e.g., creation of virtual link, configuration of virtual resource etc. The UCLP project shows some potential towards the design of an identity management for federation but lacks users’ control over identities (requirement R4). The federation requires federated identity management, so a trust between InPs and/or SePs must be established to gain the control over the requested resources automatically on-the-fly. So, the federation needs the identity management with automated trust negotiation (requirement R10). We must also address the following research question related to resource identity management: How to map heterogeneous address space of resources in datacenters to local and global identity name-space?
Resource access control
The trivial resource access control for horizontal IaaS federation requires user-controlled access control mechanism (requirement R7) at virtual infrastructure and mandatory access control (requirement R6) at physical infrastructure. The GENI does not provide any kind of resource access control over the physical resources while virtual resources are managed in terms of Trust-Target Graph protocol of ABAC (requirement R7). The UCLP provisions MAC or DAC at virtual infrastructure level but it does not fulfil the requirement at physical level. X-bone uses ACL, a simplest access control management of resources. Some research questions related to resource access control are: Where should be the placement of resource access controls in physical resources? If the location of access control is in control plane of physical resource; and distributed among InPs and SePs, how would they interact? What would be bandwidth-delay product performance of physical as well as virtual network infrastructures after deploying resource access controls?
Intra-InP and Inter-InP routing
Keller et al.  and Fukushima et al.  open up theoretical research directions for intra-InP and inter-InP routing respectively. The inter-InP routing should not disclose routing information to InPs other than intended InPs (i.e minimum disclosure) and also provide operational confidentiality in routing process. MDR offers both minimum disclosure and operational confidentiality among InPs but does not provide other properties mentioned in Table 4. The intra-InP and inter-InP routing should possess the security requirements, R6 and R7 with the consideration of tenants’ virtual network collocation. We pose the following research questions for routing process in the federation by including aforementioned security requirements: How the router maintains routing table using intra-InP and inter-InP routing? How the information (i.e., packets) of different virtual networks of cloud users are separated? How the router will forward the packets of different virtual networks without exposing or compromising?
With the motivation of adding full network virtualiztion in horizontal IaaS federation, we investigated network virtualization security in four areas: monolithic IaaS cloud, generic network virtualization, datacenter network virtualization and virtual resources. We presented the qualitative comparisons of generic network virtualization projects, datacenters, routing protocols and virtual resources from aforementioned areas. Our qualitative comparisons show the following important insights related to network virtualization and security issues in horizontal IaaS federation. The monolithic IaaS clouds do not support full network virtualization but give minimal network virtualization to offer the connectivity of virtual networks or virtual machines. The simple security services are offered in terms of VLAN, VPN or tunnelling for the collocation of multiple tenants in monolithic IaaS clouds. The datacenters lack both full network virtualization and basic security services for the horizontal IaaS federation. The network virtualization projects offer full network virtualization but partial security provisions in terms of one or more services of identity management, resource access control and trust management. The router architectures mostly focus on the performance of virtual software routers and do not add any security features for the collocation of tenants networks. The virtual switches cannot have more than 4K VLANs. This paper shows that the virtual links can be created using either signalling protocol or encapsulation. The encapsulation-based virtual link has an extra overhead of encapsulation on the top of L2/L3 protocols but give hop integrity security service. The signalling-based virtual link offers various security services like origin authentication, hop integrity and path validation. The research challenges mentioned in Section ‘Research directions’ are crucial to the success of horizontal IaaS federation in cloud computing.
- Celesti A, Tusa F, Villari M, Puliafito A: How to enhance cloud architectures to enable cross-federation. In Cloud Computing (CLOUD), 2010 IEEE 3rd international conference on. Miami: IEEE; 2010:337–345.View ArticleGoogle Scholar
- Armbrust M, Fox A, Griffith R, Joseph AD, Katz R, Konwinski A, Lee G, Patterson D, Rabkin A, Stoica I, Zaharia M: A view of cloud computing. Commun ACM 2010, 53(4):50–58. http://doi.acm.org/10.1145/1721654.1721672 10.1145/1721654.1721672View ArticleGoogle Scholar
- Zhang Z, Zhang X: Realization of open cloud computing federation based on mobile agent. In Intelligent computing and intelligent systems, 2009. ICIS 2009. IEEE international conference on, Volume 3. Shanghai: IEEE; 2009:642–646.View ArticleGoogle Scholar
- Hao F, Lakshman TV, Mukherjee S, Song H: Secure cloud computing with a virtualized network infrastructure. In Proceedings of the 2nd USENIX conference on Hot topics in cloud computing, HotCloud’10. Berkeley: USENIX Association; 2010:16–16. http://dl.acm.org/citation.cfm?id=1863103.1863119Google Scholar
- Berger S, Cáceres R, Goldman K, Pendarakis D, Perez R, Rao JR, Rom E, Sailer R, Schildhauer W, Srinivasan D, Tal S, Valdez E: Security for the cloud infrastructure: trusted virtual data center implementation. IBM J Res Dev 2009, 53(4):560–571. http://dl.acm.org/citation.cfm?id=1850659.1850665View ArticleGoogle Scholar
- Berger S, Cáceres R, Pendarakis D, Sailer R, Valdez E, Perez R, Schildhauer W, Srinivasan D: TVDc: managing security in the trusted virtual datacenter. SIGOPS Oper Syst Rev 2008, 42: 40–47. http://doi.acm.org/10.1145/1341312.1341321 10.1145/1341312.1341321View ArticleGoogle Scholar
- Chowdhury N, Boutaba R: Network virtualization: state of the art and research challenges. Commun Mag IEEE 2009, 47(7):20–26.View ArticleGoogle Scholar
- Fan P, Chen Z, Wang J, Zheng Z, Lyu M: Topology-aware deployment of scientific applications in cloud computing. In Cloud Computing (CLOUD), 2012 IEEE 5th international conference on. Honolulu: IEEE; 2012:319–326.View ArticleGoogle Scholar
- Chae Y, Merugu S, Zegura E, Bhattacharjee S: Exposing the network: support for topology-sensitive applications. In Open Architectures and Network Programming, 2000. Proceedings. OPENARCH 2000. 2000 IEEE Third Conference on. Tel, Aviv: IEEE; 2000:65–74.Google Scholar
- Celesti A, Tusa F, Villari M, Puliafito A: Three-phase cross-cloud federation model: the cloud SSO authentication. In Advances in Future Internet (AFIN), 2010 second international conference on. Venice: IEEE; 2010:94–101.View ArticleGoogle Scholar
- Chowdhury NMK, Boutaba R: A survey of network virtualization. Comput Netw 2010, 54(5):862–876. http://dx.doi.org/10.1016/j.comnet.2009.10.017 10.1016/j.comnet.2009.10.017View ArticleMATHGoogle Scholar
- Bari M, Boutaba R, Esteves R, Granville L, Podlesny M, Rabbani M, Zhang Q, Zhani M: Data center network virtualization: a survey. Commun Surv Tutorials, IEEE 2012, PP(99):1–20.Google Scholar
- Buyya R, Ranjan R, Calheiros RN: InterCloud: utility-oriented federation of cloud computing environments for scaling of application services. In Proceedings of the 10th international conference on algorithms and architectures for parallel processing - Volume Part I, ICA3PP’10. Berlin, Heidelberg: Springer-Verlag; 2010:13–31. http://dx.doi.org/10.1007/978–3-642–13119–6_2View ArticleGoogle Scholar
- Matias J, Jacob E, Sanchez D, Demchenko Y: An OpenFlow based network virtualization framework for the cloud. In Cloud Computing Technology and Science (CloudCom), 2011 IEEE Third International Conference on. Athens: IEEE; 2011:672–678.View ArticleGoogle Scholar
- Vaquero LM, Rodero-Merino L, Morán D: Locking the sky: a survey on IaaS cloud security. Computing 2011, 91: 93–118. http://dx.doi.org/10.1007/s00607–010–0140-x 10.1007/s00607-010-0140-xView ArticleMATHGoogle Scholar
- Iankoulova I, Daneva M: Cloud computing security requirements: A systematic review. Research Challenges in Information Science (RCIS), 2012 sixth international conference on 2012, 1–7.View ArticleGoogle Scholar
- Natarajan S, Wolf T: Security issues in network virtualization for the future Internet. Computing, Networking and Communications (ICNC), 2012 international conference on 2012, 537–543.View ArticleGoogle Scholar
- Security Guidance for Critical Areas of Focus in Cloud Computing V3.0, Cloud Security Alliance Tech. rep. 2011. https://cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf Tech. rep. 2011.
- Rubin A, Geer JDE: A survey of Web security. Computer 1998, 31(9):34–41.View ArticleGoogle Scholar
- Onisick J: Access Layer Network Virtualization: VN-Tag and VEPA. 2012.http://wikibon.org/wiki/v/Edge_Virtual_BridgingGoogle Scholar
- Amazon Virtual Private Cloud Network - Administrator Guidehttp://awsdocs.s3.amazonaws.com/VPC/latest/vpc-nag.pdf Tech. rep. 2012.
- Amazon Virtual Private Cloud - User Guidehttp://awsdocs.s3.amazonaws.com/VPC/latest/vpc-ug.pdf Tech. rep. 2012.
- GoGrid - Getting Started Guide L-20121018http://storage.pardot.com/3442/103057/WP_Getting_Started_L_20121018.pdf Tech. rep. 2012.
- Xu Z, Di S, Zhang W, Cheng L, Wang CL: WAVNet: Wide-area network virtualization technique for virtual private cloud. Parallel Processing (ICPP), 2011 international conference on 2011, 285–294.View ArticleGoogle Scholar
- Benson T, Akella A, Shaikh A, Sahu S: CloudNaaS: a cloud networking platform for enterprise applications. In Proceedings of the 2nd ACM symposium on cloud computing, SOCC ’11. New York: ACM; 2011:8:1–8:13. http://doi.acm.org/10.1145/2038916.2038924Google Scholar
- Edwards A, Fischer A, Lain A: Diverter: a new approach to networking within virtualized infrastructures. In Proceedings of the 1st ACM workshop on Research on enterprise networking, WREN ’09. New York: ACM; 2009:103–110. http://doi.acm.org/10.1145/1592681.1592698View ArticleGoogle Scholar
- Hao F, Lakshman TV, Mukherjee S, Song H: Enhancing dynamic cloud-based services using network virtualization. SIGCOMM Comput Commun Rev 2010, 40: 67–74. http://doi.acm.org/10.1145/1672308.1672322 10.1145/1672308.1672322View ArticleGoogle Scholar
- Rodrigues H, Santos JR, Turner Y, Soares P, Guedes D: Gatekeeper: supporting bandwidth guarantees for multi-tenant datacenter networks. In Proceedings of the 3rd conference on I/O virtualization, WIOV’11. Berkeley: USENIX Association; 2011:6–6. http://dl.acm.org/citation.cfm?id=2001555.2001561Google Scholar
- Lam T, Vahdat A, Radhakrishnan S, Varghese G: NetShare: Virtualizing Data Center Networks across Services. 2010.http://research.microsoft.com/apps/video/dl.aspx?id=132892 Tech. rep., Microsoft Research Lab.Google Scholar
- Mudigonda J, Yalagandula P, Mogul J, Stiekes B, Pouffary Y: NetLord: a scalable multi-tenant network architecture for virtualized datacenters. SIGCOMM Comput Commun Rev 2011, 41(4):62–73. http://doi.acm.org/10.1145/2043164.2018444 10.1145/2043164.2018444View ArticleGoogle Scholar
- Ballani H, Costa P, Karagiannis T, Rowstron A: Towards predictable datacenter networks. SIGCOMM Comput Commun Rev 2011, 41(4):242–253. http://doi.acm.org/10.1145/2043164.2018465 10.1145/2043164.2018465View ArticleGoogle Scholar
- Niranjan Mysore R, Pamboris A, Farrington N, Huang N, Miri P, Radhakrishnan S, Subramanya V, Vahdat A: PortLand: a scalable fault-tolerant layer 2 data center network fabric. SIGCOMM Comput Commun Rev 2009, 39(4):39–50. http://doi.acm.org/10.1145/1594977.1592575 10.1145/1594977.1592575View ArticleGoogle Scholar
- Mudigonda J, Yalagandula P, Al-Fares M, Mogul JC: SPAIN: COTS data-center Ethernet for multipathing over arbitrary topologies. In Proceedings of the 7th USENIX conference on Networked systems design and implementation, NSDI’10. Berkeley: USENIX Association; 2010:18–18. http://dl.acm.org/citation.cfm?id=1855711.1855729Google Scholar
- Greenberg A, Hamilton JR, Jain N, Kandula S, Kim C, Lahiri P, Maltz DA, Patel P, Sengupta S: VL2: a scalable and flexible data center network. SIGCOMM Comput Commun Rev 2009, 39(4):51–62. http://doi.acm.org/10.1145/1594977.1592576 10.1145/1594977.1592576View ArticleGoogle Scholar
- Cao Y, Yang L: A survey of identity management technology. In Information Theory and Information Security (ICITIS), 2010 IEEE international conference on. Beijing: IEEE; 2010:287–293.Google Scholar
- GENI Security Architecture, Global Environment for Network Innovations Tech. rep. http://groups.geni.net/geni/attachment/wiki/GENISecurity/GENI-SEC-ARCH-0.4.pdf Tech. rep.
- Peterson L, Roscoe T, Muir S, Klingaman A: PlanetLab architecture: an overview. 2006. Tech. rep., PlanetLab ConsortiumGoogle Scholar
- Hulsebosch B, Groote R, Snijders M: Secure user-controlled lightpath provisioning with user-controlled identity management. In Proceedings of the 3rd international conference on autonomous infrastructure, management and security: scalability of networks and services, AIMS ’09. Berlin, Heidelberg: Springer-Verlag; 2009:1–14. http://dx.doi.org/10.1007/978–3-642–02627–0_1Google Scholar
- Clem J, MacAlpine T, Badgett B: X-Bone: Automated System for Deployment and Managament of Network Overlays Security Assessment Report. 2003.http://www.isi.edu/xbone/pubs/xbone_security_assessment.pdf Tech. rep., Information Design Assurance Red Team, Sandia National Laboratories, P. O. Box 5800, Albuquerque, NM 87185-0784, 2003.Google Scholar
- Chowdhury N, Zaheer FE, Boutaba R: iMark: An identity management framework for network virtualization environment. In Integrated Network Management, 2009. IM ’09. IFIP/IEEE International Symposium on. Long Island: IEEE; 2009:335–342.View ArticleGoogle Scholar
- Bhargav-Spantzel A, Squicciarini A, Bertino E: Trust negotiation in identity management. Secur Privacy, IEEE 2007, 5(2):55–63.View ArticleGoogle Scholar
- Zhang P, Durresi A, Barolli L: Survey of trust management on various networks. In Complex, Intelligent and Software Intensive Systems (CISIS), 2011 international conference on. Seoul: IEEE Computer Society; 2011:219–226.View ArticleGoogle Scholar
- Winsborough W, Jacobs J: Automated trust negotiation technology with attribute-based access control. In DARPA Information Survivability Conference and Exposition, 2003. Proceedings, Volume 2. Los Alamitos: IEEE Computer Society; 2003:60–62.View ArticleGoogle Scholar
- Li N, Winsborough W: Towards practical automated trust negotiation. In Proceedings of the 3rd international workshop on policies for distributed systems and networks (POLICY’02), POLICY ’02. Washington: IEEE Computer Society; 2002:92–92. http://dl.acm.org/citation.cfm?id=863632.883493Google Scholar
- Winsborough WH, Li N: Protecting sensitive attributes in automated trust negotiation. In Proceedings of the 2002 ACM workshop on Privacy in the Electronic Society, WPES ’02. NY: ACM; 2002:41–51. http://doi.acm.org/10.1145/644527.644532Google Scholar
- Chen J: UCLP Security. 2004.http://www.uclp.ca/files/uclp1.x/Report-UCLP-Security.pdf Tech. rep., School of Information Technology and Engineering University of Ottawa.Google Scholar
- Fukushima M, Hasegawa T, Hasegawa T, Nakao A: Minimum disclosure routing for network virtualization. In Computer communications workshops (INFOCOM WKSHPS), 2011 IEEE Conference on. Shanghai: IEEE; 2011:858–863.View ArticleGoogle Scholar
- Caesar M, Condie T, Kannan J, Lakshminarayanan K, Stoica I: ROFL: routing on flat labels. SIGCOMM Comput Commun Rev 2006, 36(4):363–374. http://doi.acm.org/10.1145/1151659.1159955 10.1145/1151659.1159955View ArticleGoogle Scholar
- Huang D, Ata S, Medhi D: Establishing secure virtual trust routing and provisioning domains for future internet. In Global telecommunications conference (GLOBECOM 2010), 2010 IEEE. Miami: IEEE; 2010:1–6.Google Scholar
- Kent S, Lynn C, Seo K: Secure Border Gateway Protocol (S-BGP). Selected Areas Commun, IEEE J 2000, 18(4):582–592.View ArticleGoogle Scholar
- Goodell G, Aiello W, Griffin T, Ioannidis J, McDaniel P, Rubin A: Working around BGP: an incremental approach to improving security and accuracy of interdomain routing. In In Proc. NDSS. San Diego: Internet Society; 2003.Google Scholar
- Ng J: Extensions to BGP to Support Secure Origin BGP (soBGP). 2002.http://tools.ietf.org/pdf/draft-ng-sobgp-bgp-extensions-00.txt Tech. rep., IETF.Google Scholar
- Kolon M: Intelligent Logical Router Service. 2004.http://netscreen.com/solutions/literature/white_papers/200097.pdf Tech. rep., Juniper Networks.Google Scholar
- Pisa P, Fernandes N, Carvalho H, Moreira M, Campista M, Costa L, Duarte O: OpenFlow and Xen-Based Virtual Network Migration. In Pont A, Pujolle G, Raghavan S (eds) Communications: wireless in developing countries and networks of the future, Volume 327 of IFIP advances in information and communication technology. Berlin, Heidelberg: Springer; 2010:170–181. http://dx.doi.org/10.1007/978–3-642–15476–8_17Google Scholar
- Layer 3 Virtual Switching - Integrated Virtual Routing with Multi-Layer Switching Tech. rep., Extreme Networks, Inc 2006. http://www.extremenetworks.com/libraries/whitepapers/WPL3Virtual_1185.pdf Tech. rep., Extreme Networks, Inc 2006.
- Wang Y, Keller E, Biskeborn B, van der Merwe J, Rexford J: Virtual routers on the move: live router migration as a network-management primitive. SIGCOMM Comput Commun Rev 2008, 38(4):231–242. http://doi.acm.org/10.1145/1402946.1402985 10.1145/1402946.1402985View ArticleGoogle Scholar
- Rus A, Barabas M, Boanea G, Dobrota V: Implementation of QoS-Aware virtual routers. Electronics and Telecommunications (ISETC), 2010 9th International Symposium on 2010, 161–164.View ArticleGoogle Scholar
- Comer D, Martynov M: Building experimental virtual routers with network processors. In Testbeds and Research Infrastructures for the Development of Networks and Communities, 2006. TRIDENTCOM 2006. 2nd International Conference on. Barcelona: IEEE; 2006:9–230.Google Scholar
- Bianco A, Birke R, Bolognesi D, Finochietto J, Galante G, Mellia M, Prashant M, Neri F: Click vs. Linux: two efficient open-source IP network stacks for software routers. In High performance switching and routing, 2005. HPSR. 2005 workshop on. Hong Kong: IEEE; 2005:18–23.View ArticleGoogle Scholar
- Dobrescu M, Egi N, Argyraki K, Chun BG, Fall K, Iannaccone G, Knies A, Manesh M, Ratnasamy S: RouteBricks: exploiting parallelism to scale software routers. In Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles, SOSP ’09. New York: ACM; 2009:15–28.View ArticleGoogle Scholar
- Karlin S, Peterson L: VERA: an extensible router architecture. Open architectures and network programming proceedings, 2001 IEEE 2001, 3–14.Google Scholar
- Spalink T, Karlin S, Peterson L, Gottlieb Y: Building a robust software-based router using network processors. SIGOPS Oper Syst Rev 2011, 35(5):216–229. http://doi.acm.org/10.1145/502059.502056View ArticleGoogle Scholar
- Fu J, Rexford J: Efficient IP-address lookup with a shared forwarding table for multiple virtual routers. In Proceedings of the 2008 ACM CoNEXT Conference, CoNEXT ’08. New York: ACM; 2008:21:1–21:12. http://doi.acm.org/10.1145/1544012.1544033Google Scholar
- Erdem O, Le H, Prasanna V, Bazlamacci C: Hybrid data structure for IP lookup in virtual routers using FPGAs. In Application-Specific Systems, Architectures and Processors (ASAP), 2011 IEEE international conference on. Santa Monica: IEEE; 2011:95–102.View ArticleGoogle Scholar
- Xie G, He P, Guan H, Li Z, Xie Y, Luo L, Zhang J, Wang Y, Salamatian K: PEARL: a programmable virtual router platform. Commun Mag, IEEE 2011, 49(7):71–77.View ArticleGoogle Scholar
- Song H, Kodialam M, Hao F, Lakshman T: Building scalable virtual routers with trie braiding. In INFOCOM, 2010 proceedings IEEE. San Diego: IEEE; 2010:1–9.Google Scholar
- Rathore M, Hidell M, Sjodin P: Performance evaluation of open virtual routers. In GLOBECOM workshops (GC Wkshps), 2010 IEEE. Miami: IEEE; 2010:288–293.View ArticleGoogle Scholar
- Rojas-Cessa R, Salehin K, Egoh K: Experimental performance evaluation of a virtual software router. In Local Metropolitan Area Networks (LANMAN), 2011 18th IEEE Workshop on. Chapel Hill: IEEE; 2011:1–2.View ArticleGoogle Scholar
- Rojas-Cessa R, Salehin K, Egoh K: Evaluation of switching performance of a virtual software router. In Sarnoff symposium (SARNOFF), 2012 35th IEEE. Newark: IEEE; 2012:1–5.View ArticleGoogle Scholar
- Bourguiba M, Haddadou K, Pujolle G: Evaluating the forwarding plane performance of the commodity hardware virtual routers. In Communications and Networking (ComNet), 2010 second international conference on. Tozeur: IEEE; 2010:1–8.Google Scholar
- Pfaff B, Koponen T, Amidon K, Casado M, Pettit J, Shenker S: Extending networking into the virtualization layer. In 8th ACM Workshop on Hot Topics in Networks (HotNets-VIII). NY: ACM SIGCOMM; 2009.Google Scholar
- Congdon P: Virtual Ethernet Port Aggregator Standards Body Discussion. 2008.http://www.ieee802.org/1/files/public/docs2008/new-congdon-vepa-1108-v01.pdfGoogle Scholar
- Pelissier J: VNTag 101. 2008.http://www.ieee802.org/1/files/public/docs2009/new-pelissier-vntag-seminar-0508.pdfGoogle Scholar
- Tseng HM, Lee HL, Hu JW, Liu TL, Chang JG, Huang WC: Network virtualization with cloud virtual switch. In Parallel and Distributed Systems (ICPADS), 2011 IEEE 17th international conference on. Tainan: IEEE; 2011:998–1003.View ArticleGoogle Scholar
- Luo Y: Network I/O virtualization for cloud computing. IT Prof 2010, 12(5):36–41.View ArticleGoogle Scholar
- Bless R, Rohricht M, Werle C: Authenticated setup of virtual links with quality-of-service guarantees. In Computer Communications and Networks (ICCCN), 2011 proceedings of 20th international conference on. Maui: IEEE; 2011:1–8.View ArticleGoogle Scholar
- Manner J, Tschofenig H, Bless R, Stiemerling M: Authorization for NSIS Signaling Layer Protocols. 2001.https://tools.ietf.org/html/rfc5981 RFC5981. Internet Engineering Task Force.Google Scholar
- Bless R, Röhricht M: Secure signaling in next generation networks with NSIS. In Proceedings of the 2009 IEEE international conference on Communications, ICC’09. Piscataway: IEEE Press; 2009:2156–2161. http://dl.acm.org/citation.cfm?id=1817271.1817673Google Scholar
- Lau J, Townsley M, Goyret I: Layer Two Tunneling Protocol - Version 3 (L2TPv3). 2005.http://www.ietf.org/rfc/rfc3931.txt RFC3931. Internet Engineering Task Force.View ArticleGoogle Scholar
- VTun - Virtual Tunnels over TCP/IP networks Tech. rep. http://vtun.sourceforge.net/tun/ Tech. rep.
- Farinacci D, Li T, Hanks S, Meyer D, Traina P: Generic Routing Encapsulation (GRE). 2000.http://www.ietf.org/rfc/rfc2784.txt RFC2784. Internet Engineering Task Force.View ArticleGoogle Scholar
- Simpson W: IP in IP Tunneling. 1995.http://www.ietf.org/rfc/rfc1853.txt RFC1853. Internet Engineering Task Force.View ArticleGoogle Scholar
- Chen X, Phillips C: Virtual router migration and infrastructure sleeping for energy management of IP over WDM networks. Telecommunications and Multimedia (TEMU), 2012 International Conference on 2012, 31–36.View ArticleGoogle Scholar
- Keller E, Ghorbani S, Caesar M, Rexford J: Live migration of an entire network (and its hosts). In Proceedings of the 11th ACM Workshop on Hot Topics in Networks, HotNets-XI. New York: ACM; 2012:109–114. http://doi.acm.org/10.1145/2390231.2390250View ArticleGoogle Scholar
- Keller E, Lee RB, Rexford J: Accountability in hosted virtual networks. In Proceedings of the 1st ACM workshop on Virtualized infrastructure systems and architectures, VISA ’09. New York: ACM; 2009:29–36. http://doi.acm.org/10.1145/1592648.1592654View ArticleGoogle Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.