System and method for cloud survivability of Internet Protocol Security (IPSEC) Security Associations (SA) for cloud orchestration

Abstract

Systems and methods for implementing cloud survivability are provided that mitigate the loss of secure communications via cloud-orchestrated IPsec tunnels due to a loss of connectivity to a cloud service. For example, a device may establish an IPsec tunnel orchestrated by a cloud service, such as an SD-WAN tunnel orchestration. Then, in accordance with the disclosed cloud survivability techniques, if the connection to the cloud service fails, a cloud survivability phase may be triggered that fails over from the IPsec tunnel to the survivability tunnel. In some embodiments, a method includes determining, by an initiator device, whether there is a loss of connectivity between an initiator device or a responder device and a cloud service. In addition, in response to determining that there is a loss of connectivity, a survivability communication link is automatically established between the initiator device and the responder device.

Description

Background Art

[0001] A virtual private network (VPN) extends a private network to a public network and enables users to send and receive data over the public network as if the devices were directly connected to the private network. Therefore, applications running through a VPN may benefit from the functionality, security, and management of a private network. VPNs often utilize Internet Protocol security (IPsec). IPsec is a secure network protocol suite that can be used to authenticate and encrypt data packets to provide secure, encrypted communications between two computers over an Internet Protocol network. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] According to one or more different embodiments, the present disclosure is described in detail with reference to the following drawings. The drawings are provided for illustrative purposes only and only describe typical or exemplary embodiments. These drawings are provided to facilitate the reader's understanding of the various embodiments and should not be considered as limitations on the breadth, scope or applicability of the present disclosure. It should be noted that for clarity and ease of description, these drawings are not necessarily drawn to scale.

[0003] Figure 1 An example networking environment is shown in which Internet Protocol Security (IPsec) security associations (SAs) and the disclosed cloud survivability techniques may be implemented.

[0004] Figure 2 An example for implementing the disclosed cloud survivability technique according to the present disclosure is shown, which includes establishing a survivability tunnel as a fail-safe for an IPsec tunnel in a networking environment.

[0005] Figure 3 is an operational flow diagram illustrating an example method for implementing the disclosed cloud survivability techniques according to implementations of the present disclosure.

[0006] Figure 4 is a block diagram of example computing components or IPsec networking devices for implementing the disclosed cloud survivability techniques including establishing a survivability tunnel, according to one embodiment.

[0007] Figure 5 Depicted is a block diagram of an example computer system in which various embodiments described herein may be implemented.

[0008] The drawings are not intended to be exhaustive or to limit the various embodiments to the precise form disclosed. It should be understood that the various embodiments can be implemented with modification and alteration. DETAILED DESCRIPTION

[0009] The systems and techniques disclosed herein are directed to implementing cloud survivability with respect to secure network communications, for example, secure tunnels established via Internet Protocol Security (IPsec). Cloud survivability generally involves establishing (and maintaining) a secure connection between two computer devices communicating over an Internet Protocol (IP) network, particularly using IPsec. According to the IPsec protocol, a configured tunnel has a clear expiration time (e.g., a default expiration time of 24 hours). During the update of keys to maintain a tunnel in IPsec, if the connection to the cloud service (providing a new key to maintain the tunnel) fails, the current key of the IPsec tunnel will expire. Therefore, a cloud connection interruption (and thus an undesired key expiration) forces the IPsec tunnel offline, which in turn causes a network traffic interruption between devices communicating via the IPsec tunnel. However, the disclosed cloud survivability techniques can help mitigate the loss of secure communications between devices, even if the connection to the cloud is lost. For example, a device can establish an IPsec tunnel orchestrated by a cloud service, such as SD-WAN tunnel orchestration. Then, according to the disclosed cloud survivability technology, if the connection to the cloud service fails for any reason, a cloud survivability phase can be triggered, which fails over from the cloud orchestration tunnel (e.g., IPsec tunnel) to the survivability tunnel (e.g., traditional IKE tunnel / cloud-independent tunnel).

[0010] Before describing in detail embodiments of the disclosed cloud survivability systems and methods, it is useful to describe example network installations in which these systems and methods may be implemented in various applications. Figure 1 An example of a network configuration 100 that can be implemented for an organization, such as a business, educational institution, government entity, healthcare institution, or other organization is shown. The figure shows an example of a configuration implemented with an organization having multiple users (or at least multiple client devices 110) and possibly multiple physical or geographic sites 102, 132, 142. The network configuration 100 can include a main site 102 in communication with a network 120. The network configuration 100 can also include one or more remote sites 132, 142 in communication with the network 120.

[0011] The main site 102 may include a main network, which may be, for example, an office network, a home network, or other network facilities. The main site 102 network may be a private network, for example, a network that may include security and access controls to limit access to authorized users of the private network. Authorized users may include, for example, company employees at the main site 102, house residents, corporate customers, etc.

[0012] In the illustrated example, the master site 102 includes a controller 104 that communicates with the network 120. The controller 104 can provide communication with the network 120 for the master site 102, although it may not be the only point of communication for the master site 102 with the network 120. A single controller 104 is shown, although the master site may include multiple controllers and / or multiple points of communication with the network 120. In some embodiments, the controller 104 communicates with the network 120 through a router (not shown). In other embodiments, the controller 104 provides router functionality to devices in the master site 102.

[0013] The controller 104 is operable to configure and manage network devices (e.g., at the primary site 102), and may also manage network devices at remote sites 132, 134. The controller 104 is operable to configure and / or manage switches, routers, access points, and / or client devices connected to the network. The controller 104 itself may be an access point, or provide the functionality of an access point.

[0014] The controller 104 can communicate with one or more switches 108 and / or wireless access points (APs) 106a-c. The switches 108 and wireless APs 106a-c provide network connectivity to various client devices 110a-j. Using the connection to the switches 108 or APs 106a-c, the client devices 110a-j can access network resources, including the (primary site 102) network and other devices on the network 120.

[0015] Examples of client devices may include: desktop computers, laptop computers, servers, network servers, authentication servers, authentication-authorization-accounting (AAA) servers, domain name system (DNS) servers, dynamic host configuration protocol (DHCP) servers, Internet Protocol (IP) servers, virtual private network (VPN) servers, network policy servers, mainframes, tablet computers, e-readers, netbook computers, televisions and similar monitors (e.g., smart TVs), content receivers, set-top boxes, personal digital assistants (PDAs), mobile phones, smart phones, smart terminals, dumb terminals, virtual terminals, video game consoles, virtual assistants, Internet of Things (IOT) devices, etc.

[0016] Included within the primary site 102 is a switch 108, which serves as an example of an access point to a network established for wired client devices 110i-j within the primary site 102. The client devices 110i-j may connect to the switch 108 and, through the switch 108, may access other devices within the network configuration 100. The client devices 110i-j may also access a network 120 through the switch 108. The client devices 110i-j may communicate with the switch 108 through a wired connection 112. In the illustrated example, the switch 108 communicates with the controller 104 through the wired connection 112, although the connection may also be wireless.

[0017] Wireless APs 106a-c are included as another example of access points for a network established for client devices 110a-h in the main site 102. Each of the APs 106a-c may be a combination of hardware, software, and / or firmware configured to provide wireless network connectivity to the wireless client devices 110a-h. In the illustrated example, the APs 106a-c may be managed and configured by the controller 104. The APs 106a-c communicate with the controller 104 and the network via a connection 112, which may be a wired or wireless interface.

[0018] Network configuration 100 may include one or more remote sites 132. Remote sites 132 may be located in a different physical or geographic location than primary site 102. In some cases, remote sites 132 may be in the same geographic location as primary site 102, or perhaps in the same building, but lack direct connectivity to a network located within primary site 102. Instead, remote sites 132 may utilize connectivity on a different network, such as network 120. For example, Figure 1 The remote site 132 shown may be, for example, a satellite office, another floor or suite in a building, etc. The remote site 132 may include a gateway device 134 for communicating with the network 120. The gateway device 134 may be a router, a digital-to-analog modem, a cable modem, a digital subscriber line (DSL) modem, or some other network device configured to communicate with the network 120. The remote site 132 may also include a switch 138 and / or an AP 136 that communicate with the gateway device 134 via a wired or wireless connection. The switch 138 and the AP 136 provide connectivity to the network for the various client devices 140a-d.

[0019] In various embodiments, the remote site 132 may communicate directly with the primary site 102 such that client devices 140a-d at the remote site 132 access network resources at the primary site 102 as if the client devices 140a-d were located at the primary site 102. In such embodiments, the remote site 132 is managed by the controller 104 at the primary site 102, and the controller 104 provides the necessary connectivity, security, and accessibility to enable the remote site 132 to communicate with the primary site 102. Once connected to the primary site 102, the remote site 132 may act as part of a private network provided by the primary site 102.

[0020] In various embodiments, the network configuration 100 may include one or more smaller remote sites 142, including only a gateway device 144 and a wireless AP 146 for communicating with the network 120, and various client devices 150a-b access the network 120 through the wireless AP 146. Such a remote site 142 may represent, for example, the home of an individual employee or a temporary remote office. The remote site 142 may also communicate with the main site 102, so that the client devices 150a-b at the remote site 142 access the network resources at the main site 102, as if these client devices 150a-b were located at the main site 102. The remote site 142 may be managed by the controller 104 at the main site 102 to make this transparency possible. Once connected to the main site 102, the remote site 142 may act as part of the private network provided by the main site 102.

[0021] The network 120 may be a public wide area network (WAN), such as the Internet or other communication network that allows connectivity between the various sites 102, 130 to 142 and access to the servers 160a-b. The network 120 may include third-party telecommunication lines, such as telephone lines, broadcast coaxial cables, fiber optic cables, satellite communications, cellular communications, etc. The network 120 may include any number of intermediate network devices, such as switches, routers, gateways, servers, and / or controllers, which are not directly part of the network configuration 100, but facilitate communication between the various parts of the network configuration 100 and between the network configuration 100 and other network-connected entities. The network 120 may include various content servers 160a-b. The content servers 160a-b may include providers of various multimedia downloadable and / or streaming content, including audio, video, graphics, and / or text content or any combination thereof. Examples of content servers 160a-b include, for example, web servers, streaming broadcast and video providers, and cable and satellite television providers. Client devices 110a-j, 140a-d, 150a-b may request and access multimedia content provided by content servers 160a-b.

[0022] exist Figure 1 In the example deployment shown, the devices are connected via a WAN (i.e., network 120). It should be understood that the cloud survivability techniques can be used in deployment scenarios where the devices are layer 3 or connected layer 3. Figure 1 As a related example, a situation where network 120 is disrupted may result in a widespread disruption of the network. For example, if devices utilizing IPsec lose their connection to a cloud service via network 120, such connectivity issues may result in the inability to rekey IPsec keys, which may further result in the associated IPsec tunnel being shut down. Such unexpected and sporadic loss of tunnels that provide secure communications for devices on the network may negatively impact the overall network implementation.

[0023] Various embodiments of the disclosed cloud survivability technology are now described. Specifically, Figure 2 An example of a network environment 200, such as an SD-WAN 200, in which cloud survivability techniques may be implemented is depicted. The SD-WAN 200 may be designed to fully support an on-premises data center (in Figure 2 202). In this example, the SD-WAN 200 may have a topology including multiple branch offices 203a, 203b and a data center 202 that are communicatively connected via a communication network 210. The branch offices 203a, 203b may be located in different geographical locations and connected to the data center 202 that is distributed away from the respective locations of the branch offices 203a, 203b. In this example, each of the branch offices 203a, 203b includes a respective branch gateway (BG) 208a, 208b deployed thereon. Each of the BGs 208a, 208b may serve as an interface for incoming and / or outgoing traffic of its respective branch office 203a, 203b. For example, the BG 208a may interface with uplink traffic from one or more client devices at the branch office 203a that is routed to the communication network 210, and interface with downlink traffic from the communication network 210 that is directed to an appropriate one of the client devices of the branch office 203a.

[0024] in addition, Figure 2 It is shown that each data center 202 may have a cluster of VPN concentrators (VPNCs) 206a, 206b and servers 204 deployed thereon. Networking devices referred to as VPN concentrators (VPNCs) 206a, 206b are used to establish and configure tunnels, authenticate users, assign tunnels to users, ensure the delivery of data flowing through the tunnels, and encrypt and decrypt data. For ease of deployment and management, VPN concentrators are typically grouped into clusters, such as Figure 2In this example, data center 202a has a cluster including VPNC 206a, 206b and server 206. It should be understood that Figure 2 The network configuration in is an example and is not intended to be limiting. For example, a cluster may include any number of VPNCs deemed necessary and / or appropriate.

[0025] Figure 2 An example environment is shown in which IPsec can be used to provide secure connections between devices at branch offices 203a, 203b over a network 210 (e.g., the Internet), which can be implemented as a private network. For example, branch office 203a can include a first local area network (LAN) or wide area network (WAN) served by an IPsec networking device such as BG 208a, and branch office 203b can include a second local area network (LAN) or wide area network (WAN) served by an IPsec networking device such as BG 208b.

[0026] According to an embodiment, BG 208a, 208b and VPNC 206a, 206b are implemented as IPsec networking devices. The term "IPsec networking device" used herein refers to a device on which the IPsec protocol operates. Other examples of IPsec networking devices (on which the IPsec protocol can operate) may include, but are not limited to: routers; gateways, switches; firewall devices; servers; workstations; etc. Therefore, in operation, each BG 208a, 208b can form an IPsec tunnel (e.g., VPN tunnel) with these VPNC 206a, 206b in the cluster at the data center 202 via (multiple) WAN uplinks. In the illustrated example, a secure IPsec tunnel 260a can be formed between BG 208a and VPNC 206a, and another secure IPsec tunnel 260b can be formed between BG 208b and VPNC206b.

[0027] exist Figure 2 In the example of , BG 208a and VPNC 206a and BG 208b and VPNC 206b are configured as IPsec peers to establish a connection including a secure IPsec tunnel 260 by initiating an IPsec data exchange, thereby authenticating and initiating a secure connection through the network 210. As part of the IPsec data exchange process, incoming and outgoing security keys and IPsec SAs may be initialized and updated over time. According to the IPsec protocol, the IPsec networking device can be used to transparently process and route information from / to the branch offices 203a, 203b and from / to the data center 202. In some implementations, Figure 2The environment can also implement a pre-shared key (PSK) or a certification authority, which can be used to avoid man-in-the-middle attacks or spoofed nodes in the network.

[0028] Thus, IPsec can be used to build a virtual private network (VPN) for a remote site through network 210, which can be a public network (e.g., the Internet). It should be understood that the implementations described herein need not be limited to Figure 2 The network topology shown. For example, in an enterprise environment, IPsec can be implemented to provide remote access VPNs for individual user devices, to provide intranet VPNs to connect to remote sites, and / or to provide extranet VPNs. In the case of providing remote access VPN access to a user device (e.g., a user's laptop), the user device itself can include a VPN client configured to run an IPsec application, and the user device can be used as an IPsec networking device according to the present disclosure.

[0029] Thus, IPsec tunnels 260a, 260b may establish a secure VPN over an unsecured (eg, public) network 210 (eg, the Internet). Figure 2 The embodiments of the present invention are described as using BG to establish IPsec tunnels, but it should be understood that the disclosed technology can be used to establish IPsec tunnels and cloud survivability using any network point that can support this function, for example, via a layer 3 network (such as Figure 1 The AP and controller are connected as shown in Figure 1.

[0030] For context, IPsec describes a set of secure network protocol standards that use cryptography to protect communications over Internet Protocol (IP) networks. It can be used to authenticate endpoint hosts and provide data confidentiality and integrity. IPsec can use the Internet Key Exchange (IKE) protocol to authenticate each peer in an IPsec session, negotiate security associations (SAs) between peers, and handle the exchange of session keys. IKE is a component of IPsec that performs mutual authentication and establishes and maintains SAs.

[0031] The IPsec data exchange between two peers may include five steps: i) initiation of an IPsec session; ii) IKE phase 1; iii) IKE phase 2; iv) data transfer; and v) IPsec session termination. IPsec session initiation (e.g., VPN tunnel) may be triggered when network traffic is marked as protected based on a certain IPsec security policy configured in the IPsec peers. For example, network traffic determined to be a specific type may be marked as protected based on the security policy, while other traffic may be transmitted normally over the public network. After the session is initiated, the IKE process may begin. During IKE phase 1, security parameters and keys required to establish an IKE security association (SA) may be negotiated. IKE phase 1 may include: authenticating the identity of the IPsec peers; negotiating a common IKE SA policy between the peers to protect the IKE exchange; a Diffie-Hellman (DH) key exchange for creating a shared key; and setting up a secure tunnel to negotiate IKE phase 2 parameters.

[0032] During IKE Phase 2, the two peers can negotiate a shared IPsec policy; and negotiate the security parameters and incoming / outgoing security keys required to establish two unidirectional IPsec SAs (e.g., one for incoming traffic and one for outgoing traffic). Thereafter, traffic can be exchanged during the IPsec session, with packets encrypted / decrypted at the peer using the encryption specified in the IPsec SA. In addition, traffic can be authenticated.

[0033] The devices at both ends of an IPsec tunnel are considered IPsec peers. Figure 2 In the example of , BG 208a and VPNC 206a connected via IPsec tunnel 260a can be considered as IPsec peers, and BG 208a and VPNC 206a connected via IPsec tunnel 260b can be considered as IPsec peers. To build the IPsec tunnel, the IPsec peers (e.g., BG 208a and 206a) exchange a series of messages about encryption and authentication and attempt to reach agreement on many different parameters during the VPN negotiation process, as described in detail above. One device of the IPsec peers acts as the initiator in the negotiation sequence, while the other device is the responder. As an example, BG 208a, 208b can be the initiator in their respective negotiations, while VPNC 206a, 206b acts as the responder.

[0034] According to some standards, IPsec SAs may be created to have a limited lifetime (e.g., in terms of time or traffic volume). In order to ensure uninterrupted traffic (e.g., traffic that was interrupted by an expired SA), the IPsec SA must be "re-keyed". As described herein, re-keying refers to creating a new IPsec SA to replace an expiring IPsec SA before the IPsec SA expires (e.g., to ensure minimal traffic loss). The initiator (e.g., BG 208a) and the responder VPNC (e.g., 206a) may maintain two IPsec SAs for a period of time during which they may receive (inbound) on both IPsec SAs. Inbound traffic on the old IPsec SA will only stop (switching outbound to the new SA) after each node explicitly knows that the peer is ready to start sending on the new SA.

[0035] In some implementations, the aforementioned IPsec SA key update involves the use of a cloud service. An example of such a cloud service is Figure 2208a, 208b and VPNC 206a, 206b. In some implementations, tunnel orchestration 250 can negotiate keys for IPsec networking devices BG 208a, 208b and VPNC 206a, 206b and provide the keys directly to the devices for use. In addition, tunnel orchestration 250 can support key updates, for example, by generating new security keys associated with new IPsec SAs (replacing expiring IPsec SAs). Subsequently, during key updates, the new security keys can be transmitted to the initiator (e.g., BG 208a, 208b) and the responder (VPNC 206a, 206b). As previously described, once the cloud service pushes the new key set to the initiator (e.g., BG 208a, 208b) and responder (e.g., VPNC 206a, 206b), the IPsec SA can be set up. A pair of separate IPsec SAs are set up for AH and ESP conversions. Each IPsec peer agrees to set up IPsec SAs, which consist of policy parameters used during the IPsec session. IPsec SAs are unidirectional for IPsec, so that the initiator (e.g., BG 208a) will provide the policy to the responder (e.g., VPNC 206a). If the responder (e.g., VPNC 206a) accepts the policy, the policy will be sent back to the initiator (e.g., BG 208a). Negotiation establishes two unidirectional IPsec SAs between the IPsec peers, BG 208a and VPNC 206a. According to the IPsec standard, bidirectional communication consists of two IPsec SAs, i.e., one IPsec SA for each communication direction.

[0036] Figure 2 Each of the BGs 208a, 208b and VPNCs 206a, 206b is shown using a communication link that provides connectivity to the cloud service, namely, tunnel orchestration 250. In particular, BG 208a is connected to tunnel orchestration 250 via link 215a, and BG 208b is connected to tunnel orchestration 250 via link 215b. Similarly, VPNCs 206a, 206b have connectivity to tunnel orchestration 250, with VPNC 206a connected to tunnel orchestration 250 via link 216a, and VPNC 206b connected to tunnel orchestration 250 via link 216b. Although Figure 2Communication links 215a, 215b, 216a, and 216b are shown in FIG, but in some embodiments, BGs 208a, 208b and VPNCs 206a, 206b may connect to cloud service tunnel orchestration 250 using the same uplinks used to connect to network 210 (eg, WAN).

[0037] Since the cloud service (shown as tunnel orchestration 250) is necessary for key updates, and key updates are required to properly maintain the IPsec tunnel, continued connectivity of the initiator and responder to the cloud service may be critical. Figure 2 In the example of , BGs 208a, 208b and VPNCs 206a, 206b need to maintain connectivity to tunnel orchestration 250 in order to rekey (or provision new key sets) IPsec tunnels 260a, 260b. Therefore, if BGs 208a, 208b (e.g., initiators) or VPNCs 206a, 206b (e.g., responders) experience a loss of connectivity to tunnel orchestration 250, this can further result in widespread disruption of secure VPN communications because IPsec keys are not rekeyed and IPsec tunnels 260a, 260b are disrupted. In other words, without implementing the disclosed cloud survivability techniques, a loss of connectivity to tunnel orchestration 250 on network 210 (e.g., disruption to any of communication links 215a, 215b, 216a, and 216b) can cause disruption to communications throughout SD-WAN 200.

[0038] also, Figure 2Different link configurations are shown, namely survivability tunnels 270a, 270b, which are implemented by cloud survivability techniques as disclosed herein. As mentioned herein, a "survivability tunnel" can be considered as a secure communication link between devices that serves as a fail-safe (also known as failover) when the loss of connectivity to the cloud also threatens the survivability of the IPsec tunnel. Survivability tunnels are enhancements provided by the disclosed cloud survivability techniques that allow devices to remain connected (with respect to survivability tunnels) even if the cloud connection fails for any reason. In other words, a key feature of survivability tunnels is that such link mechanisms can be established and maintained without the need to continuously download key material from the cloud service to the initiator and responder, which is required for IPsec tunnels. According to an embodiment, both the initiator (e.g., BG 208a, 208b) and the responder (e.g., VPNC206a, 206b) can store tunnel configuration data received from tunnel orchestration 250 or other cloud services. The cloud service can establish an IPsec tunnel based on a factory-cert authentication, which can be performed between the cloud service and the device. Thus, the disclosed technology can utilize these aspects to implement survivability tunnels 270a, 270b. That is, the survivability tunnels can be established as traditional IKE / IPsec tunnels (e.g., without requiring connectivity to a cloud service), creating these tunnels by utilizing factory certificate authentication as an authentication mechanism to ensure trust between devices and utilizing tunnel configuration data that has been received from a cloud service. In some embodiments, the key update expiration time associated with the survivability tunnel will be the same as the time when the last configuration was received from the cloud service.

[0039] After the initial establishment of the IPsec tunnel 260a, 260b, the IPsec networking device (i.e., the BG 208a, 208b and the VPNC 206a, 206b) will attempt to trigger a key update request before receiving the previously configured key expiration time. In nominal operation (e.g., maintaining connectivity with the cloud service), the initiator (e.g., BG 206a, 206b) and the responder (e.g., VPNC 206a, 206b) will receive key material from the tunnel orchestration 250 during the key update, which allows maintenance of the IPsec tunnel 260a, 260b. However, in the event of a loss of connectivity to the cloud service, at least one of the initiator (e.g., BG 208a, 208b) or the responder (e.g., VPNC 206a, 206b) becomes susceptible to being unable to receive the necessary key material from the tunnel orchestration 250. In turn, maintenance of the IPsec tunnels 260a, 260b may be compromised due to the lack of key update information received from the tunnel orchestration 250. Currently, such a loss of connectivity to the cloud would cause the IPsec tunnels 260a, 260b to be shut down, thereby disrupting communications between the BGs 208a, 208b and the VPNCs 206a, 206b. In contrast, the cloud survivability techniques disclosed herein may initiate a survivability phase in the event of a disruption in connectivity to cloud services, which allows the initiator (e.g., BGs 208a, 208b) and responder (e.g., VPNCs 206a, 206b) to continue secure communications over the tunnels. In an example environment, upon detecting that connectivity to the tunnel orchestration 250 has been disrupted in a manner that threatens the survivability of the IPsec tunnels 260a, 260b, the survivability techniques may establish survivable tunnels 270a, 270b for use. By utilizing the survivability tunnels 270a, 270b, communications between IPsec peer BGs 208a, 208b and VPNCs 206a, 206b are kept away from the IPsec tunnels 260a, 260b which are potentially affected by a loss of connectivity with the cloud and tunnel orchestration 250.

[0040] exist Figure 2In the example of FIG. 2 , an initiator BG 208b is shown experiencing a loss of connectivity to the tunnel orchestration 250. Connections such as communication link 215b may be lost due to a plethora of reasons, network failures, hardware failures, network performance and / or quality issues, etc. For example, when a cloud infrastructure service is unavailable, the communication link 215b between BG 208b and the tunnel orchestration 250 may be lost due to a cloud outage. The cloud outage may also cause communications with nodes available via the cloud (e.g., the communication link 215b to the tunnel orchestration 250) to be interrupted during this period. As one aspect of cloud survivability techniques, an initiator (e.g., BG 208b) may detect when there is a loss of connectivity to a cloud service due to, for example, a cloud outage. In one embodiment, BG 208b may detect that its connection 215b to the tunnel orchestration 250 on the network 210 has been interrupted (e.g., the device does not recognize the existence of the communication link 215b). In addition, BG 208b may detect that further attempts to restore the communication link 215b or another connection to the tunnel orchestration 250 have failed. In another embodiment, cloud connectivity loss may be determined when a new IPsec SA fails to be established using a tunnel configuration provided by a cloud service before the current key expires. In this case, receiving an incorrect tunnel configuration may indicate a failure or malfunction of the cloud service (as opposed to a cloud outage).

[0041] In the case of a Layer 3 network configuration, for example, using access points such as Figure 1 ), if no response is received to any message sent to the cloud service, it can be determined that cloud connectivity loss is detected. For example, when there is no response to a key update request that has been transmitted to the cloud service (within a specified amount of time), the cloud survivability technology can determine that there is cloud connectivity loss.

[0042] in addition, Figure 2An example is shown where the communication link 216a between VPNC 206a and tunnel director 250 is interrupted. In this example, VPNC 206a acts as a responder, as previously described. In accordance with one aspect of cloud survivability techniques, initiators can also detect whether their peers (i.e., responders) are experiencing a loss of connectivity to cloud services (even if the initiator continues to have connectivity to the cloud services). For example, in this example, an initiator (e.g., BG 208a) can successfully transmit a key update request to tunnel orchestration 250 via communication link 215a. Subsequently, in response, BG 208a, acting as an initiator, can receive new keying material from tunnel orchestration 250. However, as described above, VPNC 206a, acting as a responder, will not have these same new keying materials because it has lost connectivity to tunnel orchestration 250. Therefore, BG 208a will not be able to start IPsec tunnel 260a because both the initiator (e.g., BG 208a) and the responder (e.g., VPNC 206a) need to receive new keying material from the cloud service to start the tunnel. Therefore, in the event that BG 208a has received new keying material during a key update, but fails to start IPsec tunnel 260a accordingly, such failure can serve as an indication to the initiator (e.g., BG 208a) that the responder (e.g., VPNC 206a) has lost their connection to the cloud service (i.e., tunnel orchestration 250). In other words, the disclosed cloud survivability techniques enable an initiator to detect or otherwise determine whether a responder of its IPsec peer has lost connectivity to the cloud service. According to an embodiment, survivability can be triggered when it is detected that the initiator or responder has lost connectivity to the cloud service during a key update.

[0043] After detecting a loss of connectivity to the cloud service, cloud survivability may then trigger survivability, which establishes a survivability tunnel 270a, 270b. The survivability process may be performed at a set time period before the current IPsec tunnel expires. In some embodiments, the survivability process is performed at least 2 minutes before the current IPsec tunnel expires, the survivability process including initiating a survivability tunnel. Thus, reference is made to Figure 2 In the example environment, 2 minutes before the IPsec tunnel 260a expires, the BG 208a acting as the initiator may start the survivability tunnel 270a, and 2 minutes before the IPsec tunnel 260b expires, the BG 208b acting as the initiator may start the survivability tunnel 270b.

[0044] To establish the survivability tunnels 270a, 270b, the cloud survivability technology may involve creating an IKE tunnel configuration with the same set of transforms previously received from the cloud service (e.g., when connectivity to the cloud microservice was available). In addition, to authenticate the IPsec peers for use of the survivability tunnel, the cloud survivability technology may configure the authentication method to be a factory certificate. For example, IPsec peers BG 208a (e.g., initiator) and VPNC 206a (e.g., responder) and BG 208b (e.g., initiator) and VPNC 206b (e.g., responder) may be authenticated with certificate-based authentication. Subsequently, after performing certificate-based authentication on the IPsec peers, the cloud survivability technology may initiate IKE phase one and phase two to start the survivability tunnel for use. Reference Figure 1 , BG 208a (e.g., initiator) and VPNC 206a (e.g., responder) and BG 208b (e.g., initiator) and VPNC 206b (e.g., responder) can trigger the traditional IKE first phase and second phase of VPN negotiation, as described in detail above, which respectively create survivability tunnels 270a, 270b. In the event that the survivability tunnel fails to be established after the first attempt, the cloud survivability technology can restart the process again in an iterative manner until the survivability tunnel is successfully established. As a result, as disclosed herein, the cloud survivability technology can provide increased reliability, ensuring that cloud survivability is properly initiated to support switching from a damaged IPsec tunnel.

[0045] After the survivability tunnels 270a, 270b are fully established, BG 208a and VPNC 206a, as well as BG 208b and VPNC 206a, continue to communicate securely, beginning to use the survivability tunnels 270a, 270b as a form of backup tunnels for the IPsec tunnels. For example, BG 208a and VPNC 206a can fail over from communicating through IPsec tunnel 260a and re-establish their secure communications through survivability tunnel 270a, as if these IPsec peers were still using IPsec tunnel 260a. Therefore, the disclosed cloud survivability technology provides an enhancement to current IPsec technology that circumvents the impact of cloud service interruptions. That is, the disclosed cloud survivability process automatically triggers the creation of a survivability tunnel for failover from an IPsec tunnel that may be unexpectedly interrupted due to loss of connectivity to the cloud service.

[0046] Figure 33 is an operational flow chart illustrating an example method 300 according to an embodiment that may be implemented by an IPsec networking device to implement cloud survivability techniques. The process 300 is illustrated as a series of executable operations in a machine-readable storage medium 301 executed by a hardware processor 302. As previously described, the computing component 303 may be a computer device that is an IPsec networking device, such as an AP ( Figure 1 shown) or gateway ( Figure 2 shown).

[0047] Now with specific reference to the operation of the method shown, the process can start at operation 310. At operation 310, it can be determined whether there is a loss of connectivity to the cloud device. As described above, the IPsec tunnel is configured to start within a specified time. Before the current IPsec tunnel expires, the IPsec peers at both ends of the IPsec tunnel participate in a key update process. During the key update, each IPsec peer receives new key material from the cloud service for establishing a new IPsec SA (to maintain the tunnel for continued use). In some embodiments, the associated IPsec tunnel is keyed at a set time, where one of the IPsec peer devices can detect whether there is a loss of connectivity to the cloud service. For example, a cloud / network outage may be the root cause of the IPsec networking device losing connectivity to the cloud service. According to some embodiments, the IPsec networking device acting as an initiator can perform a determination at operation 310. Detecting a loss of connectivity in operation 310 may include determining whether at least one of the initiator or responder of the IPsec peer has lost their connection to the cloud service.

[0048] To perform operation 310, an IPsec networking device implementing cloud survivability techniques may use various mechanisms to detect connectivity loss, including, but not limited to: detecting the loss of a physical communication link to a cloud service and failed attempts to reestablish the communication link; detecting the absence of a response from the cloud service (e.g., for all messages sent by the device); detecting a failure to establish a new cloud IPsec SA using a tunnel configuration provided by the cloud service before the current key expires; detecting a failure to start an IPsec tunnel (e.g., an indication that the responder has lost connectivity to the cloud service).

[0049] Next, at operation 320, if a loss of connectivity is detected, a conditional check may be performed to trigger a survivability action of process 300. That is, the result from the previous operation 310 may be used to satisfy check 320, which identifies whether the IPsec peer is experiencing a loss of connectivity to the cloud service. For example, if operation 310 determines that no response has been received from the cloud service (e.g., after a determined period of time), then at operation 320, the check indicates that there is indeed a loss of connectivity, which may result in the unexpected loss of the current IPsec tunnel. As a result of identifying a loss of connectivity (at Figure 3 ), operation 320 initiates survivability and proceeds to operation 330. Alternatively, if no loss of connectivity to the cloud service is identified (in Figure 3 ), indicating that both the initiator and the responder should receive new key material from the cloud service (as expected in the nominal IPsec negotiation). In this case, since the cloud service connection is not interrupted, the key update should be successful and the possibility of IPsec tunnel loss is low. Therefore, process 300 continues to operation 325, in which the IPsec peers can continue to use the current IPsec tunnel for secure communication after the key update.

[0050] Referring back to operation 330, the process 300 begins the survivability phase of the method based on detecting that there has been a loss of connectivity (either the initiator or the responder) to the cloud service. As described above, such a loss can compromise the IPsecSA during a key update, thereby affecting the ability to maintain the current IPsec tunnel. By triggering the survivability phase, the process 300 can automatically perform a failover of a survivability tunnel (e.g., a traditional IKE / IPsec tunnel configured to not require a cloud service), which is initiated as a form of backup for an IPsec tunnel that may be lost (e.g., due to an inability to complete a key update during a connectivity loss). As an example, if no IPsec tunnel is formed, the survivability phase of the process 300 can be triggered at the last 2 minute mark (e.g., after receiving the last key update configuration or after a probe failure), for example, after 8 key update attempts. In the event that the initiator triggers the survivability phase, the responder receives this trigger from the initiator for establishment of the survivability tunnel.

[0051] At operation 330, an IKE tunnel configuration is created. As previously described, the survivability tunnel may be configured as a traditional IKE / IPsec tunnel. Thus, the IKE configuration created in operation 330 may ultimately be applied to create or initiate an IPsec tunnel. According to an embodiment, the IKE configuration may be the same set of transforms previously received from the cloud service (e.g., received from the last successful key update when connectivity to the cloud service was available).

[0052] Thereafter, at operation 340, the method for performing negotiation between IPsec peers may be set to factory certificates. In other words, negotiation between IPsec peers is adjusted according to the authentication method applied by cloud orchestration (requires connection to cloud services) and enables the device to start a survivability tunnel using certificate-based authentication (does not require connection to cloud services). The responder may authenticate the initiator using the factory certificate provided by the user. The IPsec peer will first be checked using the IPsec configuration received from the cloud service. After the authentication method has been set to factory certificates, process 300 may continue to 350.

[0053] Operation 350 establishes a survivability tunnel based on the configuration set in the previous operations 340 and 330. Operation 350 may involve performing IKE Phase I and Phase II of IPsec negotiation, as described in more detail above. That is, operation 350 uses the factory certificate authentication established in the previous operation 340 to perform a traditional IKE process for tunnel configuration. As a general description, the first phase establishes a secure encrypted channel through which the two peers can negotiate the second phase. When the first phase is successfully completed, the IPsec peers can proceed to the second phase of negotiation. The second phase negotiation allows the two peers to reach an agreement on the IPsec SA. The configuration of the first and second phases must match the devices at both ends of the tunnel before the survivability tunnel can be initiated.

[0054] Next, operation 360 performs a conditional check to determine if the survivability tunnel was successfully established. Operation 360 is a mechanism that ensures that the survivability phase has initiated the survivability tunnel in a manner that allows the IPsec peers to switch from the IPsec tunnel for communication. For example, if there was a problem during the first or second phase performed in the previous operation 360, and survivability was not successfully initiated (in Figure 3 ), process 300 may return to operation 330 and retry to establish a survivable tunnel. According to some embodiments, process 300 may perform operations 330-350 in an iterative manner (a certain number of times) and continue to attempt to initiate a survivable tunnel until successful. Alternatively, if it is determined in operation 360 that the survivable tunnel was successfully initiated (in Figure 3 ), process 300 moves to operation 370.

[0055] Thereafter, at operation 370, if the survivability tunnel is available, the IPsec peers may failover from the IPsec tunnel and communicate via the survivability tunnel. Thus, the survivability tunnel will be used to pass traffic between IPsec peers (e.g., initiators and responders). Process 300 allows IPsec networked devices to continue secure communications via the survivability tunnel even if the (e.g., cloud-based) IPsec tunnel is interrupted due to loss of connection to the cloud service. According to some embodiments, during the next key update, if the previously lost cloud connection has been reestablished, communications may switch back to the cloud-orchestrated IPsec tunnel. In some embodiments, if the cloud service sends any new key configurations during the survivability phase of process 300, the responder may respond and create a bootstrap tunnel along with the existing tunnel (e.g., survivability tunnel).

[0056] Figure 4 is a block diagram of an example computing component 400 or IPsec networking device, such as a branch gateway or VPNC, for implementing cloud survivability techniques according to one embodiment. Figure 3 4. In some implementations, computing component 400 may be an initiator of an IPsec peer, wherein computing component 400 is communicatively coupled to another IP network device via an IPsec tunnel. Computing component 400 may include hardware processor 402 and machine-readable storage medium 404. Hardware processor 402 may execute instructions 406 to perform cloud survivability functions, such as establishing a cloud survivability tunnel that may serve as a security guarantee for the IPsec tunnel. For example, machine-readable storage medium 404 may implement Figure 3 Thus, the hardware processor 402 of the computing component can be programmed to: determine whether it has lost connectivity with the cloud service through the communication network, or whether its IPsec peer has lost connectivity with the cloud service through the communication network; and in response to determining that there is a loss of connectivity, automatically establish a survivability tunnel.

[0057] Figure 5 A block diagram of an example computer system 500 is depicted in which the cloud survivability techniques described herein may be implemented. For example, the computer system 500 may be an IPsec networking device, such as an AP (e.g., Figure 1 as shown) or gateway (as Figure 2 5 ), as described in detail above. Computer system 500 includes a fabric 502 or other communication mechanism for communicating information, and one or more hardware processors 504 coupled to fabric 502 for processing information. Hardware processor(s) 504 may be, for example, one or more general purpose microprocessors.

[0058] The computer system 500 also includes a main memory 506, such as a random access memory (RAM), cache, and / or other dynamic storage device, coupled to the structure 502 for storing information and instructions to be executed by the processor 504. The main memory 506 may also be used for storing temporary variables or other intermediate information during execution of instructions by the processor 504. These instructions, when stored in a storage medium accessible to the processor 504, present the computer system 500 as a special-purpose machine that is customized to perform the operations specified in the instructions.

[0059] Computer system 500 also includes a storage device 510, such as a read-only memory (ROM) or other static storage device coupled to structure 502, for storing static information and instructions for processor 504. Storage device 510, such as a magnetic disk, optical disk, or USB thumb drive (flash drive), etc., is provided and coupled to structure 502 for storing information and instructions.

[0060] Computer system 500 may be coupled to a display 512, such as a liquid crystal display (LCD) (or touch screen), via structure 502 for displaying information to a computer user. An input device 514, including alphanumeric and other keys, is coupled to structure 502 for communicating information and command selections to processor 504. Another type of user input device is a cursor control 516, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512. In some embodiments, the same direction information and command selections as a cursor control may be achieved by receiving touches on a touch screen without a cursor.

[0061] The computing system 500 may include a user interface module that implements a GUI that may be stored in a mass storage device as executable software code executed by a computing device. For example, this module and other modules may include components, such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0062] In general, the terms "component", "engine", "system", "database", "data storage", etc. used herein may refer to logic implemented in hardware or firmware, or to a collection of software instructions that may have entry points and exit points, which are written in a programming language, such as Java, C, or C++. Software components can be compiled and linked into executable programs, installed in dynamic link libraries, or can be written in interpreted programming languages, such as BASIC, Perl, or Python. It should be understood that software components can be called from other components or from themselves, and / or can be called in response to detected events or interrupts. Software components configured to be executed on a computing device can be set on a computer-readable medium, such as a compact disc, a digital video disc, a flash drive, a disk, or any other tangible medium, or as a digital download (and can be initially stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such software code can be stored in part or in whole on a storage device of the executing computing device for execution by the computing device. Software instructions can be embedded in firmware, such as an EPROM. It will also be appreciated that hardware components may include connected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0063] Computer system 500 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, causes or programs computer system 500 to become a special purpose machine. According to one embodiment, the techniques herein are performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another storage medium (e.g., storage device 510). Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0064] As used herein, a circuit may be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms may be implemented to form a circuit. In implementation, the various circuits described herein may be implemented as discrete circuits, or the functions and features described may be partially or fully shared between one or more circuits. Even if the various features or elements of a function may be described or declared as separate circuits separately, these features and functions may be shared between one or more common circuits, and such descriptions should not require or imply that separate circuits are needed to implement such features or functions. In the case of using software to implement the circuit in whole or in part, such software may be implemented to operate with a computing or processing system (e.g., computer system 500) that is capable of performing the functions described therefor.

[0065] As used herein, the term "or" may be interpreted in an inclusive or exclusive sense. Furthermore, singular descriptions of resources, operations, or structures should not be construed as excluding the plural. Unless otherwise specifically stated, or otherwise understood in the context of use, conditional language such as "may," "can," "might," or "could" is generally intended to convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not.

[0066] Unless expressly stated otherwise, the terms and phrases used in this document and variations thereof should be interpreted as open ended, not restrictive. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the items described to a given time period or to items available at a given time, but should be understood to include conventional, traditional, normal, or standard technology available or known at any time now or in the future. In certain cases, the presence of expanding words and phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be understood to mean that a narrower context is intended or required where these expanding phrases may not be present.

Claims

1. A method for achieving cloud survivability, comprising: The initiator device establishes an encrypted tunnel between the initiator device and the responder device of the cloud service based on a set of parameters obtained from the cloud service; determining, by the initiator device, whether there is a loss of connectivity from the initiator device or the responder device to the cloud service, wherein the cloud service supports respective communication links to the responder device and the initiator device via a network associated with the cloud service; In response to determining that the connectivity is lost due to not receiving a response from the cloud service to a message sent from the initiator device or the responder device, establishing, by the initiator device, a survivable tunnel between the initiator device and the responder device that bypasses the network using the set of parameters for the encrypted tunnel, the message being used for a key update for the encrypted tunnel, the survivable tunnel allowing devices to remain connected even if a cloud connection fails; as well as In response to determining that the survivability tunnel is successfully established, the initiator device is communicatively coupled to the responder device via the survivability tunnel, the survivability tunnel serving as a security guarantee for the encryption tunnel.

2. The method of claim 1, wherein the encrypted tunnel is a cloud-based Internet Protocol Security (IPsec) tunnel established via the cloud service.

3. The method of claim 1, wherein the survivability tunnel is a conventional IPsec tunnel established using Internet Key Exchange (IKE) authentication.

4. The method according to claim 3, further comprising: A failure to establish a new cloud-based security association SA using a tunnel configuration provided by the cloud service before expiration of a current key associated with the encryption tunnel is identified.

5. The method according to claim 1, further comprising: determining that the connectivity to the cloud service is lost by identifying failed attempts to reestablish a connection between the initiator device and the cloud service or between the responder device and the cloud service; as well as The survivability tunnel between the initiator device and the responder device bypassing the network is established by the initiator device using the set of parameters of the encryption tunnel.

6. The method according to claim 1, wherein establishing the survivability tunnel further comprises: creating a conventional encrypted tunnel using the set of parameters bypassing the network; as well as The responder device is authenticated using certificate-based authentication.

7. The method according to claim 1, further comprising: Traffic is forwarded from the initiator device to the responder device via the survivability tunnel.

8. The method according to claim 1, further comprising: determining whether the connectivity to the cloud service is reestablished; as well as In response to determining that the connectivity to the cloud service is reestablished, switching from the survivability tunnel to the encryption tunnel for communications between the initiator device and the responder device.

9. The method according to claim 1, further comprising: In response to determining that the survivability tunnel is not successfully established, performing an additional attempt to establish the survivability tunnel.

10. A computer system comprising: processor; Memory devices; A non-transitory computer-readable storage medium storing instructions that, when executed by the processor, cause the processor to: operating as a first networked device associated with a cloud service; establishing an encrypted tunnel between the first networked device and a second networked device associated with the cloud service based on a set of parameters obtained from the cloud service; determining whether there is a loss of connectivity from the first networked device or the second networked device to the cloud service, wherein the cloud service supports respective communication links to the first networked device and the second networked device via a network associated with the cloud service; In response to determining that the connectivity loss exists due to not receiving a response from the cloud service to a message sent from the first networked device or the second networked device, establishing a survivable tunnel between the first networked device and the second networked device bypassing the network using the set of parameters, the message being for a key update of the encryption tunnel, the survivable tunnel allowing the devices to remain connected even if a cloud connection fails; as well as In response to determining that the survivable tunnel is successfully established, the first networked device is communicatively coupled to the second networked device via the survivable tunnel, the survivable tunnel serving as a security guarantee for the encryption tunnel.

11. The computer system of claim 10, wherein the set of parameters is received from a tunnel orchestration of the cloud service.

12. The computer system of claim 10, wherein the survivability tunnel comprises a conventional Internet Protocol Security (IPsec) tunnel established using Internet Key Exchange (IKE) authentication.

13. The computer system of claim 12, wherein establishing the survivability tunnel further comprises: creating a conventional encrypted tunnel bypassing the network using the set of parameters received from the cloud service; as well as The second networked device is authenticated using certificate-based authentication.

14. The computer system of claim 10, wherein the first networking device or the second networking device comprises at least one of the following: a gateway, a branch gateway, a virtual private network (VPN) concentrator, a switch, a firewall device, a server, and a workstation.

15. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, perform the following operations: establishing an encrypted tunnel between an initiator device and a responder device of a cloud service based on a set of parameters, the set of parameters being obtained from the cloud service; determining whether there is a loss of connectivity from an initiator device or a responder device to the cloud service, wherein the cloud service supports respective communication links to the responder device and the initiator device via a network associated with the cloud service; In response to determining that the connectivity is lost due to not receiving a response from the cloud service to a message sent from the initiator device or the responder device, establishing a survivable tunnel between the initiator device and the responder device bypassing the network using the set of parameters, the message being used for key updates of the encrypted tunnel, the survivable tunnel allowing devices to remain connected even if a cloud connection fails; and In response to determining that the survivability tunnel is successfully established, the initiator device is communicatively coupled with the responder device via the survivability tunnel, the survivability tunnel serving as a security guarantee for the encryption tunnel.

16. The non-transitory computer-readable storage medium of claim 15, wherein the operations further comprise: determining that the connectivity to the cloud service is lost by identifying failed attempts to reestablish a connection between the initiator device and the cloud service or between the responder device and the cloud service; as well as The survivability tunnel between the initiator device and the responder device bypassing the network is established by the initiator device using the set of parameters of the encryption tunnel.

17. The non-transitory computer-readable storage medium of claim 16, wherein the operations further comprise: A failure to establish a new cloud-based security association SA using a tunnel configuration provided by the cloud service before expiration of a current key associated with the encryption tunnel is identified.

18. The non-transitory computer-readable storage medium of claim 15, wherein the survivability tunnel comprises a conventional Internet Protocol Security (IPsec) tunnel established using Internet Key Exchange (IKE) authentication.

19. The non-transitory computer-readable storage medium of claim 15, wherein establishing the survivability tunnel further comprises: creating a conventional encrypted tunnel bypassing the network using the set of parameters received from the cloud service; as well as The responder device is authenticated using certificate-based authentication.

20. The non-transitory computer-readable storage medium of claim 15, wherein the operations further comprise: determining whether the connectivity to the cloud service is reestablished; as well as In response to determining that the connectivity to the cloud service is reestablished, switching from the survivability tunnel to the encryption tunnel for communications between the initiator device and the responder device.

Images