Abstract: Techniques for utilizing a portion of a communication session identifier (e.g., a Session-ID, an SPI, a CID, a DCID, and/or the like) to indicate a target routing device (e.g., a VPN and/or ZTNA termination device) for establishing control plane session(s) and/or data plane session(s) at wire-speed in a networked computing environment. The routing device(s) of a networked computing environment may generate a communication session identifier and send the communication session identifier to the client device, such that subsequent packets send from the client device may be forwarded to the proper routing device indicated by the communication session identifier for establishment of one or more data plane sessions. Additionally, data plane sessions may be established using a Resumed Handshake rather than a full handshake that is typically required, as Session Resumption utilizes the assigned communication session identifier for mapping.

Abstract: Techniques for determining a preferred HTTP protocol for communication between a client device and a server over a network are described. A first type of HTTP probe is transmitted over a network from a client device to a server. A second type of HTTP probe is transmitted over a network from the client device to the server. If either the first type of HTTP probe response or the second type of HTTP probe response, the type of the HTTP probe response received is the preferred communication protocol. If the first type of HTTP probe response and the second type of HTTP probe response is received, a type of HTTP probe response received first is the preferred communication protocol. The client device communicates with the server over the network using the preferred communication protocol.

Abstract: Techniques for migrating on-premises and/or cloud-based workloads to follow a network session as it potentially migrates, due to multipathing techniques, across multiple edge and/or cloud datacenters. The techniques may include determining, by a controller of a network, that a traffic flow between an endpoint device and a workload has migrated to a different path of a multipath flow such that the traffic flow terminates at a different termination point than the workload. Based at least in part on determining that the traffic flow has migrated, the controller may cause a migration of a state of the workload to a location associated with the different termination point. That is, the controller may cause the workload to be migrated in its current state, which may be specific to the endpoint device, to follow the traffic flow.

Abstract: An apparatus configured to perform resilient data plane processing using multiple network streams may comprise a memory and a processor communicatively coupled to one another. The processor may be configured to establish a connection with the data aggregator, and request access to one or more resources from a data aggregator. Further, the processor may be configured to receive a first data stream and a second data stream from the data aggregator, combine a version of the first data stream and a version of the second data stream into a local data stream, and present the local data stream.

Abstract: Profile-based association method for enterprise networks may be provided. A computing device may configure a first profile and a second profile. Next, the client device may be configured with a set of network profiles associated with a plurality of networks. A user of the client device may be queried for a profile choice for one of the plurality of networks. Then the client device may associate with the one of the plurality of networks according to the profile choice provide by the user.

Abstract: This disclosure describes techniques for enforcing conditional access to network services. In an example method, a first computing device detects a second device operating in a per-flow authorization mode. The first device receives a first request from a second computing device to communicate with a third computing device using a first network flow and determines that the first flow is authorized (e.g., because of an active past authentication and/or the third device's authentication exemption). Data associated with the first request is transmitted to the third device. The first device then receives a second request to communicate with a fourth computing device using a second network flow and determines that the second flow is not authorized (e.g., because it is not associated with an active past authentication and/or the fourth device is not exempt from authentication). Data associated with the second request is not transmitted to the fourth device.

Abstract: Techniques for binding communication flows to unique addresses and/or ports, and configuring networking devices internal to a network to apply policy without the need to further introspect a given stream. Further, by creating mappings of unique addresses and/or ports to flows, the network devices are able to enforce policy without needing to coordinate with an edge node of the network at which the communication session terminates. Further, the techniques may include providing an SDN controller with a mapping between a unique address/port and a network flow, determining flow-specific policy to enforce on the flow, and programming one or more network devices to enforce the flow-specific policy in the network using the unique address/port.

Abstract: In one embodiment, an illustrative method herein may comprise: obtaining, by a device, one or more independent telemetry streams, wherein each of the one or more independent telemetry streams is uniquely identifiable by a span identifier; translating, by the device, each of the one or more independent telemetry streams into a corresponding QUIC protocol stream; mapping, by the device, the span identifier of each of the one or more independent telemetry streams to a respective stream identifier that uniquely identifies a QUIC channel of a multiplexed QUIC protocol stream; and communicating, by the device, the multiplexed QUIC protocol stream containing each of the one or more independent telemetry streams on its corresponding QUIC channel to cause a retrieving device to determine the span identifier of each of the one or more independent telemetry streams based on their respective stream identifier.

Abstract: Techniques for leveraging the MASQUE protocol to provide remote clients with full application access to private enterprise resources are described herein. One or more network nodes may be configured to execute a MASQUE proxy service to provide a remote client device with full access to an enterprise/private application resource executing on an application node and hosted in an enterprise/application network, behind the MASQUE proxy service. In some examples, the MASQUE proxy service may execute on a single proxy node hosted at an edge of a cloud network or at an edge of an enterprise network. Additionally, or alternatively, a first instance of the MASQUE proxy service may execute on a first proxy node hosted at an edge of a cloud network (e.g., an ingress proxy node) and a second instance of the MASQUE proxy service may execute on a second proxy node hosted at an edge of the enterprise network.

Abstract: Techniques for syncing authentication and/or authorization tokens, cookies, and related metadata across different browser instances to enable disparate applications to share a single authentication/authorization ceremony. The techniques may include receiving a policy indicating multiple enterprise-managed applications that are capable of sharing tokens or cookies for user authentication. The techniques may also include receiving a token or a cookie indicating that a user is authenticated to access a first application of the multiple enterprise-managed applications. Based at least in part on the policy, the token or the cookie may be provided to a browser such that a second application of the multiple enterprise-managed applications refrains from causing the user to authenticate for access to the second application.

Abstract: Techniques for routing service mesh traffic based on whether the traffic is encrypted or unencrypted are described herein. The techniques may include receiving, from a first node of a cloud-based network, traffic that is to be sent to a second node of the cloud-based network and determining whether the traffic is encrypted or unencrypted. If it is determined that the traffic is encrypted, the traffic may be sent to the second node via a service mesh of the cloud-based platform. Alternatively, or additionally, if it is determined that the traffic is unencrypted, the traffic may be sent to the second node via an encrypted tunnel. In some examples, the techniques may be performed at least partially by a program running on the first node of the cloud-based network, such as an extended Berkeley Packet Filter (eBPF) program, and the like.

Abstract: Techniques for leveraging the MASQUE protocol to provide remote clients with full application access to private enterprise resources are described herein. One or more network nodes may be configured to execute a MASQUE proxy service to provide a remote client device with full access to an enterprise/private application resource executing on an application node and hosted in an enterprise/application network, behind the MASQUE proxy service. In some examples, the MASQUE proxy service may execute on a single proxy node hosted at an edge of a cloud network or at an edge of an enterprise network. Additionally, or alternatively, a first instance of the MASQUE proxy service may execute on a first proxy node hosted at an edge of a cloud network (e.g., an ingress proxy node) and a second instance of the MASQUE proxy service may execute on a second proxy node hosted at an edge of the enterprise network.

Abstract: Techniques for creating in/out App Connectors for secure access solutions without the need for STUN, TURN, and/or a long-lived control plane component. The techniques may include, among other things, establishing, by an App Connector associated with a workload hosted by an enterprise network, a pool of idle sessions between the App Connector and a termination node associated with the enterprise network. The techniques may also include determining, by the App Connector, that a first idle session of the pool of idle sessions has been consumed by the termination node to establish a communication session for a client device to communicate with the workload. Based at least in part on determining that the first idle session has been consumed, the techniques may include establishing, by the App Connector, a second idle session to be added to the pool of idle sessions between the App Connector and the termination node.

Abstract: Techniques for routing service mesh traffic based on whether the traffic is encrypted or unencrypted are described herein. The techniques may include receiving, from a first node of a cloud-based network, traffic that is to be sent to a second node of the cloud-based network and determining whether the traffic is encrypted or unencrypted. If it is determined that the traffic is encrypted, the traffic may be sent to the second node via a service mesh of the cloud-based platform. Alternatively, or additionally, if it is determined that the traffic is unencrypted, the traffic may be sent to the second node via an encrypted tunnel. In some examples, the techniques may be performed at least partially by a program running on the first node of the cloud-based network, such as an extended Berkeley Packet Filter (eBPF) program, and the like.

Abstract: Techniques for managing migrations of QUIC connection session(s) across proxy nodes, data centers, and/or private application nodes are described herein. A global key-value datastore, accessible by proxy nodes and/or application nodes, may store mappings between a first QUIC connection, associated with a proxy node and a client device, on the frontend of the proxy node and a second QUIC connection, associated with the proxy node and an application node, on the backend of the proxy node. With the global key-value datastore being accessible by the proxy nodes, when a proxy node receives a QUIC packet on the front end or the back end, the proxy node may determine where to map this connection to on the opposite end. Additionally, with the global key-value datastore being accessible to the application nodes, when an application node receives a QUIC packet, the application node may determine the client device associated with the connection.

Abstract: Techniques for binding communication flows to unique addresses and/or ports, and configuring networking devices internal to a network to apply policy without the need to further introspect a given stream. Further, by creating mappings of unique addresses and/or ports to flows, the network devices are able to enforce policy without needing to coordinate with an edge node of the network at which the communication session terminates. Further, the techniques may include providing an SDN controller with a mapping between a unique address/port and a network flow, determining flow-specific policy to enforce on the flow, and programming one or more network devices to enforce the flow-specific policy in the network using the unique address/port.

Abstract: In one embodiment, an illustrative method herein may comprise: obtaining, by a device, one or more independent telemetry streams, wherein each of the one or more independent telemetry streams is uniquely identifiable by a span identifier; translating, by the device, each of the one or more independent telemetry streams into a corresponding QUIC protocol stream; mapping, by the device, the span identifier of each of the one or more independent telemetry streams to a respective stream identifier that uniquely identifies a QUIC channel of a multiplexed QUIC protocol stream; and communicating, by the device, the multiplexed QUIC protocol stream containing each of the one or more independent telemetry streams on its corresponding QUIC channel to cause a retrieving device to determine the span identifier of each of the one or more independent telemetry streams based on their respective stream identifier.

Abstract: Techniques for a client device configured with a kernel driver framework (KDF) to establish connection(s) with target workload(s) provisioned in remote network(s) (e.g., an enterprise network) using non-routable synthetic IP address(es) (e.g., a loopback address within a link-local address range, a unique local address within a discard prefix range, and/or the like). The KDF may intercept DNS requests from application(s) executing on a client device, generate and return a synthetic IP address associated with a given domain in the DNS request, and establish a connection with a secure access gateway using the non-routable synthetic IP address. Additionally, the KDF may invoke an external browser with an authentication redirect to a randomly generated synthetic IP address on a randomly generated port, where a local listener on a client device may listen on the synthetic IP address and random port to obtain and/or store authentication data for later use.

Abstract: Techniques for scaling additional capacity for secure access solutions and other workloads of enterprise edge networks in and out of a cloud-computing network based on demand. The techniques may include determining that a capacity associated with a secure access node of an enterprise edge network meets or exceeds a threshold capacity. Based at least in part on the capacity meeting or exceeding the threshold capacity, the techniques may include causing a facsimile of the secure access node to be spun up on a cloud-computing network that is remote from the enterprise edge network. In this way, new connection requests received from client devices can be redirected to the facsimile of the secure access node. Additionally, or alternatively, one or more existing connections between client devices and the secure access node may be migrated to the facsimile of the secure access node in the cloud.

Abstract: Techniques for managing migrations of QUIC connection session(s) across proxy nodes, data centers, and/or private application nodes are described herein. A global key-value datastore, accessible by proxy nodes and/or application nodes, may store mappings between a first QUIC connection, associated with a proxy node and a client device, on the frontend of the proxy node and a second QUIC connection, associated with the proxy node and an application node, on the backend of the proxy node. With the global key-value datastore being accessible by the proxy nodes, when a proxy node receives a QUIC packet on the front end or the back end, the proxy node may determine where to map this connection to on the opposite end. Additionally, with the global key-value datastore being accessible to the application nodes, when an application node receives a QUIC packet, the application node may determine the client device associated with the connection.