Transparent VPN failure recovery with virtualization
Yohei Matsuhashi
a, Takahiro Shinagawa
a,∗,1, Yoshiaki Ishii
b, Nobuyuki Hirooka
b, Kazuhiko Kato
aaDepartment of Computer Science, University of Tsukuba, 1-1-1 Tennodai, Tsukuba, Ibaraki 305-8573, Japan
bFujisoft Incorporated, 1-1 Sakuragi, Naka, Yokohama, Kanagawa 231-8008, Japan
a r t i c l e i n f o
Article history:
Received 20 January 2011 Received in revised form 10 May 2011
Accepted 28 May 2011 Available online 6 June 2011
Keywords:
Dependable system Cloud
Virtual private network Virtual machine monitor
a b s t r a c t
Cloud computing is widely used to provide today’s Internet services. Since its service scope is being extended to a wide range of business applications, the security of network communications between clients and clouds are becoming important. Several cloud vendors support virtual private networks (VPNs) for connecting their clouds. Unfortunately, cloud services become unavailable when a VPN failure occurred in a VPN gateway or networks. We propose a transparent VPN failure recovery scheme that can hide VPN failures from users and operating systems (OSs). This scheme transparently recovers from VPN failures by establishing VPN connections in a virtualization layer. When a VPN failure occurs, a client virtual machine monitor (VMM) automatically reconnects to an available VPN gateway which is geographically distributed and connected via leased lines in clouds. IP address changes are hidden from client OSs and servers via a packet relay system implemented by a relay client in the client VMM and a relay server. We implemented a prototype system based on BitVisor, a small client VMM supporting IPsec VPN, and evaluated the prototype system in a wide-area distributed Internet environment in Japan. Experimental results show that our scheme can maintain TCP connections on VPN failures, and performance overhead with the virtualization layer is around 0.6 ms to latency and 8%–30% to throughput.
© 2011 Elsevier B.V. All rights reserved.
1. Introduction
With the growing demand of computing resources, cloud computing is becoming a popular platform for providing today’s Internet services. Since the scope of cloud services is being extended from personal applications to a wide range of business applications, the security of network communications between clients and clouds is increasingly becoming important [1]. Virtual private networks (VPNs) are an attractive technology to ensure the security of network communications because they can encrypt network packets transmitted over the Internet and establish authenticated channels between clients and clouds [2]. In fact, several cloud vendors offer VPN services to connect their clouds [3,4].
Unfortunately, network communications over VPNs are discon- nected when a VPN failure occurs. The causes of VPN failures could be a software or hardware problem in VPN gateways or a part of networks, such as backbone networks, autonomous systems, and server-side network lines [5,6]. In either case, a VPN failure makes
∗Corresponding address: Campuswide Computing Research Division, Informa- tion Technology Center, The University of Tokyo, 2-11-16, Yayoi, Bunkyo-ku, Tokyo 113-8658, Japan.
E-mail addresses:[email protected](Y. Matsuhashi), [email protected],[email protected](T. Shinagawa),[email protected] (Y. Ishii),[email protected](N. Hirooka),[email protected](K. Kato).
1 Takahiro Shinagawa is currently at the University of Tokyo.
VPN gateways unavailable or unreachable, requiring clients to re- connect to a VPN gateway by finding another available VPN gate- way or waiting for the failed VPN gateway to become available again. However, reconnecting to a VPN gateway may require user operations, such as restarting the VPN client. Moreover, TCP con- nections established between clients and cloud servers may be lost after reconnection due to the IP address changes in clients, dis- turbing user experience and decreasing the availability of cloud services.
A popular approach for improving the availability of VPN gateways is using a multiplexing structure with a redundancy protocol [7]. By using multiple VPN gateways, backup gateways can take over the functionality of primary gateways in case of failures in the primary gateways. However, a multiplexing structure cannot recover failures in networks. Using leased lines between clients and clouds, instead of VPNs, contribute to improving the availability of networks. However, using leased lines for each client costs much more than using VPNs. The goal of our research is to improve the availability of VPN communications as a platform in a transparent manner via a software-based scheme that can mitigate failures in VPN gateways and networks.
We propose a transparent VPN failure recovery scheme that leverages virtualization to hide VPN failures from users and operating systems (OSs). This scheme achieves transparency by using a virtual machine monitor (VMM) at the client side to establish VPN connections and detect VPN failures. To mitigate failures in VPN gateways and networks, we place VPN gateways in geographically distributed places and connect them via leased
0167-739X/$ – see front matter©2011 Elsevier B.V. All rights reserved.
doi:10.1016/j.future.2011.05.020
Fig. 1. Assumed cloud environment.
lines in clouds. This allows clients to access cloud servers by finding at least one available and reachable VPN gateway, improving the possibility of maintaining network communications to the clouds.
Changes in client IP addresses are tolerated via a packet relay system that encapsulates IP packets with a relay client in the VMM and a relay server in the clouds.
We implemented a prototype system based on our VPN failure recovery scheme. We used BitVisor [8], a small client VMM capable of supporting VPN connections using IPsec, as a basis to implement our scheme. We evaluated the prototype system in a wide-area distributed Internet environment in Japan with three geographically distributed data centers. Experimental results show that our scheme can maintain TCP connections in VPN failures, and performance overhead in our system was around 0.6 ms to latency and 8%–30% to throughput.
This paper is organized as follows. In Section2, we describe the assumptions of our research. Section3describes our transparent VPN failure recovery scheme, Section4describes the implementa- tion of the scheme, Section5shows the experimental results using a prototype system in a wide-area distributed environment, Sec- tion6describes related work, and Section7gives a summary and our conclusion.
2. Assumptions
This section describes the assumptions of our failure recovery scheme, including the assumed cloud environment and the causes of VPN failures.
2.1. Cloud environment
Fig. 1shows an assumed cloud environment. We assume that cloud servers provide services over VPN channels. Therefore, a client first needs to establish a VPN connection to a VPN gateway provided by cloud vendors. Cloud vendors provide multiple VPN gateways to tolerate failures in VPN gateways. These VPN gateways are installed at geographically – and therefore expected to be network-topologically – distributed places to improve the possibility that a client can reach at least one VPN gateway in case of network failures.
InFig. 1, the client connects to either VPN gateway 1 (‘‘VPN GW 1’’) or VPN gateway 2 (‘‘VPN GW 2’’), consisting of a VPN channel (‘‘VPN Channel 1’’ or ‘‘VPN Channel 2’’). Although there are only two VPN gateways inFig. 1, cloud vendors can provide VPN gateways as much as possible. However, we currently assume that there are at most dozens of gateways, and clients can have a static list of VPN gateways. We also assume that the list of VPN gateways is not frequently changed.
A VPN gateway is connected to a cloud site. Each cloud site consists of multiple servers in the form of data centers and connected with each other via reliable communication channels such as leased lines. InFig. 1, ‘‘Cloud Site 1’’ and ‘‘Cloud Site 2’’ are connected via a leased line. Every server in a cloud site can always be reachable from any VPN gateway because servers are connected with reliable internal networks. This means that a client can reach a cloud server by connecting to any available VPN gateway.
Fig. 2. Overview of the scheme.
Each VPN gateway joins a different network segment of the internal cloud network. When a client connects to a VPN gateway, the VPN gateway assigns an IP address in the network segment to the client. This allows the client to access the cloud network over VPN by using the address. When a client connects to another VPN gateway, the VPN gateway assigns a new IP address to the client.
2.2. Causes of VPN failures
We assume that a VPN failure can occur in either VPN gateways or networks. Failures in VPN gateways might be caused by a hardware error in VPN gateway machines. A VPN gateway failure might also be caused by a VPN server software error due to a bug. We assume any failures that make VPN gateways unavailable. However, we do not assume complex problems, such as Byzantine failures: a VPN gateway either works correctly or simply unavailable.
Failures in networks can occur at various points. For example, a network line between a VPN gateway and the Internet may become unavailable. Failures in a part of the Internet, such as backbone networks, autonomous systems, make a VPN gateway unreachable from clients. However, we assume that at least one VPN gateway of a cloud can be reachable from the Internet. We improve this possibility by installing multiple VPN gateways in geographically distributed places.
We assume that clients can always access the Internet, that is, failures in a client-side network are not assumed. This can be mitigated by introducing backup network lines to the Internet.
We also assume that the client’s hardware and software, including client OSs and VMMs, do not cause problems.
3. Transparent VPN failure recovery
This section describes our transparent VPN failure recovery scheme. We first give an overview of our scheme, and then explain two mechanisms consisting of our scheme.
3.1. Overview
Fig. 2 shows an overview of our transparent VPN failure recovery scheme. This scheme consists of two mechanisms:
VPN management mechanism and packet relay system. The VPN management mechanism works in a client VMM to hide VPN failures from users and OSs. It maintains VPN channels by detecting VPN failures and switching VPN gateways, allowing the client OS to maintain access to cloud services.
The packet relay system consists of a relay client running in the client VMM and a relay server running in clouds. This system hides changes in IP addresses assigned to the client from a VPN gateway by constructing another virtualization layer, called packet relay channels, over the VPN channels. Hiding IP address changes prevents TCP connections between client OSs and cloud servers from being disconnected on VPN failures.
Combining these two mechanisms achieves transparent VPN failure recovery, that is, keeping TCP connections on VPN failures without intervention of users and OSs, improving the availability of cloud services in a platform level.
Fig. 3. Client VMM structure.
3.2. VPN management
We next explain the VPN management mechanisms. This mechanism works in a client VMM and has two modules: failure detection and VPN switching modules. We first explain the client VMM and then explain each module.
Client VMM. A client VMM is used for managing VPN connections without depending on users or OSs. The VMM provides a network interface card (NIC) with the guest OS, and sends/receives Ethernet packets to/from the guest OS. Therefore, the guest OS cannot detect the existence of a VPN: it sends/receives network packets as in normal Ethernet environments. The VMM encapsulates the Ethernet packets with a VPN protocol. There exists a few VMM that supports VPN functionalities [8,9].
We can use any general-purpose VMM as a basis for our scheme, as long as it supports NIC virtualization that can intercept and manipulate the data of Ethernet packets. However, virtualization of other devices, such as disks, USB devices, mouses, keyboards, graphics, and other peripheral devices, is not necessary and can be omitted. The purpose of the client VMM is not to run multiple VMs but to implement VPN functions. Therefore, we can use a small, special-purpose VMM for implementing our scheme.
Fig. 3shows the structure of our client VMM. The VMM has a VPN module to implement VPN functions. In addition, we introduce two new modules: failure detection and VPN switching modules.
The failure detection module monitors network communications between the VPN module and VPN gateways. When the failure detection module detects a VPN failure, it sends a message to the VPN switching module and initiates a failure recovery process.
The VPN switching module finds an available VPN gateway and reconnects to it by using an API provided by the VPN module.
Failure detection. The failure detection module detects VPN failures occurred in VPN gateways or networks by monitoring network communications. Network failures can be detected by sending a keep-alive message to VPN gateways. If a VPN gateway is reachable, a response message is sent back to the client. Therefore, the failure detection module can detect network failures by periodically sending keep-alive messages.
However, sending keep-alive messages to VPN gateways cannot necessarily detect failures in VPN gateways. For example, the VPN software running on a VPN gateway may hang due to software bugs. In that case, the VPN gateway host responses keep-alive messages from clients but VPN connections do not work. To detect failures in VPN gateways, the failure detection module monitors traffic over VPN sessions. It first monitors the inbound traffic, that is, packets from servers to clients. When there is no inbound traffic for a certain period, the detection module checks the VPN connectivity by sending a keep-alive message to a cloud server over the VPN channels. If there is still no inbound traffic, even after sending a few keep-alive messages, the failure detection module determines that the current VPN gateway is unavailable and initiates VPN switch.
VPN
Data
Relay client Relay server
Data layer
Internet layer
Capsule Header
Enapsulation
IP header
Data
IP header
Data
IP header
Data Packet Relay Layer
OS Server
IP header
Capsule Header
Fig. 5. Packet relay system.
VPN switching. The VPN switching module determines a new VPN gateway to be connected and establishes a connection to the gateway.
This module statically has a list of VPN gateways that are provided by cloud vendors. For the load balancing purpose, the VPN switching module randomly selects a VPN gateway from the list and attempts to establish a connection to the gateway. If the selected gateway is also unavailable, it selects another one and try again. If there are many VPN gateways, we could use a more efficient method, such as selecting a nearest gateway first.
Switching gateways is simply done by disconnecting previous sessions by force and connecting to a new VPN gateway. The VPN module provides an API for controlling the connection and the VPN switching module call this API. The VPN switching module also manages configuration information such as the network address of the VPN gateway, options (such as encryption method and hash functions), user identifier and certificate, and so on. This information is safely kept in the VMM.
3.3. Packet relay system
Switching VPN gateways may cause changes in IP addresses. Let us explain this situation using an example. InFig. 4, a VPN client is initially assigned an IP address192.168.0.1. A packet from the VPN client is sent to servers via VPN gateway 1, which has 192.168.1.1as the server-side address. Servers have a routing information that the gateway for192.168.0.1is192.168.1.1, or if the gateway supports network address translation (NAT) or IP masquerade, the source address of packets from the client is changed to192.168.1.1. Therefore, the server sends all packets for the client to192.168.1.1.
After the VPN client switches to VPN gateway 2, the client address assigned by the gateway is changed to192.168.2.1. Even if the VPN gateway uses NAT or IP masquerade, the address of the VPN gateway (192.168.3.1in this case) is different from the previously connected VPN gateway. Therefore, the client address seen from cloud servers is changed. Even if all VPN gateways assign a unique IP address to a client, cloud servers must determine which gateways (192.168.1.1or192.168.3.1) should be used for the client.
In our scheme, IP address changes are handled by the packet relay system. The packet relay system acts as a proxy for the client OS and cloud servers to hide IP address changes. As shown in Fig. 5, the packet relay system encapsulates IP packets transferred
for a client by managing the relationship between a client and VPN gateway. When a request packet to a cloud server arrives from a client via a VPN gateway, the relay server records the relationship between the client and VPN gateway. Based on this relationship information, the relay server can send a replay packet from the cloud server to the same VPN gateway as the request packet came from.
4. Implementation
In this section, we show an implementation of our transparent VPN failure recovery scheme. We first show an implementation of the VPN management mechanism, and then show an implementa- tion of the packet relaying mechanism.
4.1. VPN management
The VPN management mechanism is implemented in a client VMM. We used BitVisor [8] as a base VMM for our implementation.
BitVisor is a small lightweight VMM designed for improving the security of client machines with mandatory encryption of storage and networks. Its architecture, called para-pass-through, allows the VMM to intercept only a part of I/O access necessary to implement security function and pass through other unnecessary access. This architecture contributes to simplifying the VMM and reducing overhead.
The architecture of BitVisor is suitable for our scheme because we only need to intercept network packets sent between the guest OS and NIC devices. We reused the implementation of the IPsec VPN client module of BitVisor and disabled any other function such as storage encryption and ID management.
Failure detection. We implemented the failure detection module to run in the BitVisor VMM. The module monitors the inbound traffic that comes from cloud servers by inserting hooks into the VPN client module. If the traffic is not detected for T seconds, it starts checking whether the VPN connection is alive by using the Internet Control Message Protocol (ICMP) [10]. It sends an ICMP packet to a cloud server and continues to monitor the inbound traffic. If there is still no inbound traffic, including an ICMP reply from the server, for T seconds, it sends an ICMP packet again. After sending an ICMP packet n times and there is still no inbound traffic, it determines that the VPN connection is unavailable and starts VPN switching.
The value T must be determined so that TCP connections between clients and servers are not disconnected during VPN failure detection and VPN switching. We use the Retransmission Time Out (RTO) estimated by Jacobson’s Round Trip Time (RTT) variance, implemented to detect TCP failures in commodity operating systems such as Linux [11]. The following equation estimates smoothed round trip time and the variance to RTO:
RTO=SRTT+β ×RTTVAR. (1)
SRTT expresses smoothed round trip delay time calculated as follows:
SRTTt=(1−α)SRTT+α ×RTT. (2)
RTTVAR expresses variance of the RTT calculated as follows:
RTTVAR=(1−α)RTTVAR+α|SRTT−RTT|. (3) The failure detection module estimates the RTO value by periodically sending ICMP packets to a cloud server, and uses it as T in the scheme described above. We useα = 1/8, β = 4, which are also used in commodity operating systems because there
at the current RTO. The default timeout values in commodity operating systems are∑n+1
i 2i−1 ×RTO(n = 5)for Windows, and(3+15+1) ×RTO for Linux. Therefore, the failure detection module must detect failures within the timeout period. Our current implementation uses a timeout value(n+1) ×RTO(n = 2)to detect failures before the OSs’ TCP timeout period expires.
VPN switching. When a VPN failure is detected, the VPN switching module switches the VPN gateways. The VPN switching module uses the API provided by the VPN client module of BitVisor to switch VPN gateways. The VPN client module provides the following API:
• VPN_IPsec_Init()
• VPN_IPsec_Client_Start()
• VPN_IPsec_Client_Stop()
• VPN_IPsec_Free().
VPN_IPsec_Init() and VPN_IPsec_Free() is used to initialize and terminate the VPN client module. After initialization, VPN_IPsec_Client_Start() is used for establishing a VPN session andVPN_IPsec_Client_Stop()is used for terminating a VPN session. Current implementation of the VPN client module does not support multiple simultaneous sessions. Therefore, the VPN switching module carries out VPN switching by simply terminating the existing connection and connecting to a new VPN gateway. Establishing multiple sessions may reduce the time required to failover. However, as shown in the experimental results in Section 5, current VPN switching is fast enough to hide VPN failures from OSs and maintain TCP connections.
4.2. Packet relay system
Our packet relay system implementation performs two oper- ations: IP capsuling and NAT. IP capsuling is used for identifying clients from servers and hiding IP address changes from the guest OS. NAT is used for hiding IP address changes from servers.Fig. 6 shows these operations when an IP packet is sent from a client to a server.
The packet relay system uses a simple IP header like IP over IP (IPIP) [14] to encapsule IP packets. When a packet is sent from a client to a server, the capsuling IP header has the relay client IP as the source and the relay server IP as the destination (seeFig. 6). The relay client IP is assigned by VPN gateways and different from the IP address assigned to the guest OS (guest IP). We currently assume that the guest IP is unique in a cloud and can be used as a client ID.
When there are many clients, we can append a large (e.g., 128bits) unique identifier, after the capsule IP header.
The relay server manages the relationship between the guest and gateway IPs. In Fig. 6, it records the relationship between
‘‘Guest IP’’ and ‘‘VPN GW IP’’, allowing the relay server to determine the appropriate gateway for a client. The relay server updates the relationship management table every time it receives an IP packet from clients. The relay server also translates the source address of the original IP header to its own IP address. This allows the server to use the same IP address even when the relay client IP address is changed. It also recalculates the check-sum of IP packets. When the server sends back an IP packet to the client, the packet follows a reverse flow path.
The packet relay client is implemented as a module running in BitVisor, and the packet relay server is implemented as a user-level process running on the server.
5. Experiments
This section shows the experimental results of evaluating our scheme. We first show the results of measuring failover time. Then
Fig. 6. IP packet headers.
Fig. 7. Transition of latency to data centers.
we show the results of measuring the performance overhead of our virtualization layer.
5.1. Setup
We conducted the experiments in a wide-area distributed Internet environment in Japan. We placed a client at Tsukuba, and connected it to VPN gateways in data centers in Tokyo, Yokohama, and Fukuoka. The straight-line distances from Tsukuba is approximately 56 km to Tokyo, 84 km to Yokohama, and 926 km to Fukuoka. These data centers are connected via leased lines with a maximum speed of 100 Mbps. The leased lines are actually implemented with yet another VPN provided by an ISP.
We used a PC equipped with Intel Core 2 Duo E8600 (3.33 GHz), PC2-6400 4 GB memory, and Intel X25-V SSD 40 GB as the client machine at Tsukuba. The base VMM is BitVisor 1.1, available from sourceforge site, and the guest OS is Windows XP. Server machines are an HP ProLiand BL280c blade server equipped with Xeon E5502 (1.86 GHz), 2 GB memory, and 120 GB 5400 rpm 2.5 in. HDD. We used a Kernel-based Virtual Machine (KVM) and CentOS 5.4 for both guest and host OSs. A cloud server and the packet relay server each ran on a virtual machine.
5.2. Failover time
The VPN failover time consists of the time to (1) detect a VPN failure, (2) switch VPN gateways, and (3) restart TCP transmission.
According to our scheme, the time to detect a VPN failure is expected to be(n+1)×RTO, where RTO is calculated by Jacobson’s algorithm and n is the retry number. To verify estimated RTO, we first measured the transition of the network latency to each data center.Fig. 7 shows the results. The latency to both Tokyo and Yokoyama was around 15 ms and Fukuoka was 35 ms. In these latencies, the estimated RTO for Tokyo was about 800 ms.
We then measured the failover time. We intentionally caused VPN failures 4 times and measured the transition of TCP throughput between the client and server over VPN for 120 s. As described in Section3.2, a new VPN gateway is randomly selected from the list each time a VPN failure occurs. As shown inFig. 8, the order of the places of selected gateways in our experiment was Fukuoka, Tokyo, Yokohama, and Tokyo.
Fig. 8. Throughput transition over failure.
We also measured the exact timing of detection and switching by monitoring network packets. InFig. 8, the first failure occurred 22.5 s after the start of the experiment. The failure was detected within 2.4 s which correspond to approximately 3×RTO in our environments. After detecting the failure, TCP transmissions of the guest OS are restarted within 800 ms, including 332 ms (197 ms for IKE Phase 1 and 135 ms for IKE Phase 2) to connect to the VPN gateway in Fukuoka by the VMM. As a result, the TCP throughput was recovered within 3.2 s. The experimental results showed that our proposed scheme worked correctly and was effective for hiding VPN failures.
5.3. Performance
We next measured the overhead of the virtualization layer.
In our implementation, the client VMM including the VPN client module incurs overhead. In addition, the packet relay system incurs additional overhead to implement IP capsuling and NAT in a user-level process. We measured the overhead in three environments: ‘‘VPN on OS’’ represents that VPN is implemented in an OS (using YAMAHA YMS-VPN1), ‘‘VPN on VMM’’ represents that VPN is implemented in BitVisor but not using the packet relay system, and ‘‘VPN on VMM with relay’’ represents that VPN is implemented in BitVisor and using the packet relay system. We measured latency and throughput from a client at Tsukuba to each data center over a VPN.
Fig. 9 shows the latency. The overhead of our system was 0.53–0.76 ms in total for each data center: the VMM incurred 0.28–0.53 ms and the packet relay system incurred 0.23–0.25 ms.
Fig. 10shows the throughput. The overhead of our system was about 8%–30% in total: the VMM incurred 4%–16% overhead and the packet relay system incurred 3%–14% overhead. The overhead becomes relatively lower when connecting to a more far data center. The overhead of the packet relay system could be reduced by implementing the system in the OS kernel instead of a user-level process.
Fig. 9. Latency.
Fig. 10. Throughput.
6. Related work
Several researchers used overlay networks based on peer- to-peer technologies to improve the reachability [15–18]. They assume failures and miss configuration in the border gateway protocol (BGP) or autonomous systems. However, these systems require many nodes to construct overlay networks. Our scheme is not a peer-to-peer system and uses a relatively small set of gateways to improve availability of the network.
A router redundancy protocol, such as the virtual router redundancy protocol (VRRP) [7], places master and slave routers in redundancy. When a failure occurs in the master router, the slave router detects the failure and automatically takes over the master router’s functionalities. However, the master–slave structure does not tolerate failures in networks.
Mobile IP [19] achieves transparent IP node migration. It allows the continuation of communication even if a node moves to a different network. However, it is designed for mobile nodes and requires agents such as home and foreign agents than must be continuously available.
FVPN [20] was proposed as a VPN failure recovery framework.
This framework supports seamless network failover by leverag- ing the inherent redundancy of the underlying Internet infras- tructure. However, this framework does not tolerate IP address changes. IPTACR [21] can recover from IPsec pass-through fail- ure. However, it cannot recover from VPN failures because it does not have packet relaying mechanisms to hide IP address changes.
7. Conclusion
We proposed a transparent VPN failure recovery scheme for improving the availability of VPN connections. Our scheme uses a client VMM to transparently detect VPN failures and switch VPN gateways. To maintain TCP connections during VPN switching,
0.6 ms to latency and 8%–30% to throughput.
Currently, our scheme performs recovery operations without depending on the information from cloud sites. However, if the cloud sites provide useful internal status information, such as the point of failures or network congestion, it will allow a better recovery scheme by sharing such information with clients. We plan to address the issue of managing VPN connections in corporation with cloud sites in our future work.
Acknowledgment
This work was supported by Strategic Information and Commu- nications R&D Promotion Programme (SCOPE) from the Ministry of Internal Affairs and Communications.
References
[1] J.M. Agosta, J. Chandrashekar, D.H. Dash, M. Dave, D. Durham, H. Khosravi, H. Li, S. Purcell, S. Rungta, R. Sahita, U. Savagaonkar, E.M. Schooler, Towards autonomic enterprise security: self-defending platforms, distributed detection, and adaptive feedback, Intel technology journal Vol.10 (Issue.4) (2006).
[2] T. Wood, A. Gerber, K.K. Ramakrishnan, P. Shenoy, J.V. Merwe, The case for enterprise-ready virtual private clouds, in: Proc. of HotCloud ’09, 2009.
[3] Amazon Web Service. Amazon virtual private cloud, http://aws.amazon.com/vpc/.
[4] NTT Communications. Salesforce over vpn,http://www.ntt.com/soas/.
[5] C. Labovitz, A. Ahuja, F. Jahanian, Experimental study of internet stability and wide-area backbone failures, in: Proc. of FTCS ’99, Jun 1999, pp. 278–300.
[6] D. Oppenheimer, A. Ganapathi, D.A. Patterson, Why do internet services fail, and what can be done about it? in: Proc. of USITS ’03, Mar 2003.
[7] R. Hinden, Virtual router redundancy protocol. RFC 3768, Apr 2004.
[8] T. Shinagawa, H. Eiraku, K. Tanimoto, K. Omote, S. Hasegawa, T. Horie, M.
Hirano, K. Kourai, Y. Oyama, E. Kawai, K. Kono, S. Chiba, Y. Shinjo, K. Kato, Bitvisor: a thin hypervisor for enforcing i/o device security, in: Proc. of ACM/SIGOPS VEE ’09, Mar 2009, pp. 121–130.
[9] R. Meushaw, D. Simard, Nettop: Commercial technology in high assurance ap- plications. Tech Trend Notes: Preview of Tomorrow’s Information Technolo- gies 9, Sep 2000.
[10] J. Postel, Internet control message protocol, RFC 792, Sep 1981.
[11] V. Jacobson, Congestion avoidance and control, in: Proc. of SIGCOMM ’88, Aug 1988, pp. 314–329.
[12] M. Allman, V. Paxson, On estimating end-to-end network path properties, in:
Proc. of ACM SIGCOMM ’99, Dec 1999, pp. 124–151.
[13] R. Braden, Requirements for internet hosts — communication layers. RFC 1122, Oct 1989.
[14] C. Perkins, Ip encapsulation within ip. RFC 2003, Oct 1996.
[15] J. Aspnes, Z. Diamadi, G. Shah, Fault-tolerant routing in peer-to-peer systems, in: Proc. of ACM PODC ’02, Jul 2002, pp. 223–232.
[16] A. Rowstron, P. Druschel, Pastry: scalable, decentralized object location, and routing for large-scale peer-to-peer systems, in: Middleware 2001, in: Lecture Notes in Computer Science, vol. 2218, Springer, Berlin, Heidelberg, 2001, pp. 329–350.
[17] I. Stoica, R. Morris, D. Karger, M.F. Kaashoek, H. Balakrishnan, Chord: a scalable peer-to-peer lookup service for internet applications, in: Proc. of ACM SIGCOMM ’01, Aug 2001, pp. 149–160.
[18] D. Andersen, H. Balakrishnan, F. Kaashoek, R. Morris, Resilient overlay networks, in: Proc. of ACM SOSP ’01, Dec 2001, pp. 131–145.
[19] C. Perkins, Ip mobility support for ipv4. RFC 3344, Aug 2002.
[20] J. Han, G. Malan, F. Jahanian, Fault-tolerant virtual private networks within an autonomous system. in: Proc. of IEEE SRDS ’02, Oct 2002, pp. 41–50.
[21] J.C. Brustoloni, Automatic vpn client recovery from ipsec pass-through failures, in: Proc. of IEEE LCN ’05, Nov 2005, pp. 756–763.
Yohei Matsuhashi is a student in the Department of Computer Science, Graduate School of Systems and Information Engineering at the University of Tsukuba, Japan. He received the B.E. Degree from the Kanazawa Institute of Technology, Japan, in 2009.
Yoshiaki Ishii is a research engineer at FUJISOFT Incorpo- rated. He received the B.E. degree in industrial engineer- ing and management from Nihon University, in 2005. He joined FUJISOFT Incorporated in the same year, and has engaged in the development of financial information sys- tems etc. He transferred to R&D Department in 2009, and he is engaging in the research and development of the platform for the dependable autonomous federated cloud computing systems. He is a visiting researcher at Center for Tsukuba Advanced Research Alliance (TARA Center), Uni- versity of Tsukuba from 2010.
versity of Tsukuba from 2010.
Kazuhiko Kato received the BE and ME degrees from the University of Tsukuba, Japan, in 1985 and 1987, respec- tively. He received the Ph.D. Degree from the University of Tokyo, Japan, in 1992. He is currently a professor in the De- partment of Computer Science, Graduate School of System Information Engineering at the University of Tsukuba. His research interests include operating systems, distributed systems, and secure computing. He received the distin- guished paper awards from JSSST and IPSJ in 2004 and 2005, respectively.