Optimal data plane security and connectivity for secure connections
By using policy servers and multipathing technology in a zero-trust network, optimizing the data path between client devices and resources, the ZTNA model's challenges in maintaining end-to-end encryption are solved, and better data transmission security is achieved. performance.
Patent Information
- Application Number
- CN202380039999.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-02-23
- Filing Date
- 2023-05-11
- Publication Date
- 2024-12-27
AI Technical Summary
Existing Zero Trust Network Access (ZTNA) models are difficult to maintain end-to-end encryption simultaneously when creating the optimal data plane connection, especially when faced with complex network conditions and security policies, which can lead to performance differences and insufficient security issues. .
By using policy servers in a cloud computing network to evaluate and optimize data paths between client devices and resources, determine whether an alternative connection meets security policies, and insert encryption agents if necessary or use multipathing technology to ensure end-to-end encryption , for example, dynamic adjustment of data paths is achieved through the STUN server and the MASQUE protocol.
It realizes the creation of better data paths in a zero-trust network environment, while maintaining end-to-end encryption, improving the security and performance of data transmission, and adapting to the needs of different network conditions and security policies.
Smart Images

Figure CN119213734A_ABST
Abstract
Description
[0001] Related Applications
[0002] This application claims priority to U.S. Patent Application No. 18 / 113,248, filed on February 23, 2023, which claims priority to U.S. Provisional Patent Application No. 63 / 341,557, filed on May 13, 2022, the entire contents of which are incorporated herein by reference in their entirety and for all purposes. Technical Field
[0003] The present disclosure relates generally to techniques, among other things, for creating optimal data plane connections based on network constraints while maintaining end-to-end encryption for sessions. Background Art
[0004] The Zero Trust Network Access (ZTNA) model uses a trust broker inside the enterprise perimeter to mediate connections between specific private applications and authorized users. This allows teams to start with zero trust, but then provide connectivity based on context (identity, device, etc.). Unlike a virtual private network (VPN), ZTNA technology provides access to applications without wider network access, as well as the ability to shield applications from the open Internet. BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The following detailed description is given with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. The use of the same reference number in different drawings indicates similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale with each other.
[0006] Figure 1 An example architecture is shown in which aspects of the techniques described herein may be implemented.
[0007] FIG. 2A to FIG. 2C Shown are example architectures and implementation steps associated with various aspects of the techniques described herein.
[0008] Figure 3 Yet another example architecture and implementation steps associated with the techniques described herein are shown.
[0009] Figure 4 is a flow chart illustrating an example method associated with the techniques described herein for creating an optimal data plane connection based on network constraints while maintaining end-to-end encryption for the session.
[0010] Figure 5A and Figure 5Bare flow diagrams that collectively illustrate another example method associated with the techniques described herein for creating an optimal data plane connection based on network constraints while maintaining end-to-end encryption for a session.
[0011] Figure 6 is a computer architecture diagram showing an illustrative computer hardware architecture for implementing a computing device that can be used to implement various aspects of the various techniques presented herein. DETAILED DESCRIPTION
[0012] Overview
[0013] Various aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applicable to each aspect alone or in combination with other aspects.
[0014] The present disclosure describes various techniques for creating an optimal and secure data plane based on network constraints. As an example and not limitation, the techniques described herein may include establishing an initial networking connection for a data flow between a client device and a resource so that data plane traffic of the data flow is routed through a relay node disposed between the client device and the resource. In some examples, the techniques may include using a Session Traversal Utilities for Network Address Translators (STUN) server to determine an alternative networking connection for the data flow that bypasses the relay node. The techniques may include routing the data plane traffic of the data flow through an alternative networking connection based at least in part on determining that the alternative networking connection is a better path for the data plane traffic than the initial networking connection.
[0015] Additionally, the techniques described herein may be performed as a method and / or performed by a system having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the techniques described above and herein.
[0016] Example Embodiments
[0017] The present application relates to techniques for zero trust session creation by using the cloud as a zero trust network access (ZTNA) control plane and stitching the data planes together using multipath technology. Multipath technology allows the best data path to be determined while also maintaining end-to-end encryption between devices and resources (e.g., applications). For example, the quality of existing TCP or UDP-based encryption protocols can be evaluated by a policy server, and if the protocol meets the security policy, a direct path can be established between the device and the resource. In this way, secure transport protocols (e.g., (D)TLS1.3, QUIC (HTTPs / 3), NAT-T IPsec, Wireguard (Noise Protocol), etc.) can be carried out end-to-end between devices and resources without the need for intermediate agents. In other cases, such as when encryption is insufficient or non-existent, proxy capabilities on both ends can be used to provide this functionality while still maintaining a high degree of end-to-end encryption from the device to close to the resources deep inside the enterprise network.
[0018] In some examples, a policy server disposed in a cloud computing network may be utilized to perform various aspects of the technology disclosed herein. For example, a connection may be initially established between a client device and a resource, and the policy server may determine whether the initial connection may be optimized. For example, the initial connection may be a ZTNA connection that passes through a forwarding server (e.g., a relay server) to ensure the success of the connection, but a better and equally secure connection may be obtained. Thus, in some examples, the policy server may determine the internal capabilities of the resource (e.g., which ports and protocols are used for connection to the resource) and map the domain name system (DNS) information associated with the resource. In addition, the policy server may authenticate the permissions of the user of the client device and / or whether the network policy allows the user / client device to connect to the resource in a manner other than through a forwarding server / relay. For example, for alternative connections, the policy may require inline DLP or other security features. In addition, in some examples, the policy server may test the internal connectivity of the resource to determine whether an alternative connection (e.g., a direct connection) will provide sufficient security (e.g., whether there is strong transport encryption inherent to the resource).
[0019] In some examples, if the policy server determines that a sufficiently secure alternative connection may exist, the policy server may attempt an end-to-end session between the client device and the resource. For example, the policy server may initially establish a UDP or TCP (e.g., which may optionally be encapsulated) session at an edge or cloud rendezvous point (meet-me-here) protocol to start the session, and then the client device and the resource may begin transmitting UDP or TCP packets, while at the same time, the policy server attempts to upgrade the session with a more optimal (e.g., direct) data path using STUN (Session Traversal Utilities for Network Address Translation), ICE (Interactive Connectivity Creation), or a similar protocol, thereby essentially dynamically adapting the session to the optimal path.
[0020] In some examples, the policy server can measure or otherwise determine which path (e.g., the initial connection or the alternate connection) is the best path, giving preference to the alternate path unless there is a significant performance difference. In some examples, the policy server can discard the poorly performing path based on network conditions and route all future UDP or TCP data over the preferred path. In some cases, the policy server can remember the results of future sessions associated with a given device and that resource on a network (e.g., the same SSID) and store the results encrypted on the client device, e.g., using a server-side key, for recovery.
[0021] In some examples, when alternative connections do not meet security requirements or policies, gateway / proxy functionality can be automatically inserted in front of the resource to provide adequate transport encryption and / or any other security functionality required by the policy. Additionally, in some examples, an L3 / L4 enforcement node can be placed between the device and the resource based on policy, and the enforcement node can have the ability to add or remove any encapsulation protocols that can be used between the client device and the resource. In some cases, the encapsulation layer can be used to carry additional metadata / identities without interfering with encrypted sessions. For example, GUE or Geneve encapsulation can be added / removed by client devices (e.g., zero trust clients / applications running on client devices) and network enforcement nodes.
[0022] In some examples, a zero-trust client / application on a client device may perform network address translation (NAT) / port address translation (PAT) functions to match an intended application flow with a negotiated session, which may be on a different IP or port than the connection attempted by some software application running on the device. For example, a browser may attempt to connect to a resource (www.foo.bar) on (IP:port) 2.3.4.5:443, but the session may have been negotiated through a NAT and firewall on (IP:port) 5.6.7.8:777. In this scenario, the zero-trust nodes on both sides (client device side and resource side) can perform the appropriate NAT / PAT functions to match the intent without affecting the end-to-end encryption of the protocol itself.
[0023] Under certain network conditions, using the techniques described herein, an alternative path determined by STUN may only be available in one direction (e.g., from the resource toward the client device, but not from the client device toward the resource). In this case, if the one-way path is significantly better than the relay path, an asymmetric route may be established where the most favorable path in each direction is selected. This may result in a hybrid scenario where packets in one direction go through a relay / forwarding server, while packets in the other direction go through an alternative path (e.g., a direct path, a proxy and relay path, etc.). The solution may optionally remember this configuration for future sessions to the same client device and the same resource on the network (e.g., the same SSID).
[0024] In some examples, protocol encapsulation can be used for different situations. For example, encapsulation can be used to carry metadata of users, application identities, or other use cases in an external packet to share with implementation nodes on the path. As another example, encapsulation can be used for protocol conversion (e.g., encapsulating TCP in UDP for performance reasons or encapsulating UDP in TCP for passing through an enterprise HTTP proxy). In some examples, encapsulation can also be used to include verifiable credentials in a packet. In examples, GRE, GUE, Geneve, or any other Internet resilient encapsulation protocol can be used for these purposes.
[0025] The MASQUE (Multiplexed Application Substrate over QUIC Encryption) protocol allows any other protocol to be proxied over a QUIC (Quick UDP Internet Connection) connection. It may be desirable to use it for multiplexing remote ZTNA sessions to improve the performance characteristics of less resilient protocols, or to improve the performance characteristics of IP protocols other than UDP or TCP that are desired to be "tunneled" to enterprise applications or resources. In some examples, MASQUE termination can be done at the edge of the network (e.g., cloud or on-premises) via an edge firewall, edge proxy, or at a zero-trust (ZT) proxy node within the network. For some of these purposes, the encapsulation can be MASQUE or another proxy encapsulation protocol, or even VPN encapsulation.
[0026] In an example, when the MASQUE agent is configured at a zero-trust proxy, the same techniques described above can be used to find the optimal path (proxy or direct). Conversely, when the MASQUE agent is at the edge of the network (e.g., cloud or local), a TCP-SYN or UDP-PROBE sequence can be performed between the MASQUE edge agent and the internal resource or zero-trust agent node to discover any internal NAT or firewall between components. In some examples, a client device can connect directly to the MASQUE agent, and the MASQUE agent can apply NAT / PAT to the internal (decapsulated) protocol to reach the resource or ZT agent node while maintaining end-to-end encryption of the internal (decapsulated) protocol.
[0027] In the example where the MASQUE node is collocated with the ZT proxy component, the operation can be the same as the example previously described using STUN technology. However, when the MASQUE node is at the edge, the device can make a direct data plane connection with the MASQUE node. In this case, the ZT proxy near the application can perform in-out rendezvous at the MASQUE proxy relay based on an encrypted protocol via UDP or TCP. Lower-level protocols (UDP or TCP) can be spliced together so that the encrypted protocol can not be broken end-to-end. For example, Linux sockmaps can be one of the ways to implement low-level (UDP or TCP) relay functionality.
[0028] In this configuration, there are multiple possible approaches. As an example, on-demand aggregation can be used, where the MASQUE agent notifies the system that it has an inbound connection from a device for a given application. The appropriate ZT agent node can be contacted, and the ZT agent node initiates an outbound UDP or TCP aggregation session with the MASQUE relay component to complete the low-level (UDP or TCP) protocol bridge. When a relay can be established, packets flow between the MASQUE node and the ZT agent, or between the MASQUE node and the ZT L3 / L4 enforcer when an agent may not be needed. As another example, an idle "connection" pool can be established from a ZT agent / enforcer node to a MASQUE agent node. Ensure that at least one idle relay session is available between the nodes. When all idle relay sessions are used, a new idle session can be established from the ZT agent / enforcer to the MASQUE relay to serve future end-to-end encrypted traffic. A policy component may be used to determine the number of idle sessions to maintain between nodes, since each MASQUE node may have multiple ZT agent / enforcement nodes with which it must maintain idle sessions, and vice versa.
[0029] In some examples, temporary certificates may be generated for applications that do not support encryption or have insufficient encryption. In this case, the root certificate may be deployed out-of-band or by the ZT application itself during provisioning or at runtime via a policy engine. From this point forward, temporary certificates may be auto-generated and enabled at the ZT proxy node as needed for a given application. This may allow end-to-end encryption between an endpoint device application (e.g., a browser) and the ZT proxy.
[0030] In an example, SAML (Security Assertion Markup Language), OAuth or other authentication proxy (Auth Proxy) technologies can be used in conjunction with the system to apply flow-based policies. For example, when a user has successfully authenticated via the Auth Proxy, the flow-level component can connect the session. For example, after authentication, a UDP / TCP relay can begin passing session data associated with the application. Similarly, when a ZT actuator or proxy is approved by the Auth Proxy component, traffic can be allowed to flow.
[0031] As described herein, in some cases, there may be two categories of flows: unauthenticated and authenticated. In an example, an application may consist of one or more flow categories in each flow category. The solution described herein may allow policies to be configured to indicate any resources that must be reachable before authentication and resources that are reachable after authentication. The implementation node may allow pre-authenticated flows to pass based on the policy configuration of the application, while blocking flows that require authentication to be completed before allowing them. The Kerberos protocol is a good example of a flow that may be allowed to be pre-authenticated because the protocol itself is used to establish an authentication channel. In some examples, the Auth agent may also be used as an authentication relay to limit the exposure of authentication mechanisms on any path based on policy. In this configuration, network flows may not begin until the Auth agent completes the authentication ceremony.
[0032] By way of example and not limitation, a method according to the techniques described herein may include establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic of the data flow is routed through a relay node disposed between the client device and the resource. In some examples, the initial networking connection may be a zero trust network access (ZTNA) networking connection. In some examples, the relay node may be associated with a forwarding server. In some examples, data plane traffic may flow between the client device and the resource via the initial networking connection. In some examples, the resource may be an enterprise resource (e.g., a dedicated resource) being accessed by the client device.
[0033] In some examples, the method may include using a Session Traversal Utilities for Network Address Translators (STUN) server to determine an alternative networking connection for a data flow that bypasses a relay node. In some examples, the alternative networking connection may be at least one of the following connections: a direct networking connection between a client device and a resource, a proxy networking connection, a proxy and relay networking connection that passes through different relay nodes, and the like. In some examples, while data plane traffic of the data flow is sent between the client device and the resource via an initial networking connection, the STUN server may be used to determine the alternative networking connection. In some examples, using the STUN server to determine the alternative networking connection may include determining an Internet Protocol (IP) address and port associated with a pin-holed flow by one or more networking components or security components disposed between the client device and the resource.
[0034] In some examples, before determining the alternative networking connection, the method may also include: determining whether the security policy allows the alternative networking connection between the client device and the resource. Thus, using the STUN server to determine the alternative networking connection can be based at least in part on determining that the security policy allows the alternative networking connection. Additionally or alternatively, before determining the alternative networking connection, the method may also include: determining whether the encryption protocol associated with the resource satisfies the security policy. Thus, using the STUN server to determine the alternative networking connection can be based at least in part on determining that the encryption protocol satisfies the security policy.
[0035] In some examples, the method may include determining whether the alternate networking connection is a more optimal path for data plane traffic than the initial networking connection. For example, based at least in part on determining that the alternate networking connection is a more optimal path for data plane traffic than the initial networking connection, the method may include causing data plane traffic for the data flow to be routed through the alternate networking connection. Alternatively, the method may include avoiding routing data plane traffic for the data flow through the alternate networking connection based at least in part on determining that the alternate networking connection is a less optimal path than the initial networking connection.
[0036] In an example, determining whether an alternate networking connection is a better path for data plane traffic than the initial networking connection can include determining whether routing the data plane traffic through the alternate networking connection rather than the initial networking connection will result in at least one of: increasing the amount of bandwidth available for the data flow; reducing the cost associated with the data flow; reducing the latency associated with the data flow; reducing the amount of computation associated with sending data plane traffic; or achieving a more even distribution of resources or resource utilization (e.g., better load balancing).
[0037] In some examples, the method may also include causing the client device to store an indication that the alternate networking connection is a more optimal path for future connections to the resource. In some examples, it may be determined that the alternate networking connection between the client device and the resource fails to satisfy security policy requirements, and the method may include causing the data plane traffic to flow through a security function associated with the resource when routing the data plane traffic through the alternate networking connection.
[0038] In some examples, the alternate networking connection is a more optimal path for data plane traffic being sent from the resource to the client device, while the initial networking connection is a more optimal path for data plane traffic being sent from the client device to the resource. In such a situation, the method may include: routing data plane traffic being sent from the resource to the client device through the alternate networking connection; and routing data plane traffic being sent from the client device to the resource through the initial networking connection.
[0039] Certain implementations and embodiments of the present disclosure will now be described more fully below with reference to the accompanying drawings, in which various aspects are shown. However, various aspects can be implemented in many different forms and should not be construed as being limited to the implementations set forth herein. The present disclosure encompasses variations of the embodiments described herein. The same numbers always represent the same elements.
[0040] Figure 1 An example architecture 100 is shown in which aspects of the techniques described herein may be implemented. The architecture 100 includes a device 102, a resource 104 being accessed by the device 102, and a cloud computing network 106, which may serve as a control plane for communication sessions between the device 102 and the resource 104.
[0041] Device 102 may be any computing device capable of network communications, such as a desktop computer, a laptop computer, a cellular phone, a tablet computer, etc. In some examples, device 102 may run a client (e.g., a ZTNA client, a VPN client, etc.) for secure communications between device 102 and resource 104. In an example, resource 104 may be a dedicated enterprise resource, an application, etc.
[0042] To connect with resource 104, at "1", device 102 may perform operation 108, in which device 102 is authenticated and / or authorized for access to resource 104. In some examples, policy engine 110 and authentication agent 112 of cloud computing network 106 may authenticate and / or authorize device 102 for access to resource 104. At "2", policy engine 110 may perform action 114, which is to determine resource connection information. For example, policy engine 110 may obtain resource connection information from DNS / application metadata server 116. In some examples, resource connection information may include an IP address, port, protocol, etc. associated with resource 104.
[0043] After authenticating and / or authorizing device 102 to connect to the resource, cloud computing network 106 can provide resource connection information to device 102. Thus, at "3", an initial connection 118 (e.g., an initial networking connection) can be established between device 102 and resource 104. For example, initial connection 118 can pass through relay server 120 and proxy 122 disposed between device 102 and resource 104.
[0044] As data plane traffic flows along the initial connection 118, at "4", a STUN server 124 may be used to determine whether an alternative connection 126 is possible (e.g., a direct connection that bypasses the relay server 210). In some examples, this may include: the STUN server 124 is used to perform a bidirectional STUN discovery and transmit the discovery information to the peer. For example, the STUN server 124 may send N simultaneous bidirectional TCPSYN and / or UDP probe packets toward a relative target (e.g., from the device 102 toward the resource 104, or vice versa). In some examples, a Zero-Trust Bootstrap may spoof, generate an in line map, or create packets for TCP-SYN or UDP probes. If the packet arrives on the other side, the STUN server 124 may determine the IP address and port associated with the pinhole flow through any firewall, NAT, or other networking or security component between the device 102 and the resource 104.
[0045] If the alternative connection 126 is better than the initial connection 118, the device 102 can perform a NAT / PAT function to map the original destination to the alternative connection 126. In some examples, the poorer performing path (e.g., the initial connection 118 or the alternative connection 126) can be dropped in favor of the better path. Additionally or alternatively, both paths / connections can remain open for network resiliency.
[0046] FIG. 2A to FIG. 2C An example architecture 200 and implementation steps associated with various aspects of the technology described herein are shown. The architecture 200 includes a device 102 and a resource 104. In some examples, a dynamic communication channel 202 (e.g., a dynamic connection, a long-lived bus connection, etc.) is established between the device 102 and the DNS and / or application metadata server 116 for a control plane flow 204 associated with a data flow between the device 102 and the resource 104. In an example, the dynamic communication channel 202 can connect a client 206 running on the device 102 with the policy engine 110, and connect the policy engine 110 with the DNS and / or application metadata server 116.
[0047] In some examples, at "1", the device 102 can be authenticated and / or authorized to connect with the resource 104. In some examples, the policy engine 110 and / or the authentication agent 112 can authenticate and / or authorize the user of the device 102 for access to the resource 104. In addition, in some examples, the policy engine 110 can determine the resource 104 connection information. For example, the policy engine 110 can obtain the resource connection information from the DNS / application metadata server 116. In some examples, the resource connection information may include an IP address, port, protocol, etc. associated with the resource 104. In some examples, the DNS / application metadata server 116 can verify that the resource 104 is on the correct port, IP address, and / or protocol provided to the policy engine 110. After authenticating and / or authorizing the device 102 to connect to the resource 104, the cloud computing network 106 can provide the resource connection information to the client 206 of the device 102.
[0048] At "2", an initial connection 118 (eg, an initial networking connection) is established between the device 102 and the resource 104 for the data plane flow 208. For example, the initial connection 118 passes through a relay node 210 and a proxy 122 disposed between the device 102 and the resource 104.
[0049] As data plane traffic flows along the initial connection 118, at "3", the STUN server 124 performs bidirectional STUN discovery 212 and transmits the discovery information to the peer. For example, the STUN server 124 may send N simultaneous bidirectional TCP SYN and / or UDP probe packets toward the relative target (e.g., from the device 102 toward the resource 104, or vice versa). In some examples, the bootstrap 214 (e.g., the ZT bootstrap) may spoof, generate an online map, or create packets for TCP-SYN or UDP probes. At "4", if a successful probe 228 arrives at the other side, the STUN server 124 may determine the IP address and port associated with the pinhole flow through a firewall 216, a NAT gateway 218, or any other networking or security component between the device 102 and the resource 104. In some examples, a firewall 216 is set on an enterprise edge 220 between the Internet 222 and the DMZ 224, and another firewall 216 is set between the DMZ 224 and the NAT gateway 218, both of which are before the data center 226.
[0050] Figure 2B and Figure 2CDifferent forms that the alternative connection 126 can take are shown. If the alternative connection 126 is better than the initial connection 118, the device 102 can perform a NAT / PAT function to map the original destination to the alternative connection 126. In some examples, the poorer performing path (e.g., the initial connection 118 or the alternative connection 126) can be dropped in favor of the better path. Additionally or alternatively, both paths / connections can remain open for network resiliency.
[0051] exist Figure 2B In , the policy allows an alternative connection 126 to be made directly between the device 102 and the resource 104, such that the alternative connection pinholes through the firewall 216 and the NAT gateway 218 without additional encryption. For example, the resource 104 encryption may be strong enough that no additional security features are needed. Figure 2C In contrast, the alternative connection 126 needs to go through the proxy 122 in front of the resource 104. In the example, additional security functions can also be added based on policies.
[0052] Figure 3 Yet another example architecture 300 and implementation steps associated with the techniques described herein are shown. In the architecture 300, a proxy / tunnel headend 302 is located at the enterprise edge 220, and a UDP / TCP relay 304 is located between the proxy / tunnel headend 302 and the firewall 216. In some examples, the proxy / tunnel headend 302 may be a MASQUE proxy, an inbound and outbound site-to-site VPN tunnel headend, an edge proxy, etc.
[0053] At "1", proxy / tunnel traffic 308 flows between device 102 and proxy / tunnel headend 302. At "2", proxy / tunnel headend 302 and / or policy engine 110 may establish a connection between device 102 and resource 104. For example, device 102 may be authenticated and / or authorized to connect, and policy engine 110 may exchange connection / target information with device 102.
[0054] At "3", the policy engine 110 and / or the DNS / application metadata server 116 may use the dynamic communication channel 202 to exchange connection information, application information, DNS information, etc. associated with the resource 104. At "4", the policy engine 110 and the agent or enforcer 306 may authorize / allow the inbound and outbound sessions to be opened between the resource 104 and the device 102.
[0055] At "5", end-to-end encrypted traffic 308 (e.g., data plane traffic) can flow between the device 102 and the resource 104. For example, the end-to-end encrypted traffic can flow from the device 102 through the proxy / tunnel headend 302, through the UDP / TCP relay 304, and then through the firewall 216 and the NAT gateway 218 to the proxy or enforcer 306 before reaching the resource 104. In some examples, the end-to-end encrypted traffic 308 can be MASQUE encapsulated traffic, site-to-site VPN traffic, etc.
[0056] Figure 4 , Figure 5A and Figure 5B is a flowchart illustrating example methods 400 and 500 associated with the techniques described herein. Figure 4 , Figure 5A and Figure 5B The logical operations described may be implemented (1) as a sequence of computer-implemented acts or program modules running on a computing system, and / or (2) as interconnected machine logic circuits or circuit modules within the computing system.
[0057] The implementation of the various components described herein is a matter of choice, depending on the performance and other requirements of the computing system. Therefore, the logical operations described herein are variously referred to as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more than one operation can be performed. Figure 4 , Figure 5A and Figure 5B The operations shown and described herein may be performed in more or less order. These operations may also be performed in parallel, or in an order different from the order described herein. Some or all of these operations may also be performed by components different from those specifically identified. Although the techniques described in this disclosure are with reference to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or any configuration of components.
[0058] Figure 4 4 is a flow chart illustrating an example method 400 associated with the techniques described herein for creating an optimal data plane connection based on network constraints while maintaining end-to-end encryption for a session. The method 400 begins at operation 402, which includes establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic for the data flow is routed through a relay node disposed between the client device and the resource. For example, the policy engine 110 can establish the initial networking connection. In some examples, the initial networking connection is a secure networking connection.
[0059] At operation 404, method 400 includes using a Session Traversal Utilities for Network Address Translators (STUN) server to determine an alternative networking connection for the data flow that bypasses the relay node. For example, policy engine 110 may use STUN server 124 to determine an alternative networking connection for the data flow. In some examples, the alternative networking connection may be a direct connection, or may traverse different relay nodes.
[0060] At operation 406, method 400 includes determining whether the alternate networking connection is a more optimal path for data plane traffic than the initial networking connection. For example, policy engine 110 may determine whether routing data plane traffic through the alternate networking connection instead of the initial networking connection would result in at least one of: increasing the amount of bandwidth available for the data flow; reducing the cost associated with the data flow; reducing the latency associated with the data flow; reducing the amount of computation associated with sending data plane traffic; achieving a more even distribution of resources or resource utilization, etc. At operation 408, if the alternate networking connection is more optimal, method 400 proceeds to operation 410. However, if the alternate networking connection is inferior to the initial connection, method 400 proceeds to operation 412.
[0061] At operation 410, method 400 includes routing data plane traffic of the data flow through an alternate networking connection. For example, policy engine 110 may route data plane traffic of the data flow through an alternate networking connection.
[0062] At operation 412, method 400 includes refraining from routing data plane traffic through the alternate networking connection.For example, policy engine 110 may refrain from routing data plane traffic through the alternate networking connection.
[0063] Figure 5A and Figure 5B is a flow chart that collectively illustrates another example method associated with the techniques described herein for creating an optimal data plane connection based on network constraints while maintaining end-to-end encryption for a session. Method 500 begins at operation 502, which includes authenticating and authorizing a user of a device to access applications / resources.
[0064] At operation 504, method 500 includes determining DNS information for the application / resource and returning the address of the aggregate IP to the device. At operation 506, method 500 includes testing the internal connectivity of the application to verify the adequacy of the IP, port, and encryption protocol.
[0065] At operation 508, method 500 includes establishing a UDP or TCP bidirectional converged session between the device and the application / resource via the TCP / UDP relay node. At operation 510, method 500 includes starting data flow between the device and the application / resource via the TCP / UDP relay, allowing end-to-end encryption to occur.
[0066] At operation 512, method 500 includes: when sending data plane traffic on the converged path, performing bidirectional STUN discovery and transmitting discovery information to the peer. At operation 514, method 500 includes: when sending data plane traffic on the converged path, sending N simultaneous bidirectional TCPSYN or UDP probes toward the relative destination (e.g., from device 102 toward resource 104, or vice versa).
[0067] Steering Figure 5B At operation 516, the method 500 includes: if the packet arrives at the other side, determining the IP address and port associated with the pinhole flow through the firewall and / or NAT. At operation 518, the method 500 includes: performing NAT / PAT functions on the device to map the original destination to the direct path flow.
[0068] At operation 520, method 500 includes measuring packet performance on the newly created direct path and comparing it to the relay path. At operation 522, method 500 includes selecting an optimal path based on network conditions. At operation 524, method 500 includes at least one of discarding the lower performing path, supporting the direct path if the direct path is not significantly lower performing, or retaining both paths for network resiliency.
[0069] At operation 526, method 500 includes rerouting the protocol on the preferred path. Additionally, at operation 528, method 500 includes securely storing the results on the device for recovery using a cryptographic key from the policy server.
[0070] Figure 6 is a computer architecture diagram showing an illustrative computer hardware architecture for implementing a computing device that can be used to implement various aspects of the various techniques presented herein. Figure 6 The computer architecture shown illustrates a conventional server computer, network node (e.g., a secure access node), router, workstation, desktop computer, laptop computer, tablet computer, network appliance, e-reader, smart phone, load balancer, or other computing device and can be used to execute any software components presented herein.
[0071] The computer 600 includes a baseboard (or "motherboard") 602, which is a printed circuit board to which a number of components or devices may be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") 604 operate in conjunction with a chipset 606. The CPU 604 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of the computer 600.
[0072] The CPU 604 performs operations by transitioning from one discrete physical state to the next, where the state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide output states based on logical combinations of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders and subtractors, arithmetic logic units, floating point units, etc.
[0073] Chipset 606 provides an interface between CPU 604 and the remaining components and devices on baseboard 602. Chipset 606 may provide an interface with RAM 608, which is used as main memory in computer 600. Chipset 606 may also provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 610 or non-volatile RAM (NVRAM), which is used to store basic routines that help start computer 600 and transfer information between various components and devices. ROM 610 or NVRAM may also store other software components necessary for the operation of computer 600 according to the configuration described herein.
[0074] The computer 600 can operate in a networked environment using logical connections to remote computing devices and computer systems through a network. Chipset 606 may include functionality for providing network connectivity through NIC 612 (e.g., a Gigabit Ethernet adapter). NIC 612 is capable of connecting the computer 600 to other computing devices through network 624. It should be understood that multiple NICs 612 may be present in the computer 600, connecting the computer to other types of networks and remote computer systems. In some examples, NIC 612 may be configured to perform at least some of the techniques described herein.
[0075] The computer 600 can be connected to a storage device 618 that provides non-volatile storage for the computer. The storage device 618 can store an operating system 620, programs 622, and data, which have been described in more detail herein. The storage device 618 can be connected to the computer 600 via a storage controller 614 connected to the chipset 606. The storage device 618 can be composed of one or more physical storage units. The storage controller 614 can interface with the physical storage unit via a serial attached SCSI (serial attached SCSI, "SAS") interface, a serial advanced technology attachment (serial advanced technology attachment, "SATA") interface, a fiber channel (fiber channel, "FC") interface, or other types of interfaces for physically connecting and transmitting data between the computer and the physical storage unit.
[0076] The computer 600 can store data on the storage device 618 by transforming the physical state of the physical storage unit to reflect the information being stored. In different embodiments of the present specification, the specific transformation of the physical state may depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage unit, whether the storage device 618 is characterized as primary storage or secondary storage, etc.
[0077] For example, the computer 600 may store information to the storage device 618 by issuing instructions through the storage controller 614 to change the magnetic properties of a specific location within a disk drive unit, the reflective or refractive properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical media are possible without departing from the scope and spirit of the present specification, and the foregoing examples are provided only for the convenience of the present specification. The computer 600 may further read information from the storage device 618 by detecting the physical state or properties of one or more specific locations within the physical storage unit.
[0078] In addition to the mass storage device 618 described above, the computer 600 may also access other computer-readable storage media to store and retrieve information (e.g., program modules, data structures, or other data). It should be understood by those skilled in the art that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by the computer 600. In some examples, the operations performed by the architecture 100 and / or any components included therein may be supported by one or more devices similar to the computer 600. In other words, some or all of the operations performed by the architecture 100 and / or any components included therein may be performed by one or more computing devices 600 operating in a scalable arrangement.
[0079] By way of example, and not limitation, computer-readable storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY or other optical storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.
[0080] As briefly mentioned above, the storage device 618 may store an operating system 620 that is used to control the operation of the computer 600. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises an LINUX operating system from MICROSOFT Corporation of Redmond, Washington. SERVER operating system. According to another embodiment, the operating system may include a UNIX operating system or one of its variants. It should be understood that other operating systems may also be used. Storage device 618 may store other systems or applications and data utilized by computer 600.
[0081] In one embodiment, the storage device 618 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into the computer 600, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform the computer 600 by specifying how the CPU 604 transitions between states. According to one embodiment, the computer 600 is able to access a computer-readable storage medium storing computer-executable instructions that, when executed by the computer 600, perform the operations described above with reference to Figures 1 to 5B As well as the various processes described herein. The computer 600 may also include a computer-readable storage medium having stored thereon instructions for performing any other computer-implemented operations described herein.
[0082] The computer 600 may also include one or more input / output controllers 616 for receiving and processing input from a number of input devices (e.g., a keyboard, a mouse, a touch pad, a touch screen, an electronic stylus, or other types of input devices). Similarly, the input / output controller 616 may provide output to a display (e.g., a computer monitor, a flat panel display, a digital projector, a printer, or other types of output devices). It will be appreciated that the computer 600 may not include Figure 6 All components shown in the Figure 6 Other components not explicitly shown may be used in conjunction with Figure 6 A completely different architecture is shown in .
[0083] The computer 600 may include one or more hardware processors (processors) configured to execute one or more stored instructions. The processor(s) may include one or more cores. In addition, the computer 600 may include one or more network interfaces configured to provide communication between the computer 600 and other devices. The network interface may include a device configured to couple to a personal area network (PAN), a wired and wireless local area network (LAN), a wired and wireless wide area network (WAN), etc. For example, the network interface may include a device compatible with Ethernet, Wi-Fi™, etc.
[0084] Program 622 may include any type of program or process to perform the techniques described in this disclosure for creating an optimal data plane connection based on network constraints while maintaining end-to-end encryption for the session.
[0085] In general, techniques for creating an optimal and secure data plane based on network constraints are described. The techniques may include establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic for the data flow is routed through a relay node disposed between the client device and the resource. In some examples, the techniques may include using a Session Traversal Utilities for Network Address Translators (STUN) server to determine an alternative networking connection for the data flow that bypasses the relay node. The techniques may include routing data plane traffic for the data flow through an alternative networking connection based at least in part on determining that the alternative networking connection is a more optimal path for the data plane traffic than the initial networking connection.
[0086] Although the present invention has been described with reference to specific embodiments, it should be understood that the scope of the present invention is not limited to these specific embodiments. Because other modifications and changes that change to adapt to specific operating requirements and environments are obvious to those skilled in the art, the present invention is not considered to be limited to the examples selected for the purpose of disclosure, but includes all changes and modifications that do not constitute a deviation from the true spirit and scope of the present invention.
[0087] Although the present application describes embodiments with specific structural features and / or method actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Instead, the specific features and actions are merely illustrative of some embodiments falling within the scope of the claims of the present application.
Claims
1. A method comprising: establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic of the data flow is routed through a relay node disposed between the client device and the resource; determining, using a Session Traversal Utilities for Network Address Translators (STUN) server, an alternative networking connection for the data flow that bypasses the relay node; as well as The data plane traffic of the data flow is caused to be routed through the alternate networking connection based at least in part on determining that the alternate networking connection is a more optimal path for the data plane traffic than the initial networking connection.
2. The method according to claim 1, wherein: The initial networking connection is a zero trust network access (ZTNA) networking connection, and the alternative networking connection is at least one of the following connections: a direct networking connection, a proxy networking connection, or a proxy and relay networking connection passing through different relay nodes.
3. The method according to claim 1 or 2, wherein: The alternate networking connection is determined using the STUN server while the data plane traffic of the data flow is sent between the client device and the resource via the initial networking connection.
4. The method according to any one of claims 1 to 3, wherein: Determining the alternative networking connection using the STUN server includes determining an Internet Protocol (IP) address and port associated with a pinhole flow through one or more networking components or security components disposed between the client device and the resource.
5. The method according to any one of claims 1 to 4, further comprising: and determining whether a security policy allows the alternative networking connection to be made between the client device and the resource, and wherein determining the alternative networking connection using the STUN server is based at least in part on determining that the security policy allows the alternative networking connection to be made.
6. The method according to any one of claims 1 to 5, further comprising: The client device is caused to store an indication that the alternate networking connection is a more optimal path for future connections to the resource.
7. The method according to any one of claims 1 to 6, further comprising: A determination is made as to whether an encryption protocol associated with the resource satisfies a security policy, and wherein determining the alternative networking connection using the STUN server is based at least in part on determining that the encryption protocol satisfies the security policy.
8. The method according to any one of claims 1 to 7, further comprising: determining that the alternative networking connection between the client device and the resource fails to satisfy security policy requirements; as well as When routing the data plane traffic through the alternative networking connection, the data plane traffic is caused to flow through security functions associated with the resource.
9. The method according to any one of claims 1 to 8, further comprising: Routing the data plane traffic of the data flow through the alternate networking connection is avoided based at least in part on determining that the alternate networking connection is a less optimal path than the initial networking connection.
10. The method according to any one of claims 1 to 9, wherein: The alternate networking connection is a more optimal path for data plane traffic being sent from the resource to the client device, and the initial networking connection is a more optimal path for data plane traffic being sent from the client device to the resource, the method further comprising: routing data plane traffic being sent from the resource to the client device through the alternate networking connection; and Data plane traffic being sent from the client device to the resource is routed through the initial networking connection.
11. The method according to any one of claims 1 to 10, wherein: Determining whether the alternate networking connection is a more optimal path for the data plane traffic than the initial networking connection includes determining whether routing the data plane traffic through the alternate networking connection instead of the initial networking connection would result in at least one of the following: increasing the amount of bandwidth available for the data stream; reducing costs associated with said data flow; reducing latency associated with said data flow; reducing the amount of computation associated with sending said data plane traffic; or Achieve a more even distribution of resources or resource utilization.
12. A system comprising: one or more processors; as well as One or more non-transitory computer-readable media storing instructions that, when executed, cause the one or more processors to perform operations comprising: establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic of the data flow is routed through a relay node disposed between the client device and the resource; determining, using a Session Traversal Utilities for Network Address Translators (STUN) server, an alternative networking connection for the data flow between the client device and the resource that bypasses the relay node; determining whether the alternate networking connection is a more optimal path for the data plane traffic than the initial networking connection; and The data plane traffic of the data flow is routed through the alternate networking connection based at least in part on determining that the alternate networking connection is a more optimal path.
13. The system according to claim 12, wherein: The initial networking connection is a zero trust network access (ZTNA) networking connection, and the alternative networking connection is at least one of the following connections: a direct networking connection, a proxy networking connection, or a proxy and relay networking connection passing through different relay nodes.
14. The system according to claim 12 or 13, wherein: The alternate networking connection is determined using the STUN server while the data plane traffic of the data flow is sent between the client device and the resource via the initial networking connection.
15. A system according to any one of claims 12 to 14, wherein: Determining the alternative networking connection using the STUN server includes determining an Internet Protocol (IP) address and port associated with a pinhole flow via one or more network security components disposed between the client device and the resource.
16. The system according to any one of claims 12 to 15, wherein the operations further comprise: and determining whether a security policy allows the alternative networking connection to be made between the client device and the resource, and wherein determining the alternative networking connection using the STUN server is based at least in part on determining that the security policy allows the alternative networking connection to be made.
17. The system according to any one of claims 12 to 16, wherein the operations further comprise: A determination is made as to whether an encryption protocol associated with the resource satisfies a security policy, and wherein determining the alternative networking connection using the STUN server is based at least in part on determining that the encryption protocol satisfies the security policy.
18. The system of any one of claims 12 to 17, wherein the operations further comprise: determining that the alternative networking connection between the client device and the resource fails to satisfy security policy requirements; as well as When routing the data plane traffic through the alternative networking connection, the data plane traffic is caused to flow through security functions associated with the resource.
19. One or more non-transitory computer-readable media storing instructions that, when executed, cause one or more computing devices to perform operations comprising: establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic of the data flow is routed through a relay node disposed between the client device and the resource; determining, using a Session Traversal Utilities for Network Address Translators (STUN) server, an alternative networking connection for the data flow between the client device and the resource that bypasses the relay node; determining whether the alternate networking connection is a more optimal path for the data plane traffic than the initial networking connection; as well as The data plane traffic of the data flow is routed through the alternate networking connection based at least in part on determining that the alternate networking connection is a more optimal path.
20. The one or more non-transitory computer readable media of claim 19, wherein: The initial networking connection is a zero trust network access (ZTNA) networking connection, and the alternative networking connection is at least one of the following connections: a direct networking connection, a proxy networking connection, or a proxy and relay networking connection passing through different relay nodes.
21. An apparatus comprising: means for establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic of the data flow is routed through a relay node disposed between the client device and the resource; means for determining, using a Session Traversal Utilities for Network Address Translator (STUN) server, an alternate networking connection for the data flow that bypasses the relay node; as well as Means for routing the data plane traffic of the data flow through the alternate networking connection based at least in part on determining that the alternate networking connection is a more optimal path for the data plane traffic than the initial networking connection.
22. The apparatus according to claim 21, further comprising: Module for implementing the method according to any one of claims 2 to 11.
23. A computer program, a computer program product or a computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 11.
Citation Information
Cited By
Method and apparatus for managing customer premises traffic
US12689567B2