Enforcing Conditional Access to Network Services Based on Authorization Statuses Associated with Network Flows

This application is a continuation of and claims priority to U.S. patent application Ser. No. 18/453,952, filed Aug. 22, 2023.

This present application pertains to network communication systems, and more particularly, to techniques for enforcing conditional access to network services based on per-flow authorization statuses associated with network flows.

In computer networking systems, it is crucial to control and manage access to network services in an effective, efficient, and secure manner. This involves the process of authorizing users based on certain criteria, and subsequently granting or denying access to network services. One of the challenges in this scenario is the efficient handling of time-sensitive processes such as Domain Name System (DNS) queries and Transmission Control Protocol (TCP) handshake requests, which may time out before a user can complete an authentication process.

This disclosure describes techniques for enforcing conditional access to network services based on per-flow authorization statuses associated with network flows. In some cases, the techniques described herein relate to a method including detecting, by a processor of a first computing device, that a second computing device is operating in a per-flow authorization mode. The method may further include receiving, from the second computing device, a first request to communicate using a first network flow between the second computing device and a third computing device. The method may further include determine that the first network flow is authorized, wherein determining that the first network flow is authorized comprises determining at least one of: (i) that the first network flow is associated with a past authentication that is active, or (ii) that the third computing device is exempt from an authentication requirement. The method may further include based on determining that the first network flow is authorized, transmitting first data associated with the first request to the third computing device. The method may further include receiving, from the second computing device, a second request to communicate using a second network flow between the second computing device and a fourth computing device. The method may further include determine that the second network flow is unauthorized based on determining that the second network flow is independent of any active authentications and that the fourth computing device is subject to the authentication requirement. The method may further include based on determining that the first network flow is unauthorized, blocking transmission of second data associated with the second request to the fourth computing device.

Additionally, the techniques described herein may be performed by a system and/or device having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the method described above.

This disclosure describes techniques for enforcing conditional access to network services based on per-flow authorization statuses associated with network flows. In some cases, an example system selectively allows or blocks access to a network service based on whether the network flow associated with the access request has been authorized. The techniques may enable a captive portal process to give additional time to a user to complete an authentication process by preventing timeouts associated with DNS queries or TCP handshake requests.

In some cases, if a network flow associated with a DNS query is not authorized, the example system synthesizes a DNS response with an artificial canonical name (CNAME) record referring to an invalid hostname. This DNS response causes the querying device to retry the query, which prevents the DNS process from timing out and gives time to user to authenticate. The example system continues responding with artificial CNAME records until authentication occurs, a timeout threshold expires, or authentication fails. If the user authenticates before timeout, the example system resolves the initial DNS query. If the timeout threshold expires or authentication fails (e.g., due to exceeding maximum number of allowable authentication attempts), then the example system may redirect the querying device to a block page.

In some cases, if a network flow associated with a TCP handshake request is not authorized, the example system establishes a partial two-party TCP connection with the requesting device only, without connecting to the destination device. This two-party TCP connection provides the impression of a successful TCP handshake to the requesting device and prevents the TCP request from timing out, thus giving the user more time to authenticate. The example system maintains the two-party connection, dropping all packets received in association with that connection, until authentication occurs, a timeout threshold expires, or authentication fails. If the user authenticates before timeout, the example system creates the three-way TCP connection with the destination and starts to relay packets associated with that connection. If the timeout threshold expires or authentication fails (e.g., due to exceeding maximum number of allowable authentication attempts), then the example system may redirect the querying device to a block page.

In some cases, if a network flow associated with a UDP packet is not authorized, the example system drops the UDP packet. The sending device may retry sending packets due to retransmission mechanisms. The example system continues dropping UDP packets associated with a network flow until authentication occurs, a timeout threshold expires, or authentication fails. If the user authenticates before timeout, the example system starts to relay packets associated with the network flow. If the timeout threshold expires or authentication fails (e.g., due to exceeding maximum number of allowable authentication attempts), then the example system may redirect the querying device to a block page.

In some cases, by giving users additional time to perform authentication before reaching a timeout, the techniques described herein reduce the number of reload requests, which in turn reduces the computational load on server devices and proxy servers. Moreover, by enabling selective captive portal enforcement on a network flow level, the techniques described herein enhance security of access to network resources. For example, the techniques described herein can be used to enable selective captive portal enforcement in virtual private network (VPN) or zero trust network access (ZTNA) environments.

an example environmentfor conditional access to network services based on per-flow authorization statuses associated with network flows. Environmentincludes an endpoint device, a proxy server, multiple web servers, and multiple DNS servers.

The endpoint devicemay be a computing device operated by an end user that generates requests to access network services hosted by the web serversvia the proxy server. The endpoint devicemay be, for example, a personal computer, smartphone, tablet computer, smart television, Internet of Things (IoT) device, or other type of computing device capable of connecting to a network and accessing network services. The endpoint devicemay execute software applications such as a web browser or other applications that generate network connection requests and communicate with the proxy serverand web serversover a network.

The proxy serveroperates as an intermediary between the endpoint deviceand the web serversthat host various network services. The proxy servermay be configured to conditionally relay traffic between the endpoint deviceand the web serversbased on authorization statuses associated with different network flow. A network flow that has been previously authenticated or may be directed to an allowlisted destination device may be relayed normally by the proxy server. However, a network flow that is not authorized or directed to a non-allowlisted destination can be blocked or redirected by the proxy serverto facilitate authentication.

A network flow may refer to a sequence of packets sent between two nodes (e.g., between the endpoint deviceand one of the web servers) over a network, where the sequence of packets shares certain characteristics. For example, a network flow may include packets belonging to a particular TCP connection or UDP communication stream between a client and server. The packets in a network flow may have a common source address, destination address, source port, destination port, and/or transport protocol.

In some cases, the proxy serverprocesses a DNS query, a TCP handshake request, or a data packet received from the endpoint deviceto determine the corresponding network flow. The proxy serverthen determines whether the network flow is authorized. A network flow may be determined to be authorized if it is associated with an active authentication (e.g., if it has been previously authenticated and the authentication has not expired) or if it is associated with a destination device that is allowlisted. In some cases, the proxy servermaintains a database that describes network flows that are associated with active authentications. When a new DNS query or data packet arrives, the relevant proxy component (e.g., one of the DNS resolver, TCP proxy, or UDP proxy) processes the source and destination identifiers of the query or data packet to match it to an existing flow in the database. If a match is found, the network flow is determined to be authorized.

The proxy servermay include several components to enable conditional access to the web servers. A DNS resolvermay process domain name system (DNS) queries received from the endpoint device. The DNS resolverdetermines whether the endpoint deviceis authorized to communicate with the destination specified in the DNS query based on the authorization status of the corresponding network flow. If the network flow is authorized, the DNS query may be resolved by querying one of the DNS serversto retrieve an IP address for the destination web server. If the network flow is not authorized, the DNS resolversynthesizes a DNS response with an artificial canonical name (CNAME) record (e.g., a CNAME record that refers to an inauthentic hostname, such as a randomly generated hostname) that refers to an inauthentic hostname (e.g., a randomly generated hostname). This causes the endpoint deviceto retry the DNS query with the inauthentic hostname, during which time the user can be prompted to authenticate.

In some cases, the DNS resolvercontinues to respond to DNS queries with inauthentic hostnames until the earlier of network flow authentication or the expiration of a threshold period from the receipt of the initial DNS query. If the threshold period expires before authentication is completed, the DNS resolvermay redirect the endpoint deviceto a block webpage (e.g., by returning the IP address of the block webpage). The block webpage may describe the reason for blocking access to the requested hostname. In some cases, if the authentication fails, the DNS resolvermay redirect the endpoint deviceto the block webpage.

The TCP proxymay process TCP handshake requests received from the endpoint devicebased on the authorization status of the corresponding network flow. If the network flow is authorized, the TCP proxymay establish a normal three-party TCP handshake between the endpoint deviceand destination web serverwith the proxy acting as a relay. If the network flow is not authorized, the TCP proxymay establish a two-party TCP connection between the endpoint deviceand proxy server. This prevents the connection request from timing out during authentication process. Once authentication is complete, the TCP proxycan establish the full three-party TCP connection with the web server.

In some cases, the TCP proxycontinues to respond to TCP packets transmitted using the two-party TCP handshake by refusing to relay those packets until the earlier of network flow authentication or the expiration of a threshold period from the receipt of the initial DNS query. If the threshold period expires before authentication is completed, the TCP proxymay redirect the endpoint deviceto a block webpage. The block webpage may describe the reason for blocking access to the requested hostname. In some cases, if the authentication fails, the TCP proxymay redirect the endpoint deviceto the block webpage.

The UDP proxymay process UDP packets received from the endpoint devicebased on the authorization status of the corresponding network flow. If the network flow is authorized, the UDP proxymay relay UDP packets to destination web server. If the network flow is not authorized, the UDP proxymay drop the UDP packet. In some cases, because UDP has longer time-out periods and is a connectionless protocol, there is no need for creating a two-party connection to provide the impression of a successful connection to the endpoint device.

In some cases, the UDP proxycontinues to drop UDP packets until the earlier of network flow authentication or the expiration of a threshold period from the receipt of the initial DNS query. If the threshold period expires before authentication is completed, the UDP proxymay redirect the endpoint deviceto a block webpage. The block webpage may describe the reason for blocking access to the requested hostname. In some cases, if the authentication fails, the UDP proxymay redirect the endpoint deviceto the block webpage.

The web serversmay host various network applications and services accessible to endpoint devicesvia the proxy server. Examples of web serversinclude servers associated with web sites, messaging services, streaming media services, enterprise applications, and online games. Web serversmay respond to a request relayed by the proxy serverafter the corresponding network flow is authorized.

DNS serversmay provide domain name resolution services used by the DNS resolvercomponent of the proxy server. DNS serverscan include public DNS servers or private DNS servers operating locally within the network environment. Examples of DNS serversinclude top-level domain (TLD) DNS servers, domain-level DNS servers, and subdomain-level DNS servers.

In an example workflow, to access a network service hosted by one of the web servers, the endpoint deviceinitiates a DNS query for the hostname of the web serverand sends this request to the proxy server. The DNS resolverobtains the authorization status of the network flow between the endpoint deviceand the destination web serverand determines that the network flow is not authorized. Accordingly, the DNS resolverreturns a DNS response to the endpoint devicecontaining an inauthentic CNAME record with a randomly generated hostname. The endpoint deviceautomatically retries the DNS query using this inauthentic hostname. Meanwhile, the user of the endpoint deviceis prompted to authenticate, for example by prompting for credentials or initiating multi-factor authentication. Until the authentication is completed, the DNS resolvercontinues to provide CNAME records with inauthentic hostnames to the endpoint device, which then leads to new DNS queries by the endpoint device. Once authentication is complete, the DNS resolverdetects that the network flow is now authorized. Accordingly, the DNS resolveruses the DNS serversto resolve the IP address of the original web server hostname. DNS resolvermay return this IP address to the endpoint device.

In another example workflow, to communicate with a destination web serverusing a TCP connection, the endpoint devicesends a TCP handshake request (a SYNC packet) to the TCP proxy. The TCP proxyobtains the authorization status of the network flow associated with the TCP connection between the endpoint device and the destination web serverand determines that the network flow is not authorized. Accordingly, the TCP proxydoes not create a three-party TCP connection but still returns a handshake acknowledgment (a SYNC-ACK packet) to the endpoint device. Having received the handshake acknowledgment, the endpoint devicesends an acknowledgement of the handshake acknowledgement (an ACK packet) and starts to send data using the TCP connection. Meanwhile, the user of the endpoint deviceis prompted to authenticate, for example by prompting for credentials or initiating multi-factor authentication. Until the authentication is completed, the TCP proxydoes not relay packets received using the network flow to the destination web serverand acknowledges those packets without delivering them to the destination. Once the authentication is complete, the TCP proxyestablishes a three-party TCP connection and starts to relay packets received from the endpoint device in relation to the network flow to the destination web server.

In an additional example workflow, to communicate with a destination web serverusing a UDP connection, the endpoint devicesends a UDP packet to the UDP proxy. The UDP proxyobtains the authorization status of the network flow associated with the UDP connection between the endpoint device and the destination web serverand determines that the network flow is not authorized. Accordingly, the UDP proxydrops the UDP packet. This may cause the endpoint deviceto transmit the UDP packet again. The UDP proxymay continue to drop UDP packets associated with the network flow until that network flow is authorized.

The proxy servermay be used to enable selective captive portal enforcement in virtual private network (VPN) or zero trust network access (ZTNA) environments. In these environments, the proxy servercan be used to enable previously authenticated network flows and network flows to allowlisted destinations but disable network flows to non-allowlisted destinations that have not been previously authenticated.

For example, if a DNS query seeks the IP address of a non-allowlisted web server, the DNS resolvermay be configured to continue to respond to the DNS query with inauthentic-hostname CNAME records until the DNS resolverdetermines that the network flow between the endpoint deviceand the non-allowlisted web serveris authenticated.

As another example, if a TCP handshake request seeks a TCP connection with a non-allowlisted web server, the TCP proxymay be configured to establish a two-party TCP connection and maintain this TCP connection until the TCP proxydetermines that the network flow between the endpoint deviceand the non-allowlisted web serveris authenticated. If the TCP proxydetermines that the network flow between the endpoint deviceand the non-allowlisted web serveris authenticated, the TCP proxyestablishes a three-party TCP connection that involves the endpoint device, the non-allowlisted web server, and the proxy server.

is a flowchart diagram of an example processfor enabling a capital portal workflow. As depicted in, at operation, a Dynamic Host Configuration Protocol (DHCP) assigns an IP address to the computing device being connected to the network. At operation, the system determines whether the computing device supports captive portals. If so, then the system proceeds to operation. Otherwise, the system proceeds to operationto use connection patterns other than a captive portal workflow.

At operation, the system determines whether a web browser being used by the computing device supports active portals. If so, then the system proceeds to operation. Otherwise, the system proceeds to operationto use connection patterns other than a captive portal workflow.

At operation, the system presents a captive portal. The captive portal may be presented using a standard web browser using a captive portal mini browser (CPMB). In some cases, if the captive portal is presented using a CPMB, the system may close the CPMB upon successful connection.

is a flowchart diagram of an example processfor processing DNS queries from a source computing device when the source computing device is operating in a per-flow authorization mode. The per-flow authorization mode may require that each network flow be authorized and only allowed if it is either associated with an active authentication (e.g., if it has been previously authenticated and the authentication is active) or if it is to an allowlisted destination.

The processbegins when the system receives a DNS query from a source computing device (operation). The DNS query may include a requested hostname that the source computing device is attempting to resolve to an IP address.

Upon receiving the DNS query, the system extracts and records the source IP address of the DNS query (operation). This source IP address may identify the source computing device that originated the query.

The system then extracts the requested hostname from the DNS query (operation). This hostname may identify the web server or other network service that the source computing device is attempting to access.

Using the recorded source IP address and requested hostname, the system detects the network flow associated with this DNS query (operation). The network flow may be characterized by a source device and a destination device.

The system then determines whether the corresponding network flow associated with the DNS query is authorized (operation). The system may check a database or other data structure that tracks authentication status of different network flows. The system may determine that the network flow is authorized if the network flow is associated with an active authentication, or the destination is allowlisted. If the network flow associated with this DNS query is authorized (operation—yes), then the system performs normal DNS resolution by querying one or more external DNS servers for the IP address of the requested hostname (operation). The system may receive the IP address response from the DNS servers and return this IP address in a DNS response to the source computing device. This response may enable the source computing device to initiate direct communication with the destination web server using the resolved IP address.

If the system determines that the network flow is not authorized (operation—no), then the system generates a canonical name (CNAME) record with an inauthentic hostname, such as a randomly generated string. The system returns this synthesized CNAME record with the inauthentic hostname to the source computing device in a DNS response (operation). In some cases, after the source computing device receives this DNS response, it will automatically retry the DNS query using the inauthentic hostname from the CNAME record. This causes the source computing device to send a new DNS query to the system using the fake hostname. Upon receiving this retry DNS query with the inauthentic hostname (operation), the system checks whether the original network flow associated with the initial DNS query has now been authorized (operation). The system may determine whether the network flow has become authorized since the initial DNS query, for example due to the user authenticating.

If the network flow is now authorized (operation—yes), the system performs normal DNS resolution to retrieve the real IP address, as in operation. The real IP address is returned to the source computing device to allow access. If the network flow is still not authorized (operation—no), the system checks whether a timeout threshold has been reached since the receipt of the initial DNS query or if authentication has failed (e.g., due to failing a maximum number of allowed attempts for authentication) (operation). If the timeout threshold has not yet been reached and the authentication has not failed (operation—no), the system again synthesizes and returns another CNAME record with a different inauthentic hostname (repeat operation). This causes additional retry queries from the source computing device. If the timeout threshold has been reached or authentication has failed (operation—yes), the system returns the IP address of a block webpage to the source computing device instead of the real IP address (operation).

provides an operational exampleof processing DNS queries from a source computing devicewhen the source computing device is operating in a per-flow authorization mode. As depicted in, after the initial DNS queryby the source computing devicethat includes a requested hostname H, the DNS resolverreturns a DNS responsewith a CNAME response describing an inauthentic hostname Hbecause the network flow is not authorized. Thereafter, the source computing devicesends a second DNS queryfor H, and the DNS resolverresponds with the DNS responsewith a CNAME response describing an inauthentic hostname H, because the network flow is still not authorized. The source computing devicethen sends the DNS queryfor H. At this point, because the network flow is authorized, the DNS resolverreturns DNS responsethat includes the IP address for H, the originally requested hostname.

is a flowchart diagram of an example processfor processing TCP data packets transmitted by a source computing device while the source computing device is operating in a per-flow authorization mode. As depicted in, processbegins when the system receives a TCP handshake request (SYNC packet) from a source computing device attempting to establish a TCP connection with a destination computing device (operation). The system then records the source IP address and source port of the TCP handshake request to identify the source computing device (operation). The system also records the destination IP address and destination port specified in the TCP handshake packet to identify the intended destination device (operation).

Using the source and destination identifiers, the system detects the network flow associated with this TCP connection request (operation). The network flow may be characterized by the source IP address, source port number, destination IP address, and destination port number.

The system then determines whether the network flow associated with this TCP connection request is currently authorized (operation). The system may determine that the network flow is authorized if the network flow has an active authentication, or if the destination is allowlisted.

If the system determines that the network flow is authorized (operation—yes), the system performs normal TCP forwarding by relaying the handshake and subsequent packets (e.g., the TCP handshake acknowledgement (SYNC-ACK packet) and the acknowledgement of the TCP handshake acknowledgement (ACK packet)) between the source computing device and destination device (operation). This may establish a typical three-party TCP connection.

If the system determines that the determines network flow is not authorized (operation—no), the system returns a TCP handshake response (SYNC-ACK packet) directly to the source computing device without relaying the handshake request to the intended destination device. This may establish a two-party TCP connection. After the source computing device returns an acknowledgement (ACK packet) of the TCP handshake acknowledgement (SYNC-ACK packet), the system receives and processes this ACK packet (operation). But the system does not forward this packet to the destination device, instead acknowledging the packets directly back to the source device only. This may establish a partial two-party TCP connection between just the source computing device and the system, excluding the destination device. From the perspective of the source device, the connection has been established successfully.

Afterward, the system determines whether network flow associated with this TCP connection has now been authenticated (operation). This determination may be performed periodically and/or may be triggered when the system receives a TCP packet associated with the two-party TCP connection. This determination may determine if the flow has become authorized while the system has been maintaining the two-party connection.

If the system determines that network flow is now authorized (operation—yes), the system establishes the full three-party TCP connection by forwarding the stored handshake request to the destination device (operation). With the three-party handshake completed, the system now forwards packets normally between the source and destination.

If the system determines that network flow is still not authorized (operation—no), the system determines whether a timeout threshold has elapsed since the initial TCP connection request or whether the authentication has failed (operation). If the timeout has not yet expired and the authentication has not failed (operation—no), the system continues maintaining the two-party TCP connection with the source computing device only, without forwarding packets to the destination device until a next determination at operation.

If the timeout has expired or if the authentication has failed (operation—yes), the system sends a TCP reset (RST) to the source computing device instead of forwarding the stored packets to the destination (operation). This closes the TCP connection from the perspective of the source device. The system may also direct the source computing device to a block webpage.